From owner-freebsd-stable@FreeBSD.ORG Sun Oct 25 00:47:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD5CC1065694; Sun, 25 Oct 2009 00:47:04 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id F1DEE8FC15; Sun, 25 Oct 2009 00:47:03 +0000 (UTC) Received: by fxm6 with SMTP id 6so10598596fxm.43 for ; Sat, 24 Oct 2009 17:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:x-enigmail-version :content-type; bh=Jgo1oz91UzhC843uO4oDPHCEx3xYbfGTO5obJor8JiY=; b=NMyVlcMhjlrx1g4JF1b23Rqb68DpBNJoryQGkuPvphDF/FdDed6Maz1ry1bh2qh+Jj LKaa/AAdEvQ6w+6SKUfiTa4I0u5FxiwrNNpStU7Weego9uzlYc9iRcQ2BfKRKE3xmqIt 5x9X+j4O62k19ghfoHJCyr1sBPoi611zel79w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:content-type; b=N7esZVe7qQIxTvIkTUn/ymbu2aHA+uvRqTV+YAkTaTRzDQjpH/Mm86IUUsKScqqPzJ Cz5hYVHNUKlkpRJOLpwC4iZQzmLNkMKbtykBfdvP0XNnuvXn5L2zUCTN+5QhysgF9Q3I okd7cTSdTrTMo/Kj2OjFCrj8P2VwR4GFzKgGQ= Received: by 10.103.127.32 with SMTP id e32mr1830525mun.70.1256431622913; Sat, 24 Oct 2009 17:47:02 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 7sm9023256mup.42.2009.10.24.17.46.58 (version=SSLv3 cipher=RC4-MD5); Sat, 24 Oct 2009 17:47:02 -0700 (PDT) Sender: Alexander Motin Message-ID: <4AE3A001.8000205@FreeBSD.org> Date: Sun, 25 Oct 2009 03:46:57 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: FreeBSD-Current X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------040203050503000402040302" Cc: icegloom dem , FreeBSD Stable , freebsd-amd64@freebsd.org Subject: MCP55 SATA solution to test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 00:47:04 -0000 This is a multi-part message in MIME format. --------------040203050503000402040302 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Hi. Thanks to one man who provided access to his machine, I seem to found how to fix device detection on nVidia MCP55 SATA controller on amd64 8.0. Looks like this controller need some time (very short) to enable BAR(5) memory access after PCI configuration register written. Probably some changes in PCI code exposed this issue. Also it explains why setting hw.pci.mcfg to 0 helps. Attached patch solves problem for that machine. Testers are welcome. -- Alexander Motin --------------040203050503000402040302 Content-Type: text/plain; name="mcp55.sata.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mcp55.sata.patch" --- ata-nvidia.c.prev 2009-10-25 03:13:57.000000000 +0300 +++ ata-nvidia.c 2009-10-25 03:15:52.000000000 +0300 @@ -165,7 +165,8 @@ ata_nvidia_chipinit(device_t dev) /* enable control access */ pci_write_config(dev, 0x50, pci_read_config(dev, 0x50, 1) | 0x04,1); - + /* MCP55 seems to need some time to allow r_res2 read. */ + DELAY(10); if (ctlr->chip->cfg1 & NVQ) { /* clear interrupt status */ ATA_OUTL(ctlr->r_res2, offset, 0x00ff00ff); --------------040203050503000402040302-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 25 02:07:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BF1B1065679 for ; Sun, 25 Oct 2009 02:07:18 +0000 (UTC) (envelope-from pirat@tint.or.th) Received: from mail.tint.or.th (ns2.tint.or.th [122.154.13.210]) by mx1.freebsd.org (Postfix) with SMTP id 194718FC08 for ; Sun, 25 Oct 2009 02:07:16 +0000 (UTC) Received: (qmail 22027 invoked from network); 25 Oct 2009 01:34:32 -0000 Received: from www.tint.or.th (HELO alpha.nst.or.th) (122.154.13.80) by mail.tint.or.th with SMTP; 25 Oct 2009 01:34:32 -0000 Received: from 10.3.1.28 (10.3.1.28 [10.3.1.28]) by webmail.tint.or.th (Horde Framework) with HTTP; Sun, 25 Oct 2009 08:14:22 +0700 Message-ID: <20091025081422.20341pp8zbvuupgu@webmail.tint.or.th> X-Priority: 3 (Normal) Date: Sun, 25 Oct 2009 08:14:22 +0700 From: =?utf-8?b?4LmE4Lie4Lij4Lix4LiKIA==?= =?utf-8?b?4Lio4Lij4Li14LmC4Lii4LiY4Liy?= To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3) Subject: make release stop at cdrtools X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 02:07:18 -0000 hi sirs, apologized me for disturbing this list but ireally have problem s. i make my own release by follwoing document in releng articles. here is my command cd /usr/src/release time make CHROOTDIR=3D/kaitag/KAITAG BUILDNAME=3D7.2-RELEASE \ CVSROOT=3D/var/ftp/pub/ncvs RELEASETAG=3DRELENG_7_2_0_RELEASE \ EXTSRCDIR=3D/usr/src EXTPORTSDIR=3D/usr/ports \ DOC_LANG=3Den_US.ISO8859-1 NODOC=3DNO NOPORTS=3DNO \ MAKE_DVD=3DYES MAKE_ISOS=3DYES CDROM=3DYES RELEASEDISTFILES=3D/var/ftp/pub/d= istfiles \ release the build process goes well but then fetching for cdrtools.tbz begin and sto= p. in my machine i have installed cdrtools and there is also mkisofs file =20 so i wonder why the script /usr/src/release/i386/mkisofsimages.sh =20 still fetching for cdrtools. and here is my uname of my machine wmc# uname -a FreeBSD wmc.tint.or.th 7.2-RELEASE FreeBSD KAITAG #0: Wed Oct 21 =20 14:36:40 ICT 2009 root@wmc.tint.or.th:/usr/obj/usr/src/sys/WMC i386 wmc# i set UNAME_r=3D7.2-RELEASE in /etc/make.conf though. many thanks in advance for any helps and hints. with best regards, psr --=20 =E0=B8=A1=E0=B8=B0=E0=B9=84=E0=B8=9F =E0=B8=85=E0=B8=99=E0=B9=80=E0=B8=AB=E0= =B8=A5=E0=B8=B4=E0=B8=87=E0=B8=9F=E0=B9=89=E0=B8=B2 =E0=B8=A1=E0=B8=B0=E0=B8=82=E0=B8=B2=E0=B8=A1 =E0=B8=84=E0=B8=B4=E0=B8=99=E0= =B9=80=E0=B8=94=E0=B8=B4=E0=B8=99=E0=B8=94=E0=B8=99 http://makham.blogspot.com ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 25 16:37:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 922CB1065670 for ; Sun, 25 Oct 2009 16:37:17 +0000 (UTC) (envelope-from marco.broeder@gmx.eu) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id D89828FC15 for ; Sun, 25 Oct 2009 16:37:16 +0000 (UTC) Received: (qmail invoked by alias); 25 Oct 2009 16:10:35 -0000 Received: from port-92-195-123-16.dynamic.qsc.de (EHLO localhost) [92.195.123.16] by mail.gmx.net (mp019) with SMTP; 25 Oct 2009 17:10:35 +0100 X-Authenticated: #23197544 X-Provags-ID: V01U2FsdGVkX18Wh+8h1qoWtyZnSbXhhnuO+jSsS1a4OAfYoY75bY qQD+JcnL9fpMsG From: Marco =?utf-8?q?Br=C3=B6der?= To: freebsd-stable@freebsd.org Date: Sun, 25 Oct 2009 17:09:49 +0100 User-Agent: KMail (FreeBSD) References: <4AE3A001.8000205@FreeBSD.org> In-Reply-To: <4AE3A001.8000205@FreeBSD.org> MIME-Version: 1.0 Message-Id: <200910251709.49850.marco.broeder@gmx.eu> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Y-GMX-Trusted: 0 X-FuHaFi: 0.66 Cc: Alexander Motin , FreeBSD-Current , icegloom dem , freebsd-amd64@freebsd.org Subject: Re: MCP55 SATA solution to test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: marco.broeder@gmx.eu List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 16:37:17 -0000 On Sun October 25 2009 02:46:57 Alexander Motin wrote: > Hi. >=20 > Thanks to one man who provided access to his machine, I seem to found > how to fix device detection on nVidia MCP55 SATA controller on amd64 > 8.0. Looks like this controller need some time (very short) to enable > BAR(5) memory access after PCI configuration register written. Probably > some changes in PCI code exposed this issue. Also it explains why > setting hw.pci.mcfg to 0 helps. >=20 > Attached patch solves problem for that machine. Testers are welcome. >=20 Success! I tested your patch and everything is working fine with hw.pci.mcfg set to 1, now. Please commit it. Many thanks! =2D-=20 Regards, Marco Br=C3=B6der OpenPGP key fingerprint: 5615 106E 031A F3D3 64CC 0F9E 4DCE 6524 F595 082F From owner-freebsd-stable@FreeBSD.ORG Sun Oct 25 16:44:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31DC71065697 for ; Sun, 25 Oct 2009 16:44:07 +0000 (UTC) (envelope-from kris.weston@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id E42638FC1E for ; Sun, 25 Oct 2009 16:44:05 +0000 (UTC) Received: by ewy18 with SMTP id 18so9870070ewy.43 for ; Sun, 25 Oct 2009 09:44:04 -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; bh=KfOHqae4egt0Ld+HppA54iK94Ee6i3eWvRE4LmaeIE4=; b=nrCNT4YtEUfo1xtwd4R/B7udmplnCDhqiPykeosoQzZ7qjAjEM3thN4T6EA45Lpkx+ sHfsgh8GPuX7SCZ9i8UaUwOmI5zO4m7MPPqTv7ImYUCyiHlbYB/2KNaedLMrKIBwPFWu bAzbgvAIF6Eco8vkp6h+2nypZufwADm+sWpEI= 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; b=wE0v8YFlxx8g/2o8ukVKwTJ2Kaa75J3pRkc9ZLAk7mKuIVwVjoYz2yJ/smJ+ygBeJS C4vT3Mq3v1LMx5k99na4E21kbtHDW7l9XIGERktfBtOyIYI0IUU6B59uw+9rQNb5Tr30 IBIHcRg9OtCrZAHqsqTTOt30cXZuzi9FhWvPA= MIME-Version: 1.0 Received: by 10.216.86.132 with SMTP id w4mr1301444wee.87.1256489044501; Sun, 25 Oct 2009 09:44:04 -0700 (PDT) In-Reply-To: <1256303940.2283.15.camel@balrog.2hip.net> References: <72d267bc0910210511t4a54ce3dm1490fec593377a44@mail.gmail.com> <1256303940.2283.15.camel@balrog.2hip.net> Date: Sun, 25 Oct 2009 16:44:04 +0000 Message-ID: <72d267bc0910250944y298d9535x9eac8cf9ba7a9b27@mail.gmail.com> From: Kris Weston To: Robert Noland Content-Type: multipart/mixed; boundary=0016e6d77ed32966ad0476c52798 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: i am desperate over some GPT tables X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 16:44:07 -0000 --0016e6d77ed32966ad0476c52798 Content-Type: text/plain; charset=ISO-8859-1 hi Robert appreciate you having a look at this, if you need any funny noises ever, give us a shout :) i really dont know what to do as i dont have a spare box to try out solaris on and solaris wont boot fully here... i did manage to export the drives from solaris first so all *should* be well... there are three disks in the set ad4,ad6,ad8 terrabyte each - they are supposed to be two mirrors but one disk went down should still work though - well was working in solaris... as i said before it at least could read the pools from freebsd before but something has happened now where it wont... i think 4+6 are a mirror... let me know if you can shed any light... out of interest - how do you look at these dumps ? and what are you looking for ? thanks Kris -- )) (( c[_] 2009/10/23 Robert Noland > On Wed, 2009-10-21 at 13:11 +0100, Kris Weston wrote: > > been looking for months now, trawled google no help, i just dont > understand. > > do you need a GPT table with zfs ? > > i have a pentium D 3ghz (running 64bit stable 7.2) and i cant seem to > import > > my zpool into it > > exported fine on solaris , its definitely the same version (v13) > > but when i import into zfs it says GPT tables corrupt ? > > why ? and what does this mean ? > > please help me. pleeeeease. > > Send me the fist 34 sectors of the disk and I will try to take a look. > > dd if= of=header.dmp bs=512 count=34 > > robert. > > > -- > > > > )) > > (( > > c[_] > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > -- > Robert Noland > FreeBSD > > --0016e6d77ed32966ad0476c52798 Content-Type: application/octet-stream; name="headerad4.dmp" Content-Disposition: attachment; filename="headerad4.dmp" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g180zhmb0 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABx8X1RAAAA////7v///wEA AACvbXB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVapF RkkgUEFSVAAAAQAAAgAAdR5OLwAAAAABAAAAAAAAAK9tcHQAAAAAIgAAAAAAAACObXB0AAAAALvu hT9trUc1qY/b2p80ChQCAAAAAAAAAAkAAACAAAAA6vz2dQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMOM iWrSHbIRmaYIACBzZjEJtXrznMVqR6EFgFNuo8xzAAEAAAAAAACOLXB0AAAAAAAAAAAAAAAAegBm AHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7WpRq 0h2yEZmmCAAgc2Yx2zIpwvcZYWGt7OCsR2L/048tcHQAAAAAjm1wdAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --0016e6d77ed32966ad0476c52798 Content-Type: application/octet-stream; name="headerad6.dmp" Content-Disposition: attachment; filename="headerad6.dmp" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g180zhmh1 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABApsJPAAAA////7v///wEA AACvbXB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVapF RkkgUEFSVAAAAQAAAgAANkM1swAAAAABAAAAAAAAAK9tcHQAAAAAIgAAAAAAAACObXB0AAAAAAYi WFZ2u0p+p4byPpVoMxcCAAAAAAAAAAkAAACAAAAAKpBM+QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMOM iWrSHbIRmaYIACBzZjE5tNoYsEnJEdYjkyQ6xGjrAAEAAAAAAACOLXB0AAAAAAAAAAAAAAAAegBm AHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7WpRq 0h2yEZmmCAAgc2Yxh9w4A2OZbSLhloVt6Zrrjo8tcHQAAAAAjm1wdAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --0016e6d77ed32966ad0476c52798 Content-Type: application/octet-stream; name="headerad8.dmp" Content-Disposition: attachment; filename="headerad8.dmp" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g180zhml2 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////7v///wEA AACvbXB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVapF RkkgUEFSVAAAAQAAAgAAMRkXtQAAAAABAAAAAAAAAK9tcHQAAAAAIgAAAAAAAACObXB0AAAAACZt 3JrPI0NCpdudjLIely4CAAAAAAAAAAkAAACAAAAAq3oSRwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMOM iWrSHbIRmaYIACBzZjGmcKQHqLRNDvuw/QGuvBQ+AAEAAAAAAACOLXB0AAAAAAAAAAAAAAAAegBm AHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7WpRq 0h2yEZmmCAAgc2YxqNsegL5IRk2uYPtqnZm6LI8tcHQAAAAAjm1wdAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --0016e6d77ed32966ad0476c52798-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 25 19:54:53 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D14DF1065670 for ; Sun, 25 Oct 2009 19:54:53 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out1.tiscali.nl (smtp-out1.tiscali.nl [195.241.79.176]) by mx1.freebsd.org (Postfix) with ESMTP id 93B158FC12 for ; Sun, 25 Oct 2009 19:54:53 +0000 (UTC) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out1.tiscali.nl with esmtp (Exim) (envelope-from ) id 1N29Ay-0000xN-9S for freebsd-stable@freebsd.org; Sun, 25 Oct 2009 20:54:52 +0100 Received: from 82-170-177-25.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id DC65B13B63 for ; Sun, 25 Oct 2009 20:54:48 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Date: Sun, 25 Oct 2009 20:54:48 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/10.00 (FreeBSD) Content-Transfer-Encoding: quoted-printable Subject: zfs receive gives: internal error: Argument list too long X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 19:54:53 -0000 Hi, Making a backup to my external USB-disk now fails with the following =20 output. [root@sjakie ~]# zfs send -vi tank/home@repl-20090919_195900 =20 tank/home@repl-20090921_195900 > /bla.snapshot # ls -lh /bla* -rw-r--r-- 1 root wheel 547M Oct 25 20:44 /bla.snapshot [root@sjakie ~]# zfs receive -F extern/home < /bla.snapshot internal error: Argument list too long Abort trap: 6 (core dumped) # uname -a FreeBSD sjakie.klop.ws 8.0-RC1 FreeBSD 8.0-RC1 #6: Wed Oct 21 00:57:07 =20 CEST 2009 root@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC amd64 I have two pools 'tank' and 'extern'. I send/recieve several volumes from= =20 tank to extern. zpool is version 13 and zfs is version 3 Searching the internet I found this link: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=3D6573681 Is this a known bug for freebsd also? Can anybody help me in continuing my snapshotting process? (Except making= =20 a new fresh snapshot, which is my last option.) Ronald. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 25 19:58:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCC251065725 for ; Sun, 25 Oct 2009 19:58:39 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out0.tiscali.nl (smtp-out0.tiscali.nl [195.241.79.175]) by mx1.freebsd.org (Postfix) with ESMTP id 5FFB18FC0A for ; Sun, 25 Oct 2009 19:58:39 +0000 (UTC) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out0.tiscali.nl with esmtp (Exim) (envelope-from ) id 1N29Ec-0004oi-8r for freebsd-stable@freebsd.org; Sun, 25 Oct 2009 20:58:38 +0100 Received: from 82-170-177-25.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 1D83113B77 for ; Sun, 25 Oct 2009 20:58:35 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "freebsd-stable@freebsd.org" References: Date: Sun, 25 Oct 2009 20:58:34 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/10.00 (FreeBSD) Content-Transfer-Encoding: quoted-printable Subject: Re: zfs receive gives: internal error: Argument list too long X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 19:58:39 -0000 On Sun, 25 Oct 2009 20:54:48 +0100, Ronald Klop =20 wrote: > Hi, > > Making a backup to my external USB-disk now fails with the following =20 > output. > > [root@sjakie ~]# zfs send -vi tank/home@repl-20090919_195900 =20 > tank/home@repl-20090921_195900 > /bla.snapshot > > # ls -lh /bla* > -rw-r--r-- 1 root wheel 547M Oct 25 20:44 /bla.snapshot > > [root@sjakie ~]# zfs receive -F extern/home < /bla.snapshot > internal error: Argument list too long > Abort trap: 6 (core dumped) > > # uname -a > FreeBSD sjakie.klop.ws 8.0-RC1 FreeBSD 8.0-RC1 #6: Wed Oct 21 00:57:07 = =20 > CEST 2009 root@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC amd64 > > I have two pools 'tank' and 'extern'. I send/recieve several volumes =20 > from tank to extern. > zpool is version 13 and zfs is version 3 > > Searching the internet I found this link: > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=3D6573681 I meant: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=3D680= 1979 > Is this a known bug for freebsd also? > Can anybody help me in continuing my snapshotting process? (Except =20 > making a new fresh snapshot, which is my last option.) > > Ronald. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 25 21:39:30 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2B461065670 for ; Sun, 25 Oct 2009 21:39:30 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id 5F8D88FC13 for ; Sun, 25 Oct 2009 21:39:29 +0000 (UTC) Received: by fxm6 with SMTP id 6so10945636fxm.43 for ; Sun, 25 Oct 2009 14:39:29 -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=g2p44/tT8gzDiDhisMRSVjgIKCj1BCeDBN2RwVq1VYY=; b=mBXhD6nb/tNX4SOgUdpbyR7dq91eA6VXv6unXXgVD3B+vbU+DiiagAStLXXEmA5tg9 14doe7m/DnRTSaOVQAUBObIsfSWqwMidURpAWxyFZG9CLaA4ZDYnZcH9Dybnp1wZBGUi /CuAFX21MzggKtFcquhEgR7fsHA+LAlIXOmOk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Hxl2ghnzBrpflU5YUMJuKFR1YSQgZUvUH/n2VTMXiZl1WWV51Bz4fmr9G+IHOvIkmM yxLwJm5r508oB9kqYqr9xnSIwyusEXxO+ponU5qLIk01vRDfqxeW5zP25dwhCq3e1j2f Rsop05aLnNNN4MYEGDfAH8O8pl9W2KZlV6bRE= MIME-Version: 1.0 Received: by 10.223.16.72 with SMTP id n8mr399413faa.26.1256506768316; Sun, 25 Oct 2009 14:39:28 -0700 (PDT) Date: Sun, 25 Oct 2009 17:39:28 -0400 Message-ID: <4ad871310910251439x781a462cq96c98cee1a4806f7@mail.gmail.com> From: Glen Barber To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: [panic] Finally got a crash report X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 21:39:30 -0000 Howdy, Since I got this laptop, I've been having some issues I could not track. Usually the system will completely lock up, no keyboard, mouse, etc, leaving me with no way to break to the debugger, forcing me to power off completely. Something changed recently, and although the machine locked up again, I was able to get a crash report[1]. The kernel config the crash report mentions is available as well[2]. I can usually trigger it with excessive disk IO, but this time I was editing a file in Vim. Any thoughts? [1] - http://freebsd.dev-urandom.com/ports/20091025.core.txt [2] - http://freebsd.dev-urandom.com/ports/PEGASUS -- Glen Barber From owner-freebsd-stable@FreeBSD.ORG Sun Oct 25 22:51:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75E30106566B for ; Sun, 25 Oct 2009 22:51:26 +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 2490F8FC16 for ; Sun, 25 Oct 2009 22:51:25 +0000 (UTC) Received: from [192.168.1.4] (adsl-150-102-19.bna.bellsouth.net [72.150.102.19]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9PMpMCE019207 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 25 Oct 2009 18:51:23 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Kris Weston In-Reply-To: <72d267bc0910250944y298d9535x9eac8cf9ba7a9b27@mail.gmail.com> References: <72d267bc0910210511t4a54ce3dm1490fec593377a44@mail.gmail.com> <1256303940.2283.15.camel@balrog.2hip.net> <72d267bc0910250944y298d9535x9eac8cf9ba7a9b27@mail.gmail.com> Content-Type: multipart/mixed; boundary="=-jTyFCLYYyabgYp5o2B1D" Organization: FreeBSD Date: Sun, 25 Oct 2009 17:51:17 -0500 Message-Id: <1256511077.2502.181.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, 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-stable@freebsd.org Subject: Re: i am desperate over some GPT tables X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 22:51:26 -0000 --=-jTyFCLYYyabgYp5o2B1D Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2009-10-25 at 16:44 +0000, Kris Weston wrote: > hi Robert appreciate you having a look at this, > if you need any funny noises ever, give us a shout :) > i really dont know what to do as i dont have a spare box to try out solaris > on and solaris wont boot fully here... > i did manage to export the drives from solaris first so all *should* be > well... > there are three disks in the set ad4,ad6,ad8 > terrabyte each - they are supposed to be two mirrors but one disk went down > should still work though - well was working in solaris... > as i said before it at least could read the pools from freebsd before but > something has happened now where it wont... > > i think 4+6 are a mirror... > let me know if you can shed any light... > out of interest - how do you look at these dumps ? and what are you looking > for ? Ok, we have a couple of options.... What I have done so far is to hex edit your GPT headers, though technically they are valid. Sector 2 is the GPT header and normally the header length is recorded as 92 bytes. Yours claim that the header it 512 bytes or the entire sector. The crc32 value is calculated based on byte 0 - header size. Our GPT code is performing the crc comparison based on the 92 valid bytes in the header along with 512 - 92 bytes of random memory, so the header crc fails and GEOM refuses the header. We need to fix the GPT code to handle this correctly, so you can give me a little time to fix it correctly, or we can just fix your existing GPT headers to work with our code... Before: GEOM: md6: corrupt or invalid GPT detected. GEOM: md6: GPT rejected -- may not be recoverable. After: GEOM: md6: the secondary GPT table is corrupt or invalid. GEOM: md6: using the primary only -- recovery suggested. => 34 1953525101 md6 GPT (466T) 34 222 - free - (111K) 256 1953508495 1 !6a898cc3-1dd2-11b2-99a6-080020736631 (932G) 1953508751 16384 9 !6a945a3b-1dd2-11b2-99a6-080020736631 (8.0M) Hopefully I don't need to tell you proceed with caution here, but if you want to rewrite the headers, I've attached 6 files which contain the modified primary and secondary headers. The seek values below for the secondary header are calculated for your drive. Make sure that you use the correct header for the correct drive and pri/sec. dd if=headeradX-pri.dmp of=/dev/adX bs=512 seek=1 dd if=headeradX-sec.dmp of=/dev/adX bs=512 seek=1953525167 robert. > thanks > > Kris > -- > > )) > (( > c[_] > > > 2009/10/23 Robert Noland > > > On Wed, 2009-10-21 at 13:11 +0100, Kris Weston wrote: > > > been looking for months now, trawled google no help, i just dont > > understand. > > > do you need a GPT table with zfs ? > > > i have a pentium D 3ghz (running 64bit stable 7.2) and i cant seem to > > import > > > my zpool into it > > > exported fine on solaris , its definitely the same version (v13) > > > but when i import into zfs it says GPT tables corrupt ? > > > why ? and what does this mean ? > > > please help me. pleeeeease. > > > > Send me the fist 34 sectors of the disk and I will try to take a look. > > > > dd if= of=header.dmp bs=512 count=34 > > > > robert. > > > > > -- > > > > > > )) > > > (( > > > c[_] > > > _______________________________________________ > > > freebsd-stable@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > > " > > -- > > Robert Noland > > FreeBSD > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD --=-jTyFCLYYyabgYp5o2B1D Content-Disposition: attachment; filename="headerad4-pri.dmp" Content-Type: application/octet-stream; name="headerad4-pri.dmp" Content-Transfer-Encoding: base64 RUZJIFBBUlQAAAEAXAAAAEbQMF8AAAAAAQAAAAAAAACvbXB0AAAAACIAAAAAAAAAjm1wdAAAAAC7 7oU/ba1HNamP29qfNAoUAgAAAAAAAAAJAAAAgAAAAOr89nUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --=-jTyFCLYYyabgYp5o2B1D Content-Disposition: attachment; filename="headerad4-sec.dmp" Content-Type: application/octet-stream; name="headerad4-sec.dmp" Content-Transfer-Encoding: base64 RUZJIFBBUlQAAAEAXAAAAKRorfwAAAAAr21wdAAAAAABAAAAAAAAACIAAAAAAAAAjm1wdAAAAAC7 7oU/ba1HNamP29qfNAoUj21wdAAAAAAJAAAAgAAAAOr89nUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --=-jTyFCLYYyabgYp5o2B1D Content-Disposition: attachment; filename="headerad6-pri.dmp" Content-Type: application/octet-stream; name="headerad6-pri.dmp" Content-Transfer-Encoding: base64 RUZJIFBBUlQAAAEAXAAAAKqFhMMAAAAAAQAAAAAAAACvbXB0AAAAACIAAAAAAAAAjm1wdAAAAAAG IlhWdrtKfqeG8j6VaDMXAgAAAAAAAAAJAAAAgAAAACqQTPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --=-jTyFCLYYyabgYp5o2B1D Content-Disposition: attachment; filename="headerad6-sec.dmp" Content-Type: application/octet-stream; name="headerad6-sec.dmp" Content-Transfer-Encoding: base64 RUZJIFBBUlQAAAEAXAAAAEg9GWAAAAAAr21wdAAAAAABAAAAAAAAACIAAAAAAAAAjm1wdAAAAAAG IlhWdrtKfqeG8j6VaDMXj21wdAAAAAAJAAAAgAAAACqQTPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --=-jTyFCLYYyabgYp5o2B1D Content-Disposition: attachment; filename="headerad8-pri.dmp" Content-Type: application/octet-stream; name="headerad8-pri.dmp" Content-Transfer-Encoding: base64 RUZJIFBBUlQAAAEAXAAAALRJqHkAAAAAAQAAAAAAAACvbXB0AAAAACIAAAAAAAAAjm1wdAAAAAAm bdyazyNDQqXbnYyyHpcuAgAAAAAAAAAJAAAAgAAAAKt6EkcAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --=-jTyFCLYYyabgYp5o2B1D Content-Disposition: attachment; filename="headerad8-sec.dmp" Content-Type: application/octet-stream; name="headerad8-sec.dmp" Content-Transfer-Encoding: base64 RUZJIFBBUlQAAAEAXAAAAFbxNdoAAAAAr21wdAAAAAABAAAAAAAAACIAAAAAAAAAjm1wdAAAAAAm bdyazyNDQqXbnYyyHpcuj21wdAAAAAAJAAAAgAAAAKt6EkcAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --=-jTyFCLYYyabgYp5o2B1D-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 11:20:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF2B2106566C for ; Mon, 26 Oct 2009 11:20:13 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 758058FC19 for ; Mon, 26 Oct 2009 11:20:13 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2NcA-000Ktq-D1 for freebsd-stable@freebsd.org; Mon, 26 Oct 2009 11:19:54 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2NcA-0004c4-CE for freebsd-stable@freebsd.org; Mon, 26 Oct 2009 11:19:54 +0000 To: freebsd-stable@freebsd.org Message-Id: From: Pete French Date: Mon, 26 Oct 2009 11:19:54 +0000 Subject: whats best pracfive for ZFS on a whole disc these days ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 11:20:13 -0000 just about to build a new ZFS based system and I was wondering what the recommended way to dedicate a whole disc to ZFS is these days. Should I just give it 'da1', 'da2' etc as I have done in the past, or is it better to use GPT to create a partition over the whole disc, which is marked as being for freebsd-zfs ? Not that I have had any problems with simply using bare drives, but the phrase 'dangerously dedicated' does keep nagging at me, hence considering the GPT route :-) cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 12:36:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5260F1065676 for ; Mon, 26 Oct 2009 12:36:39 +0000 (UTC) (envelope-from rebotados@exemys.com) Received: from web.hostmailing.com (web.hostmailing.com [200.110.145.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7DFA58FC08 for ; Mon, 26 Oct 2009 12:36:38 +0000 (UTC) Received: from web.hostmailing.com ([200.110.145.34] helo=www.hostmailing.com) by web.hostmailing.com with esmtpa (Exim 4.63) (envelope-from ) id 1N2Ojr-0004fp-NK for freebsd-stable@freebsd.org; Mon, 26 Oct 2009 09:31:55 -0300 Date: Mon, 26 Oct 2009 09:31:55 -0300 To: freebsd-stable@freebsd.org From: Exemys Message-ID: X-Priority: 3 X-Mailer: wh4535 [version 4.1] X-Fid: eGZpZC1mcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZy0yMDg3My02NjcxLTgwMjM= MIME-Version: 1.0 Content-Type: text/plain; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Modbus Serial - Modbus TCP/IP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: exemys@exemys.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 12:36:39 -0000 This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 13:10:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C57D51065695 for ; Mon, 26 Oct 2009 13:10:33 +0000 (UTC) (envelope-from arnaud.houdelette@tzim.net) Received: from golanth.tzim.net (unknown [IPv6:2001:41d0:1:d91f:21c:c0ff:fe4b:cf32]) by mx1.freebsd.org (Postfix) with ESMTP id 623B98FC1B for ; Mon, 26 Oct 2009 13:10:33 +0000 (UTC) Received: from alarante.irisa.fr ([131.254.13.244]) by golanth.tzim.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2PLA-0004vP-Bu; Mon, 26 Oct 2009 14:10:28 +0100 Message-ID: <4AE59FBE.6060904@tzim.net> Date: Mon, 26 Oct 2009 14:10:22 +0100 From: Arnaud Houdelette User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jaime Bozza References: <4AE2232E.10406@whotookspaz.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: tzim@tzim.net X-Authenticator: plain Cc: "freebsd-stable@freebsd.org" , Jacob Myers Subject: Re: Possible scheduler (SCHED_ULE) bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:10:33 -0000 Jaime Bozza a écrit : >>> The additional information I have (over the PR) is that: >>> 1) Files over 64K cause the problem, not just larger files >>> >> I thought it was over 1 MB or so. But maybe I'm wrong. ISTR that I >> couldn't trigger it with some images of around 70K. >> > > I discovered it originally with a 72K file. After some tests, I found a 63K file worked and a 65K file didn't. When I get back into the office, I can test the actual boundary (65535, 65536, 65537, etc), but 64K seems pretty logical. > > >>> 2) switching over to SCHED_4BSD eliminates the problem - system no >>> >> longer locks. >> I will have to test this. This is indeed interesting... >> >> >>> 3) 7.2 amd64 doesn't have the problem - Tested a similar >>> >> configuration and was not able to duplicate on amd64 at all. >> I can replicate this problem on FreeBSD 7.2/amd64 reliably. >> > > I haven't tried larger files - Maybe the boundary is different on amd64? Doing some quick tests right now, I was able to upload a 100MB file without a problem, but this is an AMD64 system with SMP, plus the filesystem is all ZFS, so there are too many things different. I'll have to setup a system that closely mirrors the rest of my tests (UFS, ULE, no SMP, etc) before I can say I'm not having a problem there. > > Jaime > I had the same issue using 7.1 amd64, with ZFS, no SMP. Not really sure what is the size boundary. I can't really test either, as the machine is remote. But I confirm that each tentative upload of certain relatively 'big' files (around 1MB) with wordpress hanged the system before I switched from sendfile to writev. I might do some test on amd64 7.2 with no SMP if it can be of any use ? Arnaud From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 13:38:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DFD71065693 for ; Mon, 26 Oct 2009 13:38:05 +0000 (UTC) (envelope-from jacob@whotookspaz.org) Received: from mail-yx0-f103.google.com (mail-yx0-f103.google.com [209.85.210.103]) by mx1.freebsd.org (Postfix) with ESMTP id CBB5D8FC0A for ; Mon, 26 Oct 2009 13:38:04 +0000 (UTC) Received: by yxe1 with SMTP id 1so469711yxe.3 for ; Mon, 26 Oct 2009 06:38:04 -0700 (PDT) Received: by 10.101.5.22 with SMTP id h22mr9098518ani.186.1256564284046; Mon, 26 Oct 2009 06:38:04 -0700 (PDT) Received: from kusanagi.whotookspaz.org (adsl-153-199-151.jax.bellsouth.net [70.153.199.151]) by mx.google.com with ESMTPS id 23sm1359304yxe.0.2009.10.26.06.38.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Oct 2009 06:38:02 -0700 (PDT) Message-ID: <4AE5A631.1030607@whotookspaz.org> Date: Mon, 26 Oct 2009 09:37:53 -0400 From: Jacob Myers User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Arnaud Houdelette References: <4AE2232E.10406@whotookspaz.org> <4AE59FBE.6060904@tzim.net> In-Reply-To: <4AE59FBE.6060904@tzim.net> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig39275124F42FE2405254FE92" Cc: "freebsd-stable@freebsd.org" Subject: Re: Possible scheduler (SCHED_ULE) bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:38:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig39275124F42FE2405254FE92 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Arnaud Houdelette wrote: > I had the same issue using 7.1 amd64, with ZFS, no SMP. > Not really sure what is the size boundary. I can't really test either, > as the machine is remote. > But I confirm that each tentative upload of certain relatively 'big' > files (around 1MB) with wordpress hanged the system before I switched > from sendfile to writev. >=20 > I might do some test on amd64 7.2 with no SMP if it can be of any use ?= >=20 > Arnaud I can confirm it happens without SMP on 7.2 and amd64. If you can give it a try though, well, the more information the better. Any boundary information, even approximate (well, mostly testing if 64K is the boundary or if 1 MB or so is) would probably be good, too. --=20 Jacob Myers | Website: http://whotookspaz.org Network Admin, Wilcox Technologies | Public key: 186A424A Using FreeBSD since 2007 | Public shell: http://bit.ly/42iGCR Answer a fool according to his folly, lest he be wise in his own conceit -- Proverbs, 26:5 --------------enig39275124F42FE2405254FE92 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.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJK5aY1AAoJEA933foYakKko1wQAJtG2x3yWp2VmMlJSvaP2mxC 5EyH+AeTghsRqr1Po6vgPtcZe6B8oS/k4TGeuEXHjjM2zmyQYAprmAR5jsAom6fD nR0miZ8pyhZ/wsiUeU5l3MFPy7exaQlDsFakubVyioW0wkZ5af257y6976Sx69jJ XhGgt3xP0gXnl5Oq4Yt6OridJRH+IOYzpnfgpNdiNIgjDi3gtK+W5pNy/yHcbGM+ kD1ReLsye3cj3V+nl9/z9kWvICwqjtdu9V+VQWENWpemoyQPO0pvlhcoE2dBBDW2 dSQpl4ccmunriM8YE5UuYqDgx7A47rprGsF5TJoWc6uWJfz/KvniySTe88QKpibY e8/tnW52aTAKplTPvJAR7T6Ocgu8BSbk5/9dBCMTMIbBAlm4cPoMZpBAH/jaHU9r csuptyTIuPi2CPPUA8Quxdu/sTja7/oEhJcnIIL+3nM9uwgR1zUEmkCMXXHVh4Np PXW74HuCQ9hebybLyAOr65TNDQRZXWRW4SG7qmiV67FeGD2X8h172NxuSQBpNhkt IBDn7OmUm2+/xA/tjDSi3NHJ1Z8bDrNUCw1ZtuFg2F7i0Oi2ngWdlTyfpWgmTEoW y/gvAYKuA5UZhcpxJshWIC6MLjA6KCMfrBiJ+bZ5RvAX/0OdNCXmCM5j76HETUDj L/RcJqujhZSLNinOn6P1 =vFSO -----END PGP SIGNATURE----- --------------enig39275124F42FE2405254FE92-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 13:53:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 321C4106566C for ; Mon, 26 Oct 2009 13:53:47 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from solfertje.student.utwente.nl (solfertje.student.utwente.nl [130.89.167.40]) by mx1.freebsd.org (Postfix) with ESMTP id DB2788FC1F for ; Mon, 26 Oct 2009 13:53:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by solfertje.student.utwente.nl (Postfix) with SMTP id 1374C803E for ; Mon, 26 Oct 2009 14:53:44 +0100 (CET) Received: from hollewijn.internal (hollewijn.internal [10.236.150.4]) by solfertje.student.utwente.nl (Postfix) with ESMTP id 27F6E8034 for ; Mon, 26 Oct 2009 14:51:24 +0100 (CET) From: Alban Hertroys Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Mon, 26 Oct 2009 14:51:23 +0100 Message-Id: To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Oct 26 14:53:42 2009 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 74,4ae5a9e512191499454227 X-DSPAM-Factors: 27, but, 0.01000, From*Alban, 0.01000, Mime-Version*Message, 0.01000, Received*ESMTP, 0.01000, Alban+Hertroys, 0.01000, Mime-Version*1.0+(Apple, 0.01000, Hertroys, 0.01000, From*Hertroys, 0.01000, From*solfertje.student.utwente.nl>, 0.01000, Received*with, 0.01000, Content-Type*delsp=yes, 0.01000, Received*id, 0.01000, Received*ESMTP+id, 0.01000, Alban, 0.01000, there, 0.01000, Received*[10.236.150.4]), 0.01000, Date*2009, 0.01000, From*Hertroys+, 0.01000, I, 0.01000, I, 0.01000, after, 0.01000, Received*(Postfix)+with, 0.01000, is, 0.01000, is, 0.01000, From*, 0.01000, to, 0.01000 Subject: NULL-pointer reference in ulpt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:53:47 -0000 I didn't get any replies to my previous report, so I'm trying again. I frequently get a kernel-panic after printing something to my USB printer (A Samsung ML-1210). It looks like usb_setup_xfer() is called with a NULL-pointer for xfer from ulpt_tick(). System is a 7.2-STABLE, last updated on Sep 15. I just did a make update, but there were no changes to ulpt.c. The core-summary is available from http://solfertje.student.utwente.nl/~dalroi/core.txt Alban Hertroys -- Screwing up is the best way to attach something to the ceiling. !DSPAM:74,4ae5a9e512191499454227! From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 13:55:18 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 105091065693 for ; Mon, 26 Oct 2009 13:55:18 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id C2D6E8FC15 for ; Mon, 26 Oct 2009 13:55:17 +0000 (UTC) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Mon, 26 Oct 2009 09:55:15 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::158 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@FreeBSD.org X-SMFBL: ZnJlZWJzZC1zdGFibGVARnJlZUJTRC5vcmc= Message-ID: <4AE5AA43.7030405@comcast.net> Date: Mon, 26 Oct 2009 09:55:15 -0400 From: Steve Polyack User-Agent: Thunderbird 2.0.0.23 (X11/20090902) MIME-Version: 1.0 To: Alexander Motin References: <4AE04F73.1050703@comcast.net> <4AE073CF.40500@comcast.net> <4AE099D8.5060103@FreeBSD.org> In-Reply-To: <4AE099D8.5060103@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------070703010804050102070907" Cc: freebsd-stable , freebsd-hardware@freebsd.org Subject: Re: FreeBSD and SATA Port Multipliers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:55:18 -0000 This is a multi-part message in MIME format. --------------070703010804050102070907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alexander Motin wrote: > Steve Polyack wrote: > >> Alexander Motin wrote: >> >>> You can try this patch against today's HEAD: >>> http://people.freebsd.org/~mav/cam-ata.20091022.patch >>> >>> >> I tried the patch this morning against a fresh checkout of HEAD. >> Immediately after boot only one device per PM was detected (I have two >> hooked up at the moment, 5 drives on one, 1 on the other). However, >> about two minutes later all of the drives showed up! >> >> camcontrol also rescans the entire bus *very* quickly now, and discovers >> all changes (new/missing disks and port multipliers). >> >> Here's some verbose info from /var/log/messages immediately after boot: >> Oct 22 10:52:03 lovepod kernel: siisch0: Timeout on slot 27 >> Oct 22 10:52:03 lovepod kernel: siisch0: siis_timeout is 00000000 ss >> 08000000 rs 08000000 es 00000000 sts 801b2000 serr 00000000 >> Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms >> Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms >> Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset... >> Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms >> Oct 22 10:52:03 lovepod kernel: siisch0: hardware reset ... >> Oct 22 10:52:03 lovepod kernel: siisch0: SATA connect timeout >> status=00000001 >> Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset done: phy reset >> found no device >> Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Command timed out >> Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): error 5 >> Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Retries Exhausted >> Oct 22 10:52:03 lovepod kernel: siisch0: DISCONNECT requested >> > > What was before that? Can you send me full verbose boot messages? > > Here's a full dmesg from today using the 10/22/2009 head and patch. It actually failed to detect all but one of 6 drives this time. I'm about to try today's head and patch. I'll let you know how it goes. --------------070703010804050102070907 Content-Type: text/plain; name="dmesg.20091022patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.20091022patch" 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 9.0-CURRENT #2: Thu Oct 22 10:34:44 EDT 2009 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff809e7000. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff809e7260. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2133421704 Hz CPU: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz (2133.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Stepping = 5 Features=0xbfebfbff Features2=0x9ce3bd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4299161600 (4100 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000093fff, 602112 bytes (147 pages) 0x0000000000a16000 - 0x00000000b60fffff, 3043926016 bytes (743146 pages) 0x00000000bf78e000 - 0x00000000bf78ffff, 8192 bytes (2 pages) 0x0000000100000000 - 0x000000013ffeffff, 1073676288 bytes (262128 pages) avail memory = 4095377408 (3905 MB) ACPI APIC Table: <061909 APIC1420> INTR: Adding local APIC 18 as a target INTR: Adding local APIC 20 as a target INTR: Adding local APIC 22 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 18 cpu2 (AP): APIC ID: 20 cpu3 (AP): APIC ID: 22 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xfa710 00024 (v2 ACPIAM) ACPI: XSDT 0xbf790100 0008C (v1 NEC 20090619 MSFT 00000097) ACPI: FACP 0xbf790290 000F4 (v4 061909 FACP1420 20090619 MSFT 00000097) ACPI: DSDT 0xbf790670 05B8F (v2 10006 10006000 00000000 INTL 20051117) ACPI: FACS 0xbf79e000 00040 ACPI: APIC 0xbf790390 000D2 (v2 061909 APIC1420 20090619 MSFT 00000097) ACPI: MCFG 0xbf790470 0003C (v1 061909 OEMMCFG 20090619 MSFT 00000097) ACPI: SLIC 0xbf7904b0 00176 (v1 NEC 20090619 MSFT 00000097) ACPI: ERST 0xbf790630 00040 (v1 061909 WHEA1420 20090619 MSFT 00000097) ACPI: OEMB 0xbf79e040 0007B (v1 061909 OEMB1420 20090619 MSFT 00000097) ACPI: HPET 0xbf79a670 00038 (v1 061909 OEMHPET 20090619 MSFT 00000097) ACPI: DMAR 0xbf79e0c0 00120 (v1 AMI OEMDMAR 00000001 MSFT 00000097) ACPI: SSDT 0xbf79efb0 00363 (v1 DpgPmm CpuPm 00000012 INTL 20051117) ACPI: EINJ 0xbf79a6b0 00130 (v1 AMIER AMI_EINJ 20090619 MSFT 00000097) ACPI: BERT 0xbf79a840 00030 (v1 AMIER AMI_BERT 20090619 MSFT 00000097) ACPI: ERST 0xbf79a870 001B0 (v1 AMIER AMI_ERST 20090619 MSFT 00000097) ACPI: HEST 0xbf79aa20 000A8 (v1 AMIER AMI_HEST 20090619 MSFT 00000097) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 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 lapic: Routing NMI -> LINT1 lapic: LINT1 trigger: edge lapic: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x10000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010400 nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: null: io: random: acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 16 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0 ACPI timer: 1/2 1/2 1/1 1/0 1/0 1/2 1/0 1/0 1/1 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 3 4 6 7 10 11 12 14 15 Validation 0 14 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 6 7 10 11 12 14 15 Validation 0 7 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 6 7 10 11 12 14 15 Validation 0 6 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff iomem 0xfed40000-0xfed44fff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x3403, revid=0x13 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x3408, revid=0x13 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340a, revid=0x13 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340e, revid=0x13 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x3410, revid=0x13 domain=0, bus=0, slot=9, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x342e, revid=0x13 domain=0, bus=0, slot=20, func=0 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3422, revid=0x13 domain=0, bus=0, slot=20, func=1 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3423, revid=0x13 domain=0, bus=0, slot=20, func=2 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3438, revid=0x13 domain=0, bus=0, slot=20, func=3 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3430, revid=0x13 domain=0, bus=0, slot=22, func=0 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacfc000, size 14, enabled pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3431, revid=0x13 domain=0, bus=0, slot=22, func=1 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacf8000, size 14, enabled pcib0: matched entry for 0.22.INTB pcib0: slot 22 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3432, revid=0x13 domain=0, bus=0, slot=22, func=2 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacf4000, size 14, enabled pcib0: matched entry for 0.22.INTC pcib0: slot 22 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3433, revid=0x13 domain=0, bus=0, slot=22, func=3 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=14 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacf0000, size 14, enabled pcib0: matched entry for 0.22.INTD pcib0: slot 22 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3429, revid=0x13 domain=0, bus=0, slot=22, func=4 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacec000, size 14, enabled pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x342a, revid=0x13 domain=0, bus=0, slot=22, func=5 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xface8000, size 14, enabled pcib0: matched entry for 0.22.INTB pcib0: slot 22 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x342b, revid=0x13 domain=0, bus=0, slot=22, func=6 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xface4000, size 14, enabled pcib0: matched entry for 0.22.INTC pcib0: slot 22 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x342c, revid=0x13 domain=0, bus=0, slot=22, func=7 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=14 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xface0000, size 14, enabled pcib0: matched entry for 0.22.INTD pcib0: slot 22 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a37, revid=0x00 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0xbc00, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3a38, revid=0x00 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 map[20]: type I/O Port, range 32, base 0xb880, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x3a39, revid=0x00 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=14 map[20]: type I/O Port, range 32, base 0xb800, size 5, enabled pcib0: matched entry for 0.26.INTD pcib0: slot 26 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a3c, revid=0x00 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfacde000, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfacde000 found-> vendor=0x8086, dev=0x3a3e, revid=0x00 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfacd8000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x3a40, revid=0x00 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a48, revid=0x00 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a4a, revid=0x00 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3a34, revid=0x00 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0xb480, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x3a35, revid=0x00 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=14 map[20]: type I/O Port, range 32, base 0xb400, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a36, revid=0x00 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[20]: type I/O Port, range 32, base 0xb080, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3a3a, revid=0x00 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfacdc000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfacdc000 found-> vendor=0x8086, dev=0x244e, revid=0x90 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x1a (6500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a16, revid=0x00 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a22, revid=0x00 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=14 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0xb000, size 3, enabled map[14]: type I/O Port, range 32, base 0xac00, size 2, enabled map[18]: type I/O Port, range 32, base 0xa880, size 3, enabled map[1c]: type I/O Port, range 32, base 0xa800, size 2, enabled map[20]: type I/O Port, range 32, base 0xa480, size 5, enabled map[24]: type Memory, range 32, base 0xfacd2000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a30, revid=0x00 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[10]: type Memory, range 64, base 0xfacd0000, size 8, enabled map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: at device 3.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: at device 7.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 4 pcib3: I/O decode 0xc000-0xcfff pcib3: memory decode 0xfad00000-0xfadfffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x12d8, dev=0xe111, revid=0x02 domain=0, bus=3, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 pcib4: irq 16 at device 0.0 on pci3 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xc000-0xcfff pcib4: memory decode 0xfad00000-0xfadfffff pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x1095, dev=0x3124, revid=0x01 domain=0, bus=4, slot=4, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x01df, statreg=0x02b0, cachelnsz=64 (dwords) lattimer=0x40 (1920 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, 64 bit map[10]: type Memory, range 64, base 0xfadfe000, size 7, enabled pcib4: requested memory range 0xfadfe000-0xfadfe07f: good pcib3: requested memory range 0xfadfe000-0xfadfe07f: good map[18]: type Memory, range 64, base 0xfadf0000, size 15, enabled pcib4: requested memory range 0xfadf0000-0xfadf7fff: good pcib3: requested memory range 0xfadf0000-0xfadf7fff: good map[20]: type I/O Port, range 32, base 0xcc00, size 4, enabled pcib4: requested I/O range 0xcc00-0xcc0f: in range pcib3: requested I/O range 0xcc00-0xcc0f: in range pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 pcib4: slot 4 INTA is routed to irq 16 siis0: port 0xcc00-0xcc0f mem 0xfadfe000-0xfadfe07f,0xfadf0000-0xfadf7fff irq 16 at device 4.0 on pci4 siis0: Reserved 0x80 bytes for rid 0x10 type 3 at 0xfadfe000 siis0: Reserved 0x8000 bytes for rid 0x18 type 3 at 0xfadf0000 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 16 vector 49 siis0: [MPSAFE] siis0: [ITHREAD] siisch0: at channel 0 on siis0 siisch0: [MPSAFE] siisch0: [ITHREAD] siisch1: at channel 1 on siis0 siisch1: [MPSAFE] siisch1: [ITHREAD] siisch2: at channel 2 on siis0 siisch2: [MPSAFE] siisch2: [ITHREAD] siisch3: at channel 3 on siis0 siisch3: [MPSAFE] siisch3: [ITHREAD] pcib5: at device 9.0 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0x0-0x0 pcib5: no prefetched decode pci5: on pcib5 pci5: domain=0, physical bus=5 pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) pci0: at device 22.2 (no driver attached) pci0: at device 22.3 (no driver attached) pci0: at device 22.4 (no driver attached) pci0: at device 22.5 (no driver attached) pci0: at device 22.6 (no driver attached) pci0: at device 22.7 (no driver attached) uhci0: port 0xbc00-0xbc1f irq 16 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbc00 uhci0: [MPSAFE] uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xb880-0xb89f irq 21 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb880 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 16 vector 50 uhci1: [MPSAFE] uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xb800-0xb81f irq 19 at device 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb800 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 16 vector 51 uhci2: [MPSAFE] uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xfacde000-0xfacde3ff irq 18 at device 26.7 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 16 vector 52 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pci0: at device 27.0 (no driver attached) pcib6: irq 17 at device 28.0 on pci0 pcib6: domain 0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: I/O decode 0x0-0x0 pcib6: no prefetched decode pci6: on pcib6 pci6: domain=0, physical bus=6 pcib7: irq 17 at device 28.4 on pci0 pcib7: domain 0 pcib7: secondary bus 7 pcib7: subordinate bus 7 pcib7: I/O decode 0xd000-0xdfff pcib7: memory decode 0xfae00000-0xfaefffff pcib7: no prefetched decode pci7: on pcib7 pci7: domain=0, physical bus=7 found-> vendor=0x8086, dev=0x10d3, revid=0x00 domain=0, bus=7, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (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 MSI-X supports 5 messages in map 0x1c map[10]: type Memory, range 32, base 0xfaee0000, size 17, enabled pcib7: requested memory range 0xfaee0000-0xfaefffff: good map[18]: type I/O Port, range 32, base 0xdc00, size 5, enabled pcib7: requested I/O range 0xdc00-0xdc1f: in range map[1c]: type Memory, range 32, base 0xfaedc000, size 14, enabled pcib7: requested memory range 0xfaedc000-0xfaedffff: good pcib7: matched entry for 7.0.INTA pcib7: slot 0 INTA hardwired to IRQ 16 em0: port 0xdc00-0xdc1f mem 0xfaee0000-0xfaefffff,0xfaedc000-0xfaedffff irq 16 at device 0.0 on pci7 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfaee0000 em0: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xfaedc000 em0: attempting to allocate 3 MSI-X vectors (5 supported) msi: routing MSI-X IRQ 256 to local APIC 16 vector 53 msi: routing MSI-X IRQ 257 to local APIC 16 vector 54 msi: routing MSI-X IRQ 258 to local APIC 16 vector 55 em0: using IRQs 256-258 for MSI-X em0: Using MSIX interrupts em0: [MPSAFE] em0: [ITHREAD] em0: [MPSAFE] em0: [ITHREAD] em0: [MPSAFE] em0: [ITHREAD] em0: bpf attached em0: Ethernet address: 00:30:48:db:7d:9e pcib8: irq 16 at device 28.5 on pci0 pcib8: domain 0 pcib8: secondary bus 8 pcib8: subordinate bus 8 pcib8: I/O decode 0xe000-0xefff pcib8: memory decode 0xfaf00000-0xfaffffff pcib8: no prefetched decode pci8: on pcib8 pci8: domain=0, physical bus=8 found-> vendor=0x8086, dev=0x10d3, revid=0x00 domain=0, bus=8, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 5 messages in map 0x1c map[10]: type Memory, range 32, base 0xfafe0000, size 17, enabled pcib8: requested memory range 0xfafe0000-0xfaffffff: good map[18]: type I/O Port, range 32, base 0xec00, size 5, enabled pcib8: requested I/O range 0xec00-0xec1f: in range map[1c]: type Memory, range 32, base 0xfafdc000, size 14, enabled pcib8: requested memory range 0xfafdc000-0xfafdffff: good pcib8: matched entry for 8.0.INTA pcib8: slot 0 INTA hardwired to IRQ 17 em1: port 0xec00-0xec1f mem 0xfafe0000-0xfaffffff,0xfafdc000-0xfafdffff irq 17 at device 0.0 on pci8 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfafe0000 em1: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xfafdc000 em1: attempting to allocate 3 MSI-X vectors (5 supported) msi: routing MSI-X IRQ 259 to local APIC 16 vector 56 msi: routing MSI-X IRQ 260 to local APIC 16 vector 57 msi: routing MSI-X IRQ 261 to local APIC 16 vector 58 em1: using IRQs 259-261 for MSI-X em1: Using MSIX interrupts em1: [MPSAFE] em1: [ITHREAD] em1: [MPSAFE] em1: [ITHREAD] em1: [MPSAFE] em1: [ITHREAD] em1: bpf attached em1: Ethernet address: 00:30:48:db:7d:9f uhci3: port 0xb480-0xb49f irq 23 at device 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb480 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 16 vector 59 uhci3: [MPSAFE] uhci3: [ITHREAD] uhci3: LegSup = 0x3f00 usbus4: on uhci3 uhci4: port 0xb400-0xb41f irq 19 at device 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb400 uhci4: [MPSAFE] uhci4: [ITHREAD] uhci4: LegSup = 0x2f00 usbus5: on uhci4 uhci5: port 0xb080-0xb09f irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb080 uhci5: [MPSAFE] uhci5: [ITHREAD] uhci5: LegSup = 0x2f00 usbus6: on uhci5 ehci1: mem 0xfacdc000-0xfacdc3ff irq 23 at device 29.7 on pci0 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib9: at device 30.0 on pci0 pcib9: domain 0 pcib9: secondary bus 9 pcib9: subordinate bus 9 pcib9: I/O decode 0xf000-0xfff pcib9: memory decode 0xfb000000-0xfbefffff pcib9: prefetched decode 0xf9000000-0xf9ffffff pcib9: Subtractively decoded bridge. pci9: on pcib9 pci9: domain=0, physical bus=9 found-> vendor=0x102b, dev=0x0532, revid=0x0a domain=0, bus=9, slot=1, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=64 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x20 (8000 ns) intpin=a, irq=15 powerspec 1 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xf9000000, size 24, enabled pcib9: requested memory range 0xf9000000-0xf9ffffff: good map[14]: type Memory, range 32, base 0xfbefc000, size 14, enabled pcib9: requested memory range 0xfbefc000-0xfbefffff: good map[18]: type Memory, range 32, base 0xfb000000, size 23, enabled pcib9: requested memory range 0xfb000000-0xfb7fffff: good pcib9: matched entry for 9.1.INTA pcib9: slot 1 INTA hardwired to IRQ 18 vgapci0: mem 0xf9000000-0xf9ffffff,0xfbefc000-0xfbefffff,0xfb000000-0xfb7fffff irq 18 at device 1.0 on pci9 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xb000-0xb007,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa49f mem 0xfacd2000-0xfacd27ff irq 19 at device 31.2 on pci0 ahci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfacd2000 ahci0: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 262 to local APIC 16 vector 64 ahci0: using IRQ 262 for MSI ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC EM eSATA 6ports ahci0: Caps2: ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [MPSAFE] ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [MPSAFE] ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [MPSAFE] ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [MPSAFE] ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [MPSAFE] ahcich5: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) Calling int 0x15 (ax=0xc000 bx=0x0000 cx=0x0000 dx=0x0000 es=0x0000 di=0x0000) Exiting int 0x15 (ax=0x0000 bx=0xe712 cx=0x0000 dx=0x0000 es=0xf000 di=0x0000) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 16 vector 60 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 16 vector 61 uart0: [FILTER] uart0: fast interrupt uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 16 vector 62 uart1: [FILTER] uart1: fast interrupt cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 6E, should be 6B (20091013/tbutils-354) ACPI: SSDT 0xbf79e1e0 008F0 (v1 DpgPmm P001Ist 00000011 INTL 20051117) ACPI: SSDT 0xbf79ead0 004D5 (v1 PmRef P001Cst 00003001 INTL 20051117) est0: on cpu0 est0: Invalid id16 (set, cur) = (15, 16) est0: Invalid freq 2000, ignored. est0: Invalid id16 (set, cur) = (14, 16) est0: Invalid freq 1867, ignored. est0: Invalid id16 (set, cur) = (13, 16) est0: Invalid freq 1733, ignored. est0: Invalid id16 (set, cur) = (12, 16) est0: Invalid freq 1600, ignored. p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est1: Invalid id16 (set, cur) = (15, 16) est1: Invalid freq 2000, ignored. est1: Invalid id16 (set, cur) = (14, 16) est1: Invalid freq 1867, ignored. est1: Invalid id16 (set, cur) = (13, 16) est1: Invalid freq 1733, ignored. est1: Invalid id16 (set, cur) = (12, 16) est1: Invalid freq 1600, ignored. p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est2: Invalid id16 (set, cur) = (15, 16) est2: Invalid freq 2000, ignored. est2: Invalid id16 (set, cur) = (14, 16) est2: Invalid freq 1867, ignored. est2: Invalid id16 (set, cur) = (13, 16) est2: Invalid freq 1733, ignored. est2: Invalid id16 (set, cur) = (12, 16) est2: Invalid freq 1600, ignored. p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est3: Invalid id16 (set, cur) = (15, 16) est3: Invalid freq 2000, ignored. est3: Invalid id16 (set, cur) = (14, 16) est3: Invalid freq 1867, ignored. est3: Invalid id16 (set, cur) = (13, 16) est3: Invalid freq 1733, ignored. est3: Invalid id16 (set, cur) = (12, 16) est3: Invalid freq 1600, ignored. p4tcc3: on cpu3 acpi0: wakeup code va 0xffffff8077774000 pa 0x4000 isa_probe_children: disabling PnP devices ipmi0: on isa0 ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it uart: uart1 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 257519 -> 100000 procfs registered lapic: Divisor 2, Frequency 66669427 hz Timecounter "TSC" frequency 2133421704 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attachedsiisch0: CONNECT requested siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 siisch2: CONNECT requested siisch2: SIIS reset... siisch2: ready wait time=1ms siisch2: hardware reset ... siisch2: SATA connect time=0ms status=00000123 siisch2: ready wait time=0ms siisch2: SIIS reset done: devices=00000001 Waiting 15 seconds for SCSI devices to settle siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 siisch1: SIIS reset... siisch1: ready wait time=1ms siisch1: hardware reset ... siisch1: SATA connect timeout status=00000000 siisch1: SIIS reset done: phy reset found no device siisch2: SIIS reset... siisch2: ready wait time=1ms siisch2: hardware reset ... siisch2: SATA connect time=0ms status=00000123 siisch2: ready wait time=0ms siisch2: SIIS reset done: devices=00000001 siisch3: SIIS reset... siisch3: ready wait time=1ms siisch3: hardware reset ... siisch3: SATA connect timeout status=00000000 siisch3: SIIS reset done: phy reset found no device ahcich0: AHCI reset... ahcich0: hardware reset ... ahcich0: SATA connect timeout status=00000000 ahcich0: AHCI reset done: phy reset found no device ahcich1: AHCI reset... ahcich1: hardware reset ... ahcich1: SATA connect time=0ms status=00000123 ahcich1: ready wait time=4ms ahcich1: AHCI reset done: device found ahcich2: AHCI reset... ahcich2: hardware reset ... ahcich2: SATA connect timeout status=00000000 ahcich2: AHCI reset done: phy reset found no device ahcich3: AHCI reset... ahcich3: hardware reset ... ahcich3: SATA connect timeout status=00000000 ahcich3: AHCI reset done: phy reset found no device ahcich4: AHCI reset... ahcich4: hardware reset ... ahcich4: SATA connect timeout status=00000000 ahcich4: AHCI reset done: phy reset found no device ahcich5: AHCI reset... ahcich5: hardware reset ... ahcich5: SATA connect timeout status=00000000 ahcich5: AHCI reset done: phy reset found no device usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ipmi0: IPMI device rev. 1, firmware rev. 1.2, version 2.0 ipmi0: Number of channels 0 ipmi0: Attached watchdog ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ugen1.2: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 ukbd0: on usbus1 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 (aprobe0:siisch0:0:15:0): SIGNATURE: 9669 PM Product ID: 37261095 PM Revision: 00001706 (aprobe2:siisch2:0:15:0): SIGNATURE: 9669 PM Product ID: 37261095 PM Revision: 00001706 (aprobe5:ahcich1:0:0:0): SIGNATURE: 0000 pmp0 at siisch0 bus 0 scbus0 target 15 lun 0 pmp0: ATA/ATAPI-0 device pmp0: 300.000MB/s transfers PM ports: 5 PM RESET 0 PM RESET 1 PM RESET 2 siisch0: SNTF 0x0000 siisch0: SNTF 0x0000 PM RESET 3 PM RESET 4 siisch0: SNTF 0x0000 siisch0: SNTF 0x0000 PM reset done pmp1 at siisch2 bus 0 scbus2 target 15 lun 0 pmp1: ATA/ATAPI-0PM connect done devicePM status: 0 - 00000123 pmp1: 300.000MB/s transfersPM status: 1 - 00000123 PM status: 2 - 00000123 PM status: 3 - 00000123 PM ports: 5 PM status: 4 - 00000123 PM RESET 0 PM RESET 1 PM RESET 2 PM RESET 3 PM RESET 4 PM reset done ada0 at PM connect done GEOM: new disk ada0PM status: 0 - 00000123 ahcich1 bus 0 scbus5 target 0 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: Serial Number 9VM1RYE5 ada0: 300.000MB/s transfers ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing enabled pass0 at siisch0 bus 0 scbus0 target 15 lun 0 pass0: ATA/ATAPI-0 device pass0: 30GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). 0.000MB/s transfersPM status: 1 - 00000000 PM status: 2 - 00000000 PM status: 3 - 00000000 PM status: 4 - 00000000 pass1 at siisch2 bus 0 scbus2 target 15 lun 0 pass1: ATA/ATAPI-0 device pass1: 300.000MB/s transfers pass2 at ahcich1 bus 0 scbus5 target 0 lun 0 pass2: ATA/ATAPI-8 SATA 2.x device pass2: Serial Number 9VM1RYE5 pass2: 300.000MB/s transfers ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x12000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x14000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x16000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 18 vector 48 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 20 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 22 vector 48 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 18 vector 49 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 20 vector 49 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 22 vector 49 msi: Assigning MSI-X IRQ 256 to local APIC 18 vector 50 msi: Assigning MSI-X IRQ 257 to local APIC 20 vector 50 msi: Assigning MSI-X IRQ 258 to local APIC 22 vector 50 msi: Assigning MSI-X IRQ 260 to local APIC 18 vector 51 msi: Assigning MSI-X IRQ 261 to local APIC 20 vector 51 msi: Assigning MSI IRQ 262 to local APIC 22 vector 51 (aprobe1:siisch2:0:0:0): SIGNATURE: 0000 pass3 at siisch2 bus 0 scbus2 target 0 lun 0 pass3: ATA/ATAPI-8 SATA 2.x device pass3: Serial Number 9VS2FGFN pass3: 300.000MB/s transfers ada1 at siisch2 bus 0 scbus2 target 0 lun 0 ada1: ATA/ATAPI-8 SATA 2.x device ada1: Serial Number 9VS2FGFN ada1: 300.000MB/s transfers ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada1: Native Command Queueing enabled GEOM: new disk ada1 Trying to mount root from ufs:/dev/label/OS/rootfs ct_to_ts([2009-10-26 09:41:15]) = 1256550075.000000000 start_init: trying /sbin/init em0: Link is up 1000 Mbps Full Duplex em0: link state changed to UP siisch0: Timeout on slot 26 siisch0: siis_timeout is 00000000 ss 04000000 rs 04000000 es 00000000 sts 801a2000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 (aprobe0:siisch0:0:0:0): Command timed out (aprobe0:siisch0:0:0:0): error 5 (aprobe0:siisch0:0:0:0): Retries Exhausted siisch0: Timeout on slot 27 siisch0: siis_timeout is 00000000 ss 08000000 rs 08000000 es 00000000 sts 801b2000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect timeout status=00000001 siisch0: SIIS reset done: phy reset found no device (aprobe0:siisch0:0:1:0): Command timed out (aprobe0:siisch0:0:1:0): error 5 (aprobe0:siisch0:0:1:0): Retries Exhausted siisch0: DISCONNECT requested siisch0: CONNECT requested siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 siisch0: Timeout on slot 28 siisch0: siis_timeout is 00000000 ss 10000000 rs 10000000 es 00000000 sts 801c2000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect timeout status=00000001 siisch0: SIIS reset done: phy reset found no device (aprobe0:siisch0:0:2:0): Command timed out (aprobe0:siisch0:0:2:0): error 5 (aprobe0:siisch0:0:2:0): Retries Exhausted siisch0: DISCONNECT requested siisch0: CONNECT requested siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 siisch0: Timeout on slot 29 siisch0: siis_timeout is 00000000 ss 20000000 rs 20000000 es 00000000 sts 801d2000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect timeout status=00000001 siisch0: SIIS reset done: phy reset found no device (aprobe0:siisch0:0:3:0): Command timed out (aprobe0:siisch0:0:3:0): error 5 (aprobe0:siisch0:0:3:0): Retries Exhausted siisch0: DISCONNECT requested siisch0: CONNECT requested siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 siisch0: Timeout on slot 30 siisch0: siis_timeout is 00000000 ss 40000000 rs 40000000 es 00000000 sts 801e2000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect timeout status=00000001 siisch0: SIIS reset done: phy reset found no device (aprobe0:siisch0:0:4:0): Command timed out (aprobe0:siisch0:0:4:0): error 5 (aprobe0:siisch0:0:4:0): Retries Exhausted siisch0: DISCONNECT requested siisch0: CONNECT requested siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 PMP freeze: 0 PMP freeze: 1 PMP freeze: 2 PMP freeze: 3 PMP freeze: 4 siisch0: Timeout on slot 0 siisch0: siis_timeout is 00000000 ss 00000001 rs 00000001 es 00000000 sts 80002000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 (pmp0:siisch0:0:15:0): Command timed out (pmp0:siisch0:0:15:0): Retrying Command siisch0: Timeout on slot 1 siisch0: siis_timeout is 00000000 ss 00000002 rs 00000002 es 00000000 sts 80012000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 (pmp0:siisch0:0:15:0): Command timed out (pmp0:siisch0:0:15:0): error 5 (pmp0:siisch0:0:15:0): Retries Exhausted PMP release: 0 PMP release: 1 PMP release: 2 PMP release: 3 PMP release: 4 --------------070703010804050102070907-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 14:01:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 167521065679 for ; Mon, 26 Oct 2009 14:01:00 +0000 (UTC) (envelope-from jbozza@mindsites.com) Received: from mail.thinkburst.com (mail.thinkburst.com [204.49.104.46]) by mx1.freebsd.org (Postfix) with ESMTP id D8D968FC0A for ; Mon, 26 Oct 2009 14:00:59 +0000 (UTC) Received: from mailgate.mindsites.net (gateway.mindsites.net [204.49.104.36]) by mail.thinkburst.com (Postfix) with ESMTP id 2EA331CC27; Mon, 26 Oct 2009 09:00:59 -0500 (CDT) Received: from remote.mindsites.com (unknown [10.1.1.5]) by mailgate.mindsites.net (Postfix) with ESMTP id 0445C17048; Mon, 26 Oct 2009 09:00:58 -0500 (CDT) Received: from ATLAS.msg.local ([fe80::48f5:88b0:6093:4f67]) by ATLAS.msg.local ([fe80::48f5:88b0:6093:4f67%10]) with mapi; Mon, 26 Oct 2009 09:00:58 -0500 From: Jaime Bozza To: Jacob Myers , Arnaud Houdelette Date: Mon, 26 Oct 2009 09:00:57 -0500 Thread-Topic: Possible scheduler (SCHED_ULE) bug? Thread-Index: AcpWQY+77MX5OvaNRAepTPbFbw1qagAAEG3Q Message-ID: References: <4AE2232E.10406@whotookspaz.org> <4AE59FBE.6060904@tzim.net> <4AE5A631.1030607@whotookspaz.org> In-Reply-To: <4AE5A631.1030607@whotookspaz.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" Subject: RE: Possible scheduler (SCHED_ULE) bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:01:00 -0000 From: Jacob Myers [mailto:jacob@whotookspaz.org] > Arnaud Houdelette wrote: > > I had the same issue using 7.1 amd64, with ZFS, no SMP. > > Not really sure what is the size boundary. I can't really test > either, > > as the machine is remote. > > But I confirm that each tentative upload of certain relatively 'big' > > files (around 1MB) with wordpress hanged the system before I switched > > from sendfile to writev. > > > > I might do some test on amd64 7.2 with no SMP if it can be of any use > ? > > > > Arnaud >=20 > I can confirm it happens without SMP on 7.2 and amd64. If you can give > it a try though, well, the more information the better. Any boundary > information, even approximate (well, mostly testing if 64K is the > boundary or if 1 MB or so is) would probably be good, too. I haven't tested the specific boundaries yet, but I will do that shortly. I *was* able to get a crash dump on the i386 system - Will post the details= shortly. My amd64 system is a test system with ZFS, so I couldn't get a crash dump. = Trying to work around that. On both systems, I used a 72K file (73,688 bytes) to test. Both systems wo= uld "lock up", and then a few seconds later kdb would come up. It wasn't = an immediate thing, at least not on the i386 system. I wasn't able to watc= h the amd64 system since it's too far away to time. Jaime From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 14:03:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82F481065697; Mon, 26 Oct 2009 14:03:42 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id DEF0E8FC18; Mon, 26 Oct 2009 14:03:41 +0000 (UTC) Received: by fxm6 with SMTP id 6so11353415fxm.43 for ; Mon, 26 Oct 2009 07:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=RRPP/HG6hNhfec5pZEDw+MKbwTh+//RbpCpqx0bWno0=; b=uXSqoqO3XFVuMYETkMSfQmR5UxKVA5n3xmu815zarmUPFQEeI3xRBvOXDz0fXqIhOG z51AEAdJ1br3Uu/uAgONdhfxvhF7EaX98nuOf9IaF9ZGUDBkakvqfsIQLBmHnqW6pw3e UOLwy9WuGDM5cBI00/6LhCMDU2slfB9kOisBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=s7eqX3o2tldXsyv3GBX798ZvrQ4jQ3dXs9WzRUOkn4uXOdvawtYJun12PlI/nMMtHC mKe8togb7/rXYaFVoy8mxdt3gCNIycFQv8Wbx9I5raehVFkNswei/QHPJYjg+66NyGbd x7nSWgLmmiNLgMMuCcO0Wlh5RHB9uh+46uklM= Received: by 10.103.67.31 with SMTP id u31mr5918622muk.93.1256565820983; Mon, 26 Oct 2009 07:03:40 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 12sm276452muq.18.2009.10.26.07.03.39 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Oct 2009 07:03:39 -0700 (PDT) Sender: Alexander Motin Message-ID: <4AE5AC38.4050507@FreeBSD.org> Date: Mon, 26 Oct 2009 16:03:36 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Steve Polyack References: <4AE04F73.1050703@comcast.net> <4AE073CF.40500@comcast.net> <4AE099D8.5060103@FreeBSD.org> <4AE5AA43.7030405@comcast.net> In-Reply-To: <4AE5AA43.7030405@comcast.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable , freebsd-hardware@freebsd.org Subject: Re: FreeBSD and SATA Port Multipliers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:03:42 -0000 Steve Polyack wrote: > I'm about to try today's head and patch. I'll let you know how it goes. Ok. Just to be sure it is not cabling issue (I have seen such), try also limit port speed to 1.5Gbps by adding to loader.conf: hint.siisch.0.sata_rev=1 hint.siisch.1.sata_rev=1 hint.siisch.2.sata_rev=1 hint.siisch.3.sata_rev=1 -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 14:05:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C18E31065697 for ; Mon, 26 Oct 2009 14:05:50 +0000 (UTC) (envelope-from jbozza@mindsites.com) Received: from mail.thinkburst.com (mail.thinkburst.com [204.49.104.46]) by mx1.freebsd.org (Postfix) with ESMTP id 7BAC48FC1B for ; Mon, 26 Oct 2009 14:05:50 +0000 (UTC) Received: from mailgate.mindsites.net (gateway.mindsites.net [204.49.104.36]) by mail.thinkburst.com (Postfix) with ESMTP id F081E1CC42; Mon, 26 Oct 2009 09:05:49 -0500 (CDT) Received: from remote.mindsites.com (unknown [10.1.1.5]) by mailgate.mindsites.net (Postfix) with ESMTP id D80C517040; Mon, 26 Oct 2009 09:05:49 -0500 (CDT) Received: from ATLAS.msg.local ([fe80::48f5:88b0:6093:4f67]) by ATLAS.msg.local ([fe80::48f5:88b0:6093:4f67%10]) with mapi; Mon, 26 Oct 2009 09:05:49 -0500 From: Jaime Bozza To: Dylan Cochran Date: Mon, 26 Oct 2009 09:05:48 -0500 Thread-Topic: Possible scheduler (SCHED_ULE) bug? Thread-Index: AcpUH3evDyb48/J2TeGV319jIhQUfQCJUuVw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" Subject: RE: Possible scheduler (SCHED_ULE) bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:05:50 -0000 Sincerely, Jaime Bozza MindSites Group, LLC From: Dylan Cochran [mailto:heliocentric@gmail.com] > Superficially, this seams identical to a deadlock I reported for > 7.1-RC1. Would you mind compiling a kernel with these options: >=20 > > KDB: stack backtrace: > db_trace_self_wrapper(c0b55b52,e66e0ae0,c07615e9,c0b50617,8ca93,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c0b50617,8ca93,0,c41a7690,2,...) at kdb_backtrace+0x29 > hardclock(0,c07ff29d,0,0,4,...) at hardclock+0x1f9 > lapic_handle_timer(e66e0b08) at lapic_handle_timer+0x9c > Xtimerint() at Xtimerint+0x1f > --- interrupt, eip =3D 0xc07ff29d, esp =3D 0xe66e0b48, ebp =3D 0xe66e0c34= --- > kern_sendfile(c41a7690,e66e0cfc,0,0,0,...) at kern_sendfile+0x90d > do_sendfile(e66e0d2c,c0aba265,c41a7690,e66e0cfc,20,...) at > do_sendfile+0xb1 > sendfile(c41a7690,e66e0cfc,20,16,e66e0d2c,...) at sendfile+0x13 > syscall(e66e0d38) at syscall+0x335 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (393, FreeBSD ELF32, sendfile), eip =3D 0x282cb0cb, esp =3D > 0xbfbfc7cc, ebp =3D 0xbfbfe848 --- > KDB: enter: watchdog timeout >=20 > You can type 'reboot' to reboot the machine (in my case, panic would > not work, so a useful dump wasn't in the cards) Different offset on mine, but of course I'm using a different kernel. =20 kern_sendfile+0x6ad do_sendfile+0xb1 sendfile+0x13 Luckily, I was able to get a panic, so I have all the files necessary to de= bug. Here's the backtrace: (kgdb) backtrace #0 doadump () at pcpu.h:196 #1 0xc07f2c57 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 18 #2 0xc07f2f62 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0497e47 in db_panic (addr=3DCould not find the frame base for "db_pa= nic". ) at /usr/src/sys/ddb/db_command.c:446 #4 0xc04985bc in db_command (last_cmdp=3D0xc0ca9154, cmd_table=3D0x0, dopa= ger=3D1) at /usr/src/sys/ddb/db_command.c:413 #5 0xc04986ca in db_command_loop () at /usr/src/sys/ddb/db_command.c:466 #6 0xc049a17d in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_main.= c:228 #7 0xc081fdf6 in kdb_trap (type=3D3, code=3D0, tf=3D0xc72e2a5c) at /usr/sr= c/sys/kern/subr_kdb.c:524 #8 0xc0b01b9b in trap (frame=3D0xc72e2a5c) at /usr/src/sys/i386/i386/trap.= c:692 #9 0xc0ae58fb in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #10 0xc081ff7a in kdb_enter_why (why=3D0xc0b677b2 "watchdog", msg=3D0xc0b7e= f1d "watchdog timeout") at cpufunc.h:60 #11 0xc07b0cad in hardclock (usermode=3D0, pc=3D3229966301) at /usr/src/sys= /kern/kern_clock.c:640 #12 0xc0aedf1c in lapic_handle_timer (frame=3D0xc72e2afc) at /usr/src/sys/i= 386/i386/local_apic.c:785 #13 0xc0ae5edf in Xtimerint () at apic_vector.s:108 #14 0xc0855fdd in kern_sendfile (td=3D0xc771db40, uap=3D0xc72e2cfc, hdr_uio= =3D0x0, trl_uio=3D0x0, compat=3D0) at atomic.h:160 #15 0xc0856d31 in do_sendfile (td=3D0xc771db40, uap=3D0xc72e2cfc, compat=3D= 0) at /usr/src/sys/kern/uipc_syscalls.c:1775 #16 0xc0856dd3 in sendfile (td=3D0xc771db40, uap=3D0xc72e2cfc) at /usr/src/= sys/kern/uipc_syscalls.c:1746 #17 0xc0b01365 in syscall (frame=3D0xc72e2d38) at /usr/src/sys/i386/i386/tr= ap.c:1094 #18 0xc0ae5960 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s= :262 #19 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) This is all a bit new to me (debugging, etc), so let me know if you need an= ything else! Jaime From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 14:09:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55A1B106566C for ; Mon, 26 Oct 2009 14:09:09 +0000 (UTC) (envelope-from jbozza@mindsites.com) Received: from mail.thinkburst.com (mail.thinkburst.com [204.49.104.46]) by mx1.freebsd.org (Postfix) with ESMTP id 2523B8FC18 for ; Mon, 26 Oct 2009 14:09:08 +0000 (UTC) Received: from mailgate.mindsites.net (gateway.mindsites.net [204.49.104.36]) by mail.thinkburst.com (Postfix) with ESMTP id 9C1D81CC27; Mon, 26 Oct 2009 09:09:08 -0500 (CDT) Received: from remote.mindsites.com (unknown [10.1.1.5]) by mailgate.mindsites.net (Postfix) with ESMTP id 7A01317049; Mon, 26 Oct 2009 09:09:08 -0500 (CDT) Received: from ATLAS.msg.local ([fe80::48f5:88b0:6093:4f67]) by ATLAS.msg.local ([fe80::48f5:88b0:6093:4f67%10]) with mapi; Mon, 26 Oct 2009 09:09:08 -0500 From: Jaime Bozza To: Kostik Belousov , Dylan Cochran Date: Mon, 26 Oct 2009 09:09:06 -0500 Thread-Topic: Possible scheduler (SCHED_ULE) bug? Thread-Index: AcpUJsMCkKSZ+UzjTTawJE5X5gOI6gCHqoww Message-ID: References: <20091023212104.GH2160@deviant.kiev.zoral.com.ua> In-Reply-To: <20091023212104.GH2160@deviant.kiev.zoral.com.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" Subject: RE: Possible scheduler (SCHED_ULE) bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:09:09 -0000 From: Kostik Belousov [mailto:kostikbel@gmail.com] > Can you look up the source line for kern_sendfile+0x90d in your > kernel ? Do kgdb kernel.debug, then execute "list *(kern_sendfile+0x90d)"= . In my case, it was kern_sendfile+0x6ad (rebuilt with RELENG_7 this weekend)= . Here's the output: (kgdb) list *(kern_sendfile+0x6ad) 0xc0855fdd is in kern_sendfile (atomic.h:160). 155 static __inline int 156 atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src) 157 { 158 u_char res; 159 160 __asm __volatile( 161 " " MPLOCKED " " 162 " cmpxchgl %2,%1 ; " 163 " sete %0 ; " 164 "1: " Not much to go on there. I posted a backtrace in a previous email, but the= relevant sections (I think) are: #14 0xc0855fdd in kern_sendfile (td=3D0xc771db40, uap=3D0xc72e2cfc, hdr_uio= =3D0x0, trl_uio=3D0x0, compat=3D0) at atomic.h:160 #15 0xc0856d31 in do_sendfile (td=3D0xc771db40, uap=3D0xc72e2cfc, compat=3D= 0) at /usr/src/sys/kern/uipc_syscalls.c:1775 #16 0xc0856dd3 in sendfile (td=3D0xc771db40, uap=3D0xc72e2cfc) at /usr/src/= sys/kern/uipc_syscalls.c:1746 #17 0xc0b01365 in syscall (frame=3D0xc72e2d38) at /usr/src/sys/i386/i386/tr= ap.c:1094 #18 0xc0ae5960 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s= :262 #19 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) I'm still going to test the specific boundary, but if there's more informat= ion I can give, let me know! Jaime From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 14:18:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFA18106566C; Mon, 26 Oct 2009 14:18:37 +0000 (UTC) (envelope-from caelian@gmail.com) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by mx1.freebsd.org (Postfix) with ESMTP id 034128FC0C; Mon, 26 Oct 2009 14:18:36 +0000 (UTC) Received: by ewy5 with SMTP id 5so7328502ewy.36 for ; Mon, 26 Oct 2009 07:18:36 -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; bh=s7CuXtAViH8/zd7q9viw0dmeUggNfOFnmE33U+4RhVE=; b=qLGbLgjnxVMb9uFcsZ7IGVyHuDrCaPL+yjD0SW9jIt9mU8NShZA6RsTpcDtDWJCqOu Jx2aZwUUTQDD7ZLhxqNftdmoDjVCPMTPnaMrd1fX1ceru4ieOIwcPtZ/xJZEoJpXMmrB tgG+qK2sKWWmRdPqE6Gpms+Bit/SC1HAgoXiw= 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; b=TJ3/Q6SBwBCn+IIyVndNc3w42DvCyIAOecAZKKB552l5j06aforApHA3J6kK+1kDKL Ab1fTAnw0r+cRiqglggTYEo8S4bExZYZCcsu3Gmnze3mXxI1x/DH67jVEQkWWP6bjaKk MqPTXbJke+1RIoMlTrRe/F1CF7V9D3qSB8w7k= MIME-Version: 1.0 Received: by 10.211.146.5 with SMTP id y5mr2225643ebn.41.1256566716074; Mon, 26 Oct 2009 07:18:36 -0700 (PDT) In-Reply-To: <4AE3A001.8000205@FreeBSD.org> References: <4AE3A001.8000205@FreeBSD.org> Date: Mon, 26 Oct 2009 15:18:36 +0100 Message-ID: From: Pascal Hofstee To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: icegloom dem , FreeBSD-Current , FreeBSD Stable , freebsd-amd64@freebsd.org Subject: Re: MCP55 SATA solution to test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:18:38 -0000 2009/10/25 Alexander Motin : > Hi. > > Thanks to one man who provided access to his machine, I seem to found > how to fix device detection on nVidia MCP55 SATA controller on amd64 > 8.0. Looks like this controller need some time (very short) to enable > BAR(5) memory access after PCI configuration register written. Probably > some changes in PCI code exposed this issue. Also it explains why > setting hw.pci.mcfg to 0 helps. > > Attached patch solves problem for that machine. Testers are welcome. Confirmed this also fixes the SATA detection on my MSI K9N Neo on 9.0-CURRENT. Please commit :) From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 14:24:04 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F3EF106566B for ; Mon, 26 Oct 2009 14:24:04 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id C29378FC26 for ; Mon, 26 Oct 2009 14:24:03 +0000 (UTC) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Mon, 26 Oct 2009 10:24:02 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::126 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@FreeBSD.org X-SMFBL: ZnJlZWJzZC1zdGFibGVARnJlZUJTRC5vcmc= Message-ID: <4AE5B102.6000704@comcast.net> Date: Mon, 26 Oct 2009 10:24:02 -0400 From: Steve Polyack User-Agent: Thunderbird 2.0.0.23 (X11/20090902) MIME-Version: 1.0 To: Alexander Motin References: <4AE04F73.1050703@comcast.net> <4AE073CF.40500@comcast.net> <4AE099D8.5060103@FreeBSD.org> <4AE5AA43.7030405@comcast.net> <4AE5AC38.4050507@FreeBSD.org> In-Reply-To: <4AE5AC38.4050507@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------020700070400030106030002" Cc: freebsd-stable , freebsd-hardware@freebsd.org Subject: Re: FreeBSD and SATA Port Multipliers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:24:04 -0000 This is a multi-part message in MIME format. --------------020700070400030106030002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alexander Motin wrote: > Steve Polyack wrote: > >> I'm about to try today's head and patch. I'll let you know how it goes. >> > > Ok. Just to be sure it is not cabling issue (I have seen such), try also > limit port speed to 1.5Gbps by adding to loader.conf: > hint.siisch.0.sata_rev=1 > hint.siisch.1.sata_rev=1 > hint.siisch.2.sata_rev=1 > hint.siisch.3.sata_rev=1 > > Here's a dmesg from todays head and your patch from this morning. It's still only sensing one disk over the two PMs. Forcing SATA1/1.5Gbps operation didn't change anything. --------------020700070400030106030002 Content-Type: text/plain; name="dmesg.20091026patch-sata1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.20091026patch-sata1" 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 9.0-CURRENT #4: Mon Oct 26 10:01:55 EDT 2009 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff809e7000. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff809e7260. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2133419836 Hz CPU: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz (2133.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Stepping = 5 Features=0xbfebfbff Features2=0x9ce3bd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4299161600 (4100 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000093fff, 602112 bytes (147 pages) 0x0000000000a16000 - 0x00000000b60fffff, 3043926016 bytes (743146 pages) 0x00000000bf78e000 - 0x00000000bf78ffff, 8192 bytes (2 pages) 0x0000000100000000 - 0x000000013ffeffff, 1073676288 bytes (262128 pages) avail memory = 4095377408 (3905 MB) ACPI APIC Table: <061909 APIC1420> INTR: Adding local APIC 18 as a target INTR: Adding local APIC 20 as a target INTR: Adding local APIC 22 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 18 cpu2 (AP): APIC ID: 20 cpu3 (AP): APIC ID: 22 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xfa710 00024 (v2 ACPIAM) ACPI: XSDT 0xbf790100 0008C (v1 NEC 20090619 MSFT 00000097) ACPI: FACP 0xbf790290 000F4 (v4 061909 FACP1420 20090619 MSFT 00000097) ACPI: DSDT 0xbf790670 05B8F (v2 10006 10006000 00000000 INTL 20051117) ACPI: FACS 0xbf79e000 00040 ACPI: APIC 0xbf790390 000D2 (v2 061909 APIC1420 20090619 MSFT 00000097) ACPI: MCFG 0xbf790470 0003C (v1 061909 OEMMCFG 20090619 MSFT 00000097) ACPI: SLIC 0xbf7904b0 00176 (v1 NEC 20090619 MSFT 00000097) ACPI: ERST 0xbf790630 00040 (v1 061909 WHEA1420 20090619 MSFT 00000097) ACPI: OEMB 0xbf79e040 0007B (v1 061909 OEMB1420 20090619 MSFT 00000097) ACPI: HPET 0xbf79a670 00038 (v1 061909 OEMHPET 20090619 MSFT 00000097) ACPI: DMAR 0xbf79e0c0 00120 (v1 AMI OEMDMAR 00000001 MSFT 00000097) ACPI: SSDT 0xbf79efb0 00363 (v1 DpgPmm CpuPm 00000012 INTL 20051117) ACPI: EINJ 0xbf79a6b0 00130 (v1 AMIER AMI_EINJ 20090619 MSFT 00000097) ACPI: BERT 0xbf79a840 00030 (v1 AMIER AMI_BERT 20090619 MSFT 00000097) ACPI: ERST 0xbf79a870 001B0 (v1 AMIER AMI_ERST 20090619 MSFT 00000097) ACPI: HEST 0xbf79aa20 000A8 (v1 AMIER AMI_HEST 20090619 MSFT 00000097) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 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 lapic: Routing NMI -> LINT1 lapic: LINT1 trigger: edge lapic: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x10000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010400 nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: null: io: random: acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 16 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0 ACPI timer: 1/1 1/0 1/0 1/2 0/459 1/2 1/0 1/0 1/0 1/0 -> 9 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 3 4 6 7 10 11 12 14 15 Validation 0 14 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 6 7 10 11 12 14 15 Validation 0 7 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 6 7 10 11 12 14 15 Validation 0 6 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff iomem 0xfed40000-0xfed44fff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x3403, revid=0x13 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x3408, revid=0x13 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340a, revid=0x13 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340e, revid=0x13 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x3410, revid=0x13 domain=0, bus=0, slot=9, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x342e, revid=0x13 domain=0, bus=0, slot=20, func=0 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3422, revid=0x13 domain=0, bus=0, slot=20, func=1 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3423, revid=0x13 domain=0, bus=0, slot=20, func=2 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3438, revid=0x13 domain=0, bus=0, slot=20, func=3 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3430, revid=0x13 domain=0, bus=0, slot=22, func=0 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacfc000, size 14, enabled pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3431, revid=0x13 domain=0, bus=0, slot=22, func=1 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacf8000, size 14, enabled pcib0: matched entry for 0.22.INTB pcib0: slot 22 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3432, revid=0x13 domain=0, bus=0, slot=22, func=2 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacf4000, size 14, enabled pcib0: matched entry for 0.22.INTC pcib0: slot 22 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3433, revid=0x13 domain=0, bus=0, slot=22, func=3 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=14 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacf0000, size 14, enabled pcib0: matched entry for 0.22.INTD pcib0: slot 22 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3429, revid=0x13 domain=0, bus=0, slot=22, func=4 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacec000, size 14, enabled pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x342a, revid=0x13 domain=0, bus=0, slot=22, func=5 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xface8000, size 14, enabled pcib0: matched entry for 0.22.INTB pcib0: slot 22 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x342b, revid=0x13 domain=0, bus=0, slot=22, func=6 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xface4000, size 14, enabled pcib0: matched entry for 0.22.INTC pcib0: slot 22 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x342c, revid=0x13 domain=0, bus=0, slot=22, func=7 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=14 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xface0000, size 14, enabled pcib0: matched entry for 0.22.INTD pcib0: slot 22 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a37, revid=0x00 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0xbc00, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3a38, revid=0x00 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 map[20]: type I/O Port, range 32, base 0xb880, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x3a39, revid=0x00 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=14 map[20]: type I/O Port, range 32, base 0xb800, size 5, enabled pcib0: matched entry for 0.26.INTD pcib0: slot 26 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a3c, revid=0x00 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfacde000, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfacde000 found-> vendor=0x8086, dev=0x3a3e, revid=0x00 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfacd8000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x3a40, revid=0x00 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a48, revid=0x00 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a4a, revid=0x00 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3a34, revid=0x00 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0xb480, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x3a35, revid=0x00 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=14 map[20]: type I/O Port, range 32, base 0xb400, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a36, revid=0x00 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[20]: type I/O Port, range 32, base 0xb080, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3a3a, revid=0x00 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfacdc000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfacdc000 found-> vendor=0x8086, dev=0x244e, revid=0x90 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x1a (6500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a16, revid=0x00 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a22, revid=0x00 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=14 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0xb000, size 3, enabled map[14]: type I/O Port, range 32, base 0xac00, size 2, enabled map[18]: type I/O Port, range 32, base 0xa880, size 3, enabled map[1c]: type I/O Port, range 32, base 0xa800, size 2, enabled map[20]: type I/O Port, range 32, base 0xa480, size 5, enabled map[24]: type Memory, range 32, base 0xfacd2000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a30, revid=0x00 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[10]: type Memory, range 64, base 0xfacd0000, size 8, enabled map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: at device 3.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: at device 7.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 4 pcib3: I/O decode 0xc000-0xcfff pcib3: memory decode 0xfad00000-0xfadfffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x12d8, dev=0xe111, revid=0x02 domain=0, bus=3, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 pcib4: irq 16 at device 0.0 on pci3 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xc000-0xcfff pcib4: memory decode 0xfad00000-0xfadfffff pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x1095, dev=0x3124, revid=0x01 domain=0, bus=4, slot=4, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x01df, statreg=0x02b0, cachelnsz=64 (dwords) lattimer=0x40 (1920 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, 64 bit map[10]: type Memory, range 64, base 0xfadfe000, size 7, enabled pcib4: requested memory range 0xfadfe000-0xfadfe07f: good pcib3: requested memory range 0xfadfe000-0xfadfe07f: good map[18]: type Memory, range 64, base 0xfadf0000, size 15, enabled pcib4: requested memory range 0xfadf0000-0xfadf7fff: good pcib3: requested memory range 0xfadf0000-0xfadf7fff: good map[20]: type I/O Port, range 32, base 0xcc00, size 4, enabled pcib4: requested I/O range 0xcc00-0xcc0f: in range pcib3: requested I/O range 0xcc00-0xcc0f: in range pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 pcib4: slot 4 INTA is routed to irq 16 siis0: port 0xcc00-0xcc0f mem 0xfadfe000-0xfadfe07f,0xfadf0000-0xfadf7fff irq 16 at device 4.0 on pci4 siis0: Reserved 0x80 bytes for rid 0x10 type 3 at 0xfadfe000 siis0: Reserved 0x8000 bytes for rid 0x18 type 3 at 0xfadf0000 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 16 vector 49 siis0: [MPSAFE] siis0: [ITHREAD] siisch0: at channel 0 on siis0 siisch0: [MPSAFE] siisch0: [ITHREAD] siisch1: at channel 1 on siis0 siisch1: [MPSAFE] siisch1: [ITHREAD] siisch2: at channel 2 on siis0 siisch2: [MPSAFE] siisch2: [ITHREAD] siisch3: at channel 3 on siis0 siisch3: [MPSAFE] siisch3: [ITHREAD] pcib5: at device 9.0 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0x0-0x0 pcib5: no prefetched decode pci5: on pcib5 pci5: domain=0, physical bus=5 pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) pci0: at device 22.2 (no driver attached) pci0: at device 22.3 (no driver attached) pci0: at device 22.4 (no driver attached) pci0: at device 22.5 (no driver attached) pci0: at device 22.6 (no driver attached) pci0: at device 22.7 (no driver attached) uhci0: port 0xbc00-0xbc1f irq 16 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbc00 uhci0: [MPSAFE] uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xb880-0xb89f irq 21 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb880 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 16 vector 50 uhci1: [MPSAFE] uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xb800-0xb81f irq 19 at device 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb800 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 16 vector 51 uhci2: [MPSAFE] uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xfacde000-0xfacde3ff irq 18 at device 26.7 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 16 vector 52 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pci0: at device 27.0 (no driver attached) pcib6: irq 17 at device 28.0 on pci0 pcib6: domain 0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: I/O decode 0x0-0x0 pcib6: no prefetched decode pci6: on pcib6 pci6: domain=0, physical bus=6 pcib7: irq 17 at device 28.4 on pci0 pcib7: domain 0 pcib7: secondary bus 7 pcib7: subordinate bus 7 pcib7: I/O decode 0xd000-0xdfff pcib7: memory decode 0xfae00000-0xfaefffff pcib7: no prefetched decode pci7: on pcib7 pci7: domain=0, physical bus=7 found-> vendor=0x8086, dev=0x10d3, revid=0x00 domain=0, bus=7, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (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 MSI-X supports 5 messages in map 0x1c map[10]: type Memory, range 32, base 0xfaee0000, size 17, enabled pcib7: requested memory range 0xfaee0000-0xfaefffff: good map[18]: type I/O Port, range 32, base 0xdc00, size 5, enabled pcib7: requested I/O range 0xdc00-0xdc1f: in range map[1c]: type Memory, range 32, base 0xfaedc000, size 14, enabled pcib7: requested memory range 0xfaedc000-0xfaedffff: good pcib7: matched entry for 7.0.INTA pcib7: slot 0 INTA hardwired to IRQ 16 em0: port 0xdc00-0xdc1f mem 0xfaee0000-0xfaefffff,0xfaedc000-0xfaedffff irq 16 at device 0.0 on pci7 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfaee0000 em0: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xfaedc000 em0: attempting to allocate 3 MSI-X vectors (5 supported) msi: routing MSI-X IRQ 256 to local APIC 16 vector 53 msi: routing MSI-X IRQ 257 to local APIC 16 vector 54 msi: routing MSI-X IRQ 258 to local APIC 16 vector 55 em0: using IRQs 256-258 for MSI-X em0: Using MSIX interrupts em0: [MPSAFE] em0: [ITHREAD] em0: [MPSAFE] em0: [ITHREAD] em0: [MPSAFE] em0: [ITHREAD] em0: bpf attached em0: Ethernet address: 00:30:48:db:7d:9e pcib8: irq 16 at device 28.5 on pci0 pcib8: domain 0 pcib8: secondary bus 8 pcib8: subordinate bus 8 pcib8: I/O decode 0xe000-0xefff pcib8: memory decode 0xfaf00000-0xfaffffff pcib8: no prefetched decode pci8: on pcib8 pci8: domain=0, physical bus=8 found-> vendor=0x8086, dev=0x10d3, revid=0x00 domain=0, bus=8, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 5 messages in map 0x1c map[10]: type Memory, range 32, base 0xfafe0000, size 17, enabled pcib8: requested memory range 0xfafe0000-0xfaffffff: good map[18]: type I/O Port, range 32, base 0xec00, size 5, enabled pcib8: requested I/O range 0xec00-0xec1f: in range map[1c]: type Memory, range 32, base 0xfafdc000, size 14, enabled pcib8: requested memory range 0xfafdc000-0xfafdffff: good pcib8: matched entry for 8.0.INTA pcib8: slot 0 INTA hardwired to IRQ 17 em1: port 0xec00-0xec1f mem 0xfafe0000-0xfaffffff,0xfafdc000-0xfafdffff irq 17 at device 0.0 on pci8 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfafe0000 em1: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xfafdc000 em1: attempting to allocate 3 MSI-X vectors (5 supported) msi: routing MSI-X IRQ 259 to local APIC 16 vector 56 msi: routing MSI-X IRQ 260 to local APIC 16 vector 57 msi: routing MSI-X IRQ 261 to local APIC 16 vector 58 em1: using IRQs 259-261 for MSI-X em1: Using MSIX interrupts em1: [MPSAFE] em1: [ITHREAD] em1: [MPSAFE] em1: [ITHREAD] em1: [MPSAFE] em1: [ITHREAD] em1: bpf attached em1: Ethernet address: 00:30:48:db:7d:9f uhci3: port 0xb480-0xb49f irq 23 at device 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb480 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 16 vector 59 uhci3: [MPSAFE] uhci3: [ITHREAD] uhci3: LegSup = 0x3f00 usbus4: on uhci3 uhci4: port 0xb400-0xb41f irq 19 at device 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb400 uhci4: [MPSAFE] uhci4: [ITHREAD] uhci4: LegSup = 0x2f00 usbus5: on uhci4 uhci5: port 0xb080-0xb09f irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb080 uhci5: [MPSAFE] uhci5: [ITHREAD] uhci5: LegSup = 0x2f00 usbus6: on uhci5 ehci1: mem 0xfacdc000-0xfacdc3ff irq 23 at device 29.7 on pci0 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib9: at device 30.0 on pci0 pcib9: domain 0 pcib9: secondary bus 9 pcib9: subordinate bus 9 pcib9: I/O decode 0xf000-0xfff pcib9: memory decode 0xfb000000-0xfbefffff pcib9: prefetched decode 0xf9000000-0xf9ffffff pcib9: Subtractively decoded bridge. pci9: on pcib9 pci9: domain=0, physical bus=9 found-> vendor=0x102b, dev=0x0532, revid=0x0a domain=0, bus=9, slot=1, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=64 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x20 (8000 ns) intpin=a, irq=15 powerspec 1 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xf9000000, size 24, enabled pcib9: requested memory range 0xf9000000-0xf9ffffff: good map[14]: type Memory, range 32, base 0xfbefc000, size 14, enabled pcib9: requested memory range 0xfbefc000-0xfbefffff: good map[18]: type Memory, range 32, base 0xfb000000, size 23, enabled pcib9: requested memory range 0xfb000000-0xfb7fffff: good pcib9: matched entry for 9.1.INTA pcib9: slot 1 INTA hardwired to IRQ 18 vgapci0: mem 0xf9000000-0xf9ffffff,0xfbefc000-0xfbefffff,0xfb000000-0xfb7fffff irq 18 at device 1.0 on pci9 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xb000-0xb007,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa49f mem 0xfacd2000-0xfacd27ff irq 19 at device 31.2 on pci0 ahci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfacd2000 ahci0: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 262 to local APIC 16 vector 64 ahci0: using IRQ 262 for MSI ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC EM eSATA 6ports ahci0: Caps2: ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [MPSAFE] ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [MPSAFE] ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [MPSAFE] ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [MPSAFE] ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [MPSAFE] ahcich5: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) Calling int 0x15 (ax=0xc000 bx=0x0000 cx=0x0000 dx=0x0000 es=0x0000 di=0x0000) Exiting int 0x15 (ax=0x0000 bx=0xe712 cx=0x0000 dx=0x0000 es=0xf000 di=0x0000) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 16 vector 60 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 16 vector 61 uart0: [FILTER] uart0: fast interrupt uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 16 vector 62 uart1: [FILTER] uart1: fast interrupt cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 6E, should be 6B (20091013/tbutils-354) ACPI: SSDT 0xbf79e1e0 008F0 (v1 DpgPmm P001Ist 00000011 INTL 20051117) ACPI: SSDT 0xbf79ead0 004D5 (v1 PmRef P001Cst 00003001 INTL 20051117) est0: on cpu0 est0: Invalid id16 (set, cur) = (15, 16) est0: Invalid freq 2000, ignored. est0: Invalid id16 (set, cur) = (14, 16) est0: Invalid freq 1867, ignored. est0: Invalid id16 (set, cur) = (13, 16) est0: Invalid freq 1733, ignored. est0: Invalid id16 (set, cur) = (12, 16) est0: Invalid freq 1600, ignored. p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est1: Invalid id16 (set, cur) = (15, 16) est1: Invalid freq 2000, ignored. est1: Invalid id16 (set, cur) = (14, 16) est1: Invalid freq 1867, ignored. est1: Invalid id16 (set, cur) = (13, 16) est1: Invalid freq 1733, ignored. est1: Invalid id16 (set, cur) = (12, 16) est1: Invalid freq 1600, ignored. p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est2: Invalid id16 (set, cur) = (15, 16) est2: Invalid freq 2000, ignored. est2: Invalid id16 (set, cur) = (14, 16) est2: Invalid freq 1867, ignored. est2: Invalid id16 (set, cur) = (13, 16) est2: Invalid freq 1733, ignored. est2: Invalid id16 (set, cur) = (12, 16) est2: Invalid freq 1600, ignored. p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est3: Invalid id16 (set, cur) = (15, 16) est3: Invalid freq 2000, ignored. est3: Invalid id16 (set, cur) = (14, 16) est3: Invalid freq 1867, ignored. est3: Invalid id16 (set, cur) = (13, 16) est3: Invalid freq 1733, ignored. est3: Invalid id16 (set, cur) = (12, 16) est3: Invalid freq 1600, ignored. p4tcc3: on cpu3 acpi0: wakeup code va 0xffffff8077774000 pa 0x4000 isa_probe_children: disabling PnP devices ipmi0: on isa0 ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it uart: uart1 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 257519 -> 100000 procfs registered lapic: Divisor 2, Frequency 66669369 hz Timecounter "TSC" frequency 2133419836 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attachedsiisch0: CONNECT requested siisch0: SIIS reset... siisch0: device reset time=0ms siisch0: SATA connect time=0ms status=00000113 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 siisch2: CONNECT requested siisch2: SIIS reset... siisch2: device reset time=0ms siisch2: SATA connect time=0ms status=00000113 siisch2: ready wait time=0ms siisch2: SIIS reset done: devices=00000001 Waiting 15 seconds for SCSI devices to settle siisch0: SIIS reset... siisch0: device reset time=1ms siisch0: SATA connect time=0ms status=00000113 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 siisch1: SIIS reset... siisch1: device reset time=1ms siisch1: SATA connect timeout status=00000000 siisch1: SIIS reset done: phy reset found no device siisch2: SIIS reset... siisch2: device reset time=1ms siisch2: SATA connect time=0ms status=00000113 siisch2: ready wait time=0ms siisch2: SIIS reset done: devices=00000001 siisch3: SIIS reset... siisch3: device reset time=1ms siisch3: SATA connect timeout status=00000000 siisch3: SIIS reset done: phy reset found no device ahcich0: AHCI reset... ahcich0: hardware reset ... ahcich0: SATA connect timeout status=00000000 ahcich0: AHCI reset done: phy reset found no device ahcich1: AHCI reset... ahcich1: hardware reset ... ahcich1: SATA connect time=0ms status=00000123 ahcich1: ready wait time=4ms ahcich1: AHCI reset done: device found ahcich2: AHCI reset... ahcich2: hardware reset ... ahcich2: SATA connect timeout status=00000000 ahcich2: AHCI reset done: phy reset found no device ahcich3: AHCI reset... ahcich3: hardware reset ... ahcich3: SATA connect timeout status=00000000 ahcich3: AHCI reset done: phy reset found no device ahcich4: AHCI reset... ahcich4: hardware reset ... ahcich4: SATA connect timeout status=00000000 ahcich4: AHCI reset done: phy reset found no device ahcich5: AHCI reset... ahcich5: hardware reset ... ahcich5: SATA connect timeout status=00000000 ahcich5: AHCI reset done: phy reset found no device usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ipmi0: IPMI device rev. 1, firmware rev. 1.2, version 2.0 ipmi0: Number of channels 0 ipmi0: Attached watchdog ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ugen1.2: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 ukbd0: on usbus1 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 (aprobe0:siisch0:0:15:0): SIGNATURE: 9669 PM Product ID: 37261095 PM Revision: 00001706 (aprobe2:siisch2:0:15:0): SIGNATURE: 9669 PM Product ID: 37261095 PM Revision: 00001706 (aprobe5:ahcich1:0:0:0): SIGNATURE: 0000 pmp0 at siisch0 bus 0 scbus0 target 15 lun 0 pmp0: ATA/ATAPI-0 device pmp0: 150.000MB/s transfers PM ports: 5 PM RESET 0 PM RESET 1 PM RESET 2 siisch0: SNTF 0x0000 siisch0: SNTF 0x0000 PM RESET 3 PM RESET 4 siisch0: SNTF 0x0000 siisch0: SNTF 0x0000 PM reset done pmp1 at siisch2 bus 0 scbus2 target 15 lun 0 pmp1: ATA/ATAPI-0 device pmp1: 150.000MB/s transfers PM ports: 5 PM RESET 0 PM RESET 1 PM RESET 2 PM RESET 3 PM RESET 4 PM reset done GEOM: new disk ada0 ada0 at ahcich1 bus 0 scbus5 target 0 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: Serial Number 9VM1RYE5 ada0: 300.000MB/s transfers ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing enabled pass0 at siisch0 bus 0 scbus0 target 15 lun 0 pass0: ATA/ATAPI-0 device pass0: 150.000MB/s transfers PM connect done PM status: 0 - 00000123 PM status: 1 - 00000123 PM status: 2 - 00000123 PM status: 3 - 00000123 PM status: 4 - 00000123 pass1 at siisch2 bus 0 scbus2 target 15 lun 0 pass1: ATA/ATAPI-0 device pass1: 150.000MB/s transfers pass2 at ahcich1 bus 0 scbus5 target 0 lun 0PM connect done pass2: PM status: 0 - 00000123 ATA/ATAPI-8 SATA 2.x device pass2: Serial Number 9VM1RYE5 pass2: 300.000MB/s transfers ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x12000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x16000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x14000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 18 vector 48 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 20 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 22 vector 48 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 18 vector 49 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 20 vector 49 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 22 vector 49 msi: Assigning MSI-X IRQ 256 to local APIC 18 vector 50 msi: Assigning MSI-X IRQ 257 to local APIC 20 vector 50 msi: Assigning MSI-X IRQ 258 to local APIC 22 vector 50 msi: Assigning MSI-X IRQ 260 to local APIC 18 vector 51 msi: Assigning MSI-X IRQ 261 to local APIC 20 vector 51 msi: Assigning MSI IRQ 262 to local APIC 22 vector 51 GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). Trying to mount root from ufs:/dev/label/OS/rootfs ct_to_ts([2009-10-26 10:16:33]) = 1256552193.000000000 start_init: trying /sbin/init PM status: 1 - 00000000 PM status: 2 - 00000000 PM status: 3 - 00000000 PM status: 4 - 00000000 (aprobe1:siisch2:0:0:0): SIGNATURE: 0000 pass3 at siisch2 bus 0 scbus2 target 0 lun 0 pass3: ATA/ATAPI-8 SATA 2.x device pass3: Serial Number 9VS2FGFN pass3: 150.000MB/s transfers ada1 at siisch2 bus 0 scbus2 target 0 lun 0GEOM: new disk ada1 ada1: ATA/ATAPI-8 SATA 2.x device ada1: Serial Number 9VS2FGFN ada1: 150.000MB/s transfers ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada1: Native Command Queueing enabled em0: Link is up 1000 Mbps Full Duplex em0: link state changed to UP siisch0: Timeout on slot 26 siisch0: siis_timeout is 00000000 ss 04000000 rs 04000000 es 00000000 sts 801a2000 serr 00000000 siisch0: ready wait time=0ms siisch0: ready wait time=0ms siisch0: SIIS reset... siisch0: device reset time=1ms siisch0: SATA connect time=0ms status=00000113 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 PMP freeze: 1 PMP freeze: 2 PMP freeze: 3 PMP freeze: 4 (aprobe0:siisch0:0:0:0): Command timed out (aprobe0:siisch0:0:0:0): error 5 (aprobe0:siisch0:0:0:0): Retries Exhausted PMP freeze: 0 PM ports: -1771503359 PM RESET 0 PM reset done PM connect done PMP release: 0 PMP release: 1 PMP release: 2 PMP release: 3 PMP release: 4 t_delta 15.fc765cbdba5b39c0 too short --------------020700070400030106030002-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 14:48:26 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10CED10656A6 for ; Mon, 26 Oct 2009 14:48:26 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id BFFE18FC21 for ; Mon, 26 Oct 2009 14:48:25 +0000 (UTC) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Mon, 26 Oct 2009 10:48:24 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::159 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@FreeBSD.org X-SMFBL: ZnJlZWJzZC1zdGFibGVARnJlZUJTRC5vcmc= Message-ID: <4AE5B6B8.2010509@comcast.net> Date: Mon, 26 Oct 2009 10:48:24 -0400 From: Steve Polyack User-Agent: Thunderbird 2.0.0.23 (X11/20090902) MIME-Version: 1.0 To: Alexander Motin References: <4AE04F73.1050703@comcast.net> <4AE073CF.40500@comcast.net> <4AE099D8.5060103@FreeBSD.org> <4AE5AA43.7030405@comcast.net> <4AE5AC38.4050507@FreeBSD.org> <4AE5B102.6000704@comcast.net> In-Reply-To: <4AE5B102.6000704@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable , freebsd-hardware@freebsd.org Subject: Re: FreeBSD and SATA Port Multipliers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:48:26 -0000 Steve Polyack wrote: > Alexander Motin wrote: >> Steve Polyack wrote: >> >>> I'm about to try today's head and patch. I'll let you know how it >>> goes. >>> >> >> Ok. Just to be sure it is not cabling issue (I have seen such), try also >> limit port speed to 1.5Gbps by adding to loader.conf: >> hint.siisch.0.sata_rev=1 >> hint.siisch.1.sata_rev=1 >> hint.siisch.2.sata_rev=1 >> hint.siisch.3.sata_rev=1 >> >> > Here's a dmesg from todays head and your patch from this morning. > It's still only sensing one disk over the two PMs. Forcing > SATA1/1.5Gbps operation didn't change anything. > I should also note that if I do a 'camcontrol rescan', the first PM (with 5 physical drives attached, none detected) will vanish. Physically unplugging and reconnecting the device does the same. COMMAND=/sbin/camcontrol rescan all siisch0: Timeout on slot 29 siisch0: siis_timeout is 00000000 ss 20000000 rs 20000000 es 00000000 sts 801f2000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: device reset time=0ms siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 (aprobe0:siisch0:0:15:0): Command timed out (aprobe0:siisch0:0:15:0): error 5 (aprobe0:siisch0:0:15:0): Retries Exhausted (pass0:siisch0:0:15:0): lost device (pass0:siisch0:0:15:0): removing device entry (pmp0:siisch0:0:15:0): lost device siisch0: Timeout on slot 30 siisch0: siis_timeout is 00000000 ss 40000000 rs 40000000 es 00000000 sts 801f0000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms (pmp0:siisch0:0:15:0): Request Requeued (pmp0:siisch0:0:15:0): Retrying Command siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: device reset time=0ms siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 (aprobe0:siisch0:0:0:0): Command timed out (aprobe0:siisch0:0:0:0): error 5 (aprobe0:siisch0:0:0:0): Retries Exhausted (pmp0:siisch0:0:15:0): Request Requeued (pmp0:siisch0:0:15:0): Retrying Command (aprobe0:siisch2:0:15:0): SIGNATURE: 9669 PM Product ID: 37261095 PM Revision: 00001706 PMP freeze: 0 PM ports: 5 PM RESET 0 skipping PM RESET 1 PM RESET 2 PM RESET 3 PM RESET 4 PM reset done PM connect done PM status: 0 - 00000123 PM status: 1 - 00000000 PM status: 2 - 00000000 PM status: 3 - 00000000 PM status: 4 - 00000000 PMP release: 0 From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 14:49:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E32B1065698; Mon, 26 Oct 2009 14:49:40 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by mx1.freebsd.org (Postfix) with ESMTP id 0117D8FC26; Mon, 26 Oct 2009 14:49:39 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id n9QEncrd004823; Mon, 26 Oct 2009 15:49:38 +0100 (CET) (envelope-from Johan@double-l.nl) Date: Mon, 26 Oct 2009 15:49:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA570E2@w2003s01.double-l.local> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Index: AcpT5z1eFu4cEqe6S6KPsB2ncHkASgCYn2og References: <57200BF94E69E54880C9BB1AF714BBCBA570C7@w2003s01.double-l.local> <200910230812.31166.jhb@freebsd.org> From: "Johan Hendriks" To: "John Baldwin" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: stas@freebsd.org, bz@freebsd.org, freebsd-stable@freebsd.org Subject: RE: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:49:40 -0000 >> Hello all >> I just installed FreeBSD 8.0RC1 AMD64 on my new HP Proliant ML150 G6 >> server. >> It fails to detect the Broadcom network interface. >>=20 >>=20 >>=20 >> Pciconf -lv gives me the following. >>=20 >> none3@pci0:4:0:0: class=3D0x020000 card=3D0x705d10c chip=3D0x165b14e4 >> rev=3D0x10 >> hdr=3D0x00 >>=20 >> vendor =3D 'Broadcom Corporation' >> class =3D network >>=20 >> Subclass =3D Ethernet >>=20 >> =20 >>=20 >> Is there something I can do, other than install an other network card? >I think you can just patch the bge(4) driver to add support for your >adapter. =20 >It looks like a BCM5723 from the PCI ID. Support for it was just added in=20 >9.0 as part of change 197832, but I suspect it might not need all the other >patches from that change. Try this diff: >Index: if_bgereg.h >=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 >--- if_bgereg.h (revision 197831) >+++ if_bgereg.h (revision 197832) >@@ -2101,6 +2123,7 @@ > #define BCOM_DEVICEID_BCM5720 0x1658 > #define BCOM_DEVICEID_BCM5721 0x1659 > #define BCOM_DEVICEID_BCM5722 0x165A >+#define BCOM_DEVICEID_BCM5723 0x165B > #define BCOM_DEVICEID_BCM5750 0x1676 > #define BCOM_DEVICEID_BCM5750M 0x167C > #define BCOM_DEVICEID_BCM5751 0x1677 >Index: if_bge.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 >--- if_bge.c (revision 197831) >+++ if_bge.c (revision 197832) >@@ -170,6 +170,7 @@ > { BCOM_VENDORID, BCOM_DEVICEID_BCM5720 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5721 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5722 }, >+ { BCOM_VENDORID, BCOM_DEVICEID_BCM5723 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5750 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5750M }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5751 }, Like I said in my first answer, the device is detected with these lines. Only if I enable the device it can not boot. If I boot with the inserted em0 interface and the change in the rc.conf file the em0 into bge0 and do a /etc/netstart, the systems hangs, only a power cycle can reclaim the server. I have installed FreeBSD 9.0Current on the machine and here it works fine I saw a commit from Bjoern A. Zeeb which describe the hang, but do not know if this can be reverted back to 8.x before the release. svn commit: r198049 - head/sys/dev/bge Bjoern A. Zeeb regards, and thank you for your time. cc'ed stas@ and bz@ ( hope they do not mind, if so I am sorry) Johan Hendriks No virus found in this outgoing message. Checked by AVG - www.avg.com=20 Version: 8.5.423 / Virus Database: 270.14.32/2459 - Release Date: 10/25/09 19:57:00 From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 15:39:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 252F7106566C for ; Mon, 26 Oct 2009 15:39:04 +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 DA79F8FC15 for ; Mon, 26 Oct 2009 15:39:03 +0000 (UTC) Received: from [192.168.1.4] (adsl-150-102-19.bna.bellsouth.net [72.150.102.19]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9QFd0dx069987 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 26 Oct 2009 11:39:01 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Pete French In-Reply-To: References: Content-Type: text/plain Organization: FreeBSD Date: Mon, 26 Oct 2009 10:38:55 -0500 Message-Id: <1256571535.2502.221.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=-1.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, 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-stable@freebsd.org Subject: Re: whats best pracfive for ZFS on a whole disc these days ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:39:04 -0000 On Mon, 2009-10-26 at 11:19 +0000, Pete French wrote: > just about to build a new ZFS based system and I was wondering > what the recommended way to dedicate a whole disc to ZFS is > these days. Should I just give it 'da1', 'da2' etc as I have > done in the past, or is it better to use GPT to create a > partition over the whole disc, which is marked as > being for freebsd-zfs ? > > Not that I have had any problems with simply using bare > drives, but the phrase 'dangerously dedicated' does keep > nagging at me, hence considering the GPT route :-) Others may have different opinions, but if your drives are dedicated to zfs and you don't intend to try and boot from them, I see no reason not to continue giving the whole disk to zfs. robert. > cheers, > > -pete. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 15:41:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16710106566B; Mon, 26 Oct 2009 15:41:08 +0000 (UTC) (envelope-from stas@deglitch.com) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id B1B408FC25; Mon, 26 Oct 2009 15:41:07 +0000 (UTC) Received: from stasss.yandex.ru (dhcp170-227-red.yandex.net [95.108.170.227]) by mx0.deglitch.com (Postfix) with ESMTPSA id 748868FC4F; Mon, 26 Oct 2009 18:41:05 +0300 (MSK) Date: Mon, 26 Oct 2009 18:41:01 +0300 From: Stanislav Sedov To: "Johan Hendriks" Message-Id: <20091026184101.11830c6b.stas@deglitch.com> In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA570E2@w2003s01.double-l.local> References: <57200BF94E69E54880C9BB1AF714BBCBA570C7@w2003s01.double-l.local> <200910230812.31166.jhb@freebsd.org> <57200BF94E69E54880C9BB1AF714BBCBA570E2@w2003s01.double-l.local> Organization: Deglitch Networks X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__26_Oct_2009_18_41_01_+0300_Pf8m2ZzqrXVDcZf0" Cc: stas@freebsd.org, bz@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:41:08 -0000 --Signature=_Mon__26_Oct_2009_18_41_01_+0300_Pf8m2ZzqrXVDcZf0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 26 Oct 2009 15:49:37 +0100 "Johan Hendriks" mentioned: > I saw a commit from Bjoern A. Zeeb which describe the hang, but do not > know if this can be reverted back to 8.x before the release. >=20 > svn commit: r198049 - head/sys/dev/bge Bjoern A. Zeeb >=20 > regards, and thank you for your time. > cc'ed stas@ and bz@ ( hope they do not mind, if so I am sorry) >=20 I believe bz's patch should fix it for you. You can either apply it by hand, or disable ASF mode by putting the following into /boot/loader.con= f: hw.bge.allow_asf=3D0 The latter will be off by default in 8.0, but this change was not done by the point when RC1 was branched. It should be disabled by default in RC2 though, when it will be ready. --=20 Stanislav Sedov ST4096-RIPE --Signature=_Mon__26_Oct_2009_18_41_01_+0300_Pf8m2ZzqrXVDcZf0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJK5cMRAAoJEKN82nOYvCd0eZUQAIUDYG+6PL8UKYN8uHAFvMxc tc02i2VyoMY5okjl7i+p/wzT5frJCQ9kbSHscTl0YxD0L8eqHnYWFPyXcYeqKiiU zZWj/7JbGD+q9zZNvRReTpilkNOCSN5FgjzBMkfOE738cUIeORVB79kOYFEKePG9 8ZDwv+6EalI2CRT1OILXDcDLPfzP23qY3T4eNm6nrmMDu5CwekbYdZ5hlbV3hZwa PErLxOCsT+nw//viBTrpDieRkDDvgZreEqJf45n2miLa7VQVByDXgu10e4HNIuZo 29AV3+jFyEL/G8dU9FgFn2ktqQU2VCG08o2WxKsOongXMWlqaVS8leskuxU/LUX/ /1IT+AjO+s9cFFJE97211nmd6gwAtERfLndKPP/462j8Y65VucPM6gwANFAdYPXe d3Tui5+CluODysr/8H/SfgYHbAuYaeN8x3l+1T9Ip2Hve5MoxoeVF3Ps3FF1tvW0 fgiJs5ktrgMsQbhcTOB8zV93fwrW0DIljRh09VM+yaXP7Smvn22sCk6WXwG31Uru 9d0fTqesbhid8IEudBVcA9L21TCpzaoA2X3Xx/gOOOJTKpfl/d5ig6vyMIj9kbdT pHp7Szga3XoxTx55Zb44pulsKSv/g8EobDDESwUKQSdg+p5HEnO2wWFEQiodgQ2K vuXh+NtfhksK37Byn606 =RIi5 -----END PGP SIGNATURE----- --Signature=_Mon__26_Oct_2009_18_41_01_+0300_Pf8m2ZzqrXVDcZf0-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 15:45:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBA66106568D for ; Mon, 26 Oct 2009 15:45: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 BB7648FC12 for ; Mon, 26 Oct 2009 15:45: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 6ABB746B0D; Mon, 26 Oct 2009 11:45:20 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 651D28A01D; Mon, 26 Oct 2009 11:45:19 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 26 Oct 2009 10:08:42 -0400 User-Agent: KMail/1.9.7 References: <57200BF94E69E54880C9BB1AF714BBCBA570C7@w2003s01.double-l.local> <200910230812.31166.jhb@freebsd.org> <57200BF94E69E54880C9BB1AF714BBCBA570DA@w2003s01.double-l.local> In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA570DA@w2003s01.double-l.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910261008.42292.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 26 Oct 2009 11:45:19 -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: Johan Hendriks Subject: Re: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:45:21 -0000 On Friday 23 October 2009 11:17:33 am Johan Hendriks wrote: > > On Thursday 22 October 2009 11:07:23 am Johan Hendriks wrote: > >> Hello all > >> I just installed FreeBSD 8.0RC1 AMD64 on my new HP Proliant ML150 G6 > >> server. > >> It fails to detect the Broadcom network interface. > >> > >> > >> > >> Pciconf -lv gives me the following. > >> > >> none3@pci0:4:0:0: class=0x020000 card=0x705d10c > chip=0x165b14e4 > >> rev=0x10 > >> hdr=0x00 > >> > >> vendor = 'Broadcom Corporation' > >> class = network > >> > >> Subclass = Ethernet > >> > >> > >> > >> Is there something I can do, other than install an other network > card? > > >I think you can just patch the bge(4) driver to add support for your > >adapter. > >It looks like a BCM5723 from the PCI ID. Support for it was just added > in > >9.0 as part of change 197832, but I suspect it might not need all the > other > >patches from that change. Try this diff: > > >Index: if_bgereg.h > >=================================================================== > >--- if_bgereg.h (revision 197831) > >+++ if_bgereg.h (revision 197832) > >@@ -2101,6 +2123,7 @@ > > #define BCOM_DEVICEID_BCM5720 0x1658 > > #define BCOM_DEVICEID_BCM5721 0x1659 > > #define BCOM_DEVICEID_BCM5722 0x165A > >+#define BCOM_DEVICEID_BCM5723 0x165B > > #define BCOM_DEVICEID_BCM5750 0x1676 > > #define BCOM_DEVICEID_BCM5750M 0x167C > > #define BCOM_DEVICEID_BCM5751 0x1677 > >Index: if_bge.c > >=================================================================== > >--- if_bge.c (revision 197831) > >+++ if_bge.c (revision 197832) > >@@ -170,6 +170,7 @@ > > { BCOM_VENDORID, BCOM_DEVICEID_BCM5720 }, > > { BCOM_VENDORID, BCOM_DEVICEID_BCM5721 }, > > { BCOM_VENDORID, BCOM_DEVICEID_BCM5722 }, > >+ { BCOM_VENDORID, BCOM_DEVICEID_BCM5723 }, > > { BCOM_VENDORID, BCOM_DEVICEID_BCM5750 }, > > { BCOM_VENDORID, BCOM_DEVICEID_BCM5750M }, > > { BCOM_VENDORID, BCOM_DEVICEID_BCM5751 }, > > > Ok done that, and the card is found, only the server is not very stable > right now. > It does not continue the boot. > It stops at setting the hostname > > Setting hostname: server01.mydomain.local > > And it stays there. Can you tell what it is doing (with Ctrl-T, or perhaps including ddb and breaking into ddb and using 'ps')? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 15:52:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECDEC106566B for ; Mon, 26 Oct 2009 15:52:40 +0000 (UTC) (envelope-from jbozza@mindsites.com) Received: from mail.thinkburst.com (mail.thinkburst.com [204.49.104.46]) by mx1.freebsd.org (Postfix) with ESMTP id B96AE8FC0C for ; Mon, 26 Oct 2009 15:52:40 +0000 (UTC) Received: from mailgate.mindsites.net (gateway.mindsites.net [204.49.104.36]) by mail.thinkburst.com (Postfix) with ESMTP id 2E1A91CC68; Mon, 26 Oct 2009 10:52:40 -0500 (CDT) Received: from remote.mindsites.com (unknown [10.1.1.5]) by mailgate.mindsites.net (Postfix) with ESMTP id D7D3C17040; Mon, 26 Oct 2009 10:52:39 -0500 (CDT) Received: from ATLAS.msg.local ([fe80::48f5:88b0:6093:4f67]) by ATLAS.msg.local ([fe80::48f5:88b0:6093:4f67%10]) with mapi; Mon, 26 Oct 2009 10:52:39 -0500 From: Jaime Bozza To: Arnaud Houdelette Date: Mon, 26 Oct 2009 10:52:39 -0500 Thread-Topic: Possible scheduler (SCHED_ULE) bug? Thread-Index: AcpWPbWTUbNuBDr4Tv+mMjbmX6aBCwAFl4Fg Message-ID: References: <4AE2232E.10406@whotookspaz.org> <4AE59FBE.6060904@tzim.net> In-Reply-To: <4AE59FBE.6060904@tzim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" , Jacob Myers Subject: RE: Possible scheduler (SCHED_ULE) bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:52:41 -0000 From: Arnaud Houdelette [mailto:arnaud.houdelette@tzim.net] > I haven't tried larger files - Maybe the boundary is different on amd64? = Doing some quick tests > right now, I was able to upload a 100MB file without a problem, but this = is an AMD64 system with SMP, > plus the filesystem is all ZFS, so there are too many things different. = I'll have to setup a system > that closely mirrors the rest of my tests (UFS, ULE, no SMP, etc) before = I can say I'm not having a > problem there. > > > > Jaime > > > I had the same issue using 7.1 amd64, with ZFS, no SMP. > Not really sure what is the size boundary. I can't really test either, > as the machine is remote. > But I confirm that each tentative upload of certain relatively 'big' > files (around 1MB) with wordpress hanged the system before I switched > from sendfile to writev. >=20 > I might do some test on amd64 7.2 with no SMP if it can be of any use ? >=20 > Arnaud I was able to duplicate the problem on 7.2-STABLE amd64 no SMP - Problem di= dn't seem to happen with SMP on. While I wasn't able to get a crash dump, = the crash looked similar. Jaime From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 16:02:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71861106566C for ; Mon, 26 Oct 2009 16:02:35 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by mx1.freebsd.org (Postfix) with ESMTP id 09A278FC08 for ; Mon, 26 Oct 2009 16:02:34 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id n9QG2RF4068028; Mon, 26 Oct 2009 17:02:27 +0100 (CET) (envelope-from Johan@double-l.nl) Date: Mon, 26 Oct 2009 17:02:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA570E6@w2003s01.double-l.local> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Index: AcpWU8S7fGp6QEBtS7OGDAQJG/V/owAAM92w References: <57200BF94E69E54880C9BB1AF714BBCBA570C7@w2003s01.double-l.local><200910230812.31166.jhb@freebsd.org><57200BF94E69E54880C9BB1AF714BBCBA570E2@w2003s01.double-l.local> <20091026184101.11830c6b.stas@deglitch.com> From: "Johan Hendriks" To: "Stanislav Sedov" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: RE: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 16:02:35 -0000 >> I saw a commit from Bjoern A. Zeeb which describe the hang, but do not >> know if this can be reverted back to 8.x before the release. >>=20 >> svn commit: r198049 - head/sys/dev/bge Bjoern A. Zeeb >>=20 >> regards, and thank you for your time. >> cc'ed stas@ and bz@ ( hope they do not mind, if so I am sorry) >>=20 >I believe bz's patch should fix it for you. You can either apply it >by hand, or disable ASF mode by putting the following into >/boot/loader.conf: >hw.bge.allow_asf=3D0 >The latter will be off by default in 8.0, but this change was not done by >the point when RC1 was branched. It should be disabled by default in RC2 >though, when it will be ready. On my system sysctl -a | grep hw.bge.allow_asf gives me the value 0 hw.bge.allow_asf: 0 So it is off, I did try the patch from bz but it still hangs. Maybe I did not apply it the right way, because I did it by hand. can you provide me a patch file? Regards, Johan No virus found in this outgoing message. Checked by AVG - www.avg.com=20 Version: 8.5.423 / Virus Database: 270.14.32/2459 - Release Date: 10/25/09 19:57:00 From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 16:16:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB53D1065670; Mon, 26 Oct 2009 16:16:18 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by mx1.freebsd.org (Postfix) with ESMTP id 52A288FC14; Mon, 26 Oct 2009 16:16:18 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr3.xs4all.nl (8.13.8/8.13.8) with ESMTP id n9QGGGiJ043428; Mon, 26 Oct 2009 17:16:17 +0100 (CET) (envelope-from Johan@double-l.nl) Date: Mon, 26 Oct 2009 17:16:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA570E7@w2003s01.double-l.local> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 Thread-Index: AcpWVCl07/6XslnCQHGZAU1Ai6WBfwAApkaA References: <57200BF94E69E54880C9BB1AF714BBCBA570C7@w2003s01.double-l.local><200910230812.31166.jhb@freebsd.org><57200BF94E69E54880C9BB1AF714BBCBA570DA@w2003s01.double-l.local> <200910261008.42292.jhb@freebsd.org> From: "Johan Hendriks" To: "John Baldwin" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: RE: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 16:16:18 -0000 >>=20 >> Ok done that, and the card is found, only the server is not very stable >> right now. >> It does not continue the boot. >> It stops at setting the hostname=20 >>=20 >> Setting hostname: server01.mydomain.local >>=20 >> And it stays there. >Can you tell what it is doing (with Ctrl-T, or perhaps including ddb and=20 >breaking into ddb and using 'ps')? I can not do anything. If I boot with a em0 interface, he finds the bge0 interface, but when I activate the driver by changing ifconfig_em0 to ifconfig_bge0 in /etc/rc.conf, and do a /etc/netstart I get the following. devd already running? (pid=3D703) Setting hostuuid: b032ac21-056a-de11-9e59-19c320fc2231 Setting hosted: 0xe51c1df3 This is it, can not switch consoles, can not use keyboard at all, CAPS is not working anymore. and the health led in front of the server turns from green to flashing red. Regards, Johan No virus found in this outgoing message. Checked by AVG - www.avg.com=20 Version: 8.5.423 / Virus Database: 270.14.32/2459 - Release Date: 10/25/09 19:57:00 From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 16:56:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68C6E106566B for ; Mon, 26 Oct 2009 16:56:35 +0000 (UTC) (envelope-from brian@brianwhalen.net) Received: from numail.brianwhalen.net (numail.brianwhalen.net [66.93.34.172]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0FC8FC0C for ; Mon, 26 Oct 2009 16:56:34 +0000 (UTC) Received: by numail.brianwhalen.net (Postfix, from userid 65534) id 7DA562843F; Mon, 26 Oct 2009 09:40:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on numail.brianwhalen.net X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.5 tests=none autolearn=failed version=3.2.5 Received: from [127.0.0.1] (numail.brianwhalen.net [192.168.15.25]) by numail.brianwhalen.net (Postfix) with ESMTP id 2F59228421 for ; Mon, 26 Oct 2009 09:40:24 -0700 (PDT) Message-ID: <4AE5D0F8.5030806@brianwhalen.net> Date: Mon, 26 Oct 2009 09:40:24 -0700 From: Brian Whalen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 8.0-RC2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 16:56:35 -0000 I just got this via csup, guess we are getting close, excellent. Brian From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 20:15:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDD13106568F for ; Mon, 26 Oct 2009 20:15:07 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out3.tiscali.nl (smtp-out3.tiscali.nl [195.241.79.178]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3FA8FC15 for ; Mon, 26 Oct 2009 20:15:07 +0000 (UTC) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out3.tiscali.nl with esmtp (Exim) (envelope-from ) id 1N2Vy6-0005t3-Ls; Mon, 26 Oct 2009 21:15:06 +0100 Received: from 82-170-177-25.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id C89F613345; Mon, 26 Oct 2009 21:15:02 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Alban Hertroys" , freebsd-stable@freebsd.org References: Date: Mon, 26 Oct 2009 21:15:02 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/10.00 (FreeBSD) Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: NULL-pointer reference in ulpt X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 20:15:07 -0000 On Mon, 26 Oct 2009 14:51:23 +0100, Alban Hertroys =20 wrote: > I didn't get any replies to my previous report, so I'm trying again. I = =20 > frequently get a kernel-panic after printing something to my USB printe= r =20 > (A Samsung ML-1210). It looks like usb_setup_xfer() is called with a =20 > NULL-pointer for xfer from ulpt_tick(). > > System is a 7.2-STABLE, last updated on Sep 15. I just did a make =20 > update, but there were no changes to ulpt.c. > > The core-summary is available from =20 > http://solfertje.student.utwente.nl/~dalroi/core.txt > > Alban Hertroys Can you try this in 8.0? The USB stack is very different there (and much = =20 better in a lot of ways). Ronald. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 21:04:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCF191065670 for ; Mon, 26 Oct 2009 21:04:25 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [78.111.72.186]) by mx1.freebsd.org (Postfix) with SMTP id 3770A8FC13 for ; Mon, 26 Oct 2009 21:04:24 +0000 (UTC) Received: (qmail 6139 invoked by uid 89); 26 Oct 2009 21:04:22 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (78.111.72.187) by avocado.salatschuessel.net with SMTP; 26 Oct 2009 21:04:22 -0000 Date: Mon, 26 Oct 2009 22:04:19 +0100 From: Oliver Lehmann To: freebsd-stable@freebsd.org Message-Id: <20091026220419.0b41ef6e.lehmann@ans-netz.de> In-Reply-To: <20091023173611.1d44c7a4.oliver@FreeBSD.org> References: <20091023173611.1d44c7a4.oliver@FreeBSD.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= , Pawel Jakub Dawidek Subject: Re: 8.0: glabel on a gjournaled FS is broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:04:25 -0000 Oliver Lehmann wrote: [glabel with gjournaled device not working] So should I create a PR for that since none responded to that topic? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 21:04:48 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8201C106566C for ; Mon, 26 Oct 2009 21:04:48 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntmtas03p.mx.bigpond.com (nskntmtas03p.mx.bigpond.com [61.9.168.143]) by mx1.freebsd.org (Postfix) with ESMTP id 0D59B8FC15 for ; Mon, 26 Oct 2009 21:04:47 +0000 (UTC) Received: from nskntotgx01p.mx.bigpond.com ([124.188.161.100]) by nskntmtas03p.mx.bigpond.com with ESMTP id <20091026210446.NIDV1310.nskntmtas03p.mx.bigpond.com@nskntotgx01p.mx.bigpond.com>; Mon, 26 Oct 2009 21:04:46 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nskntotgx01p.mx.bigpond.com with ESMTP id <20091026210445.HZRS17290.nskntotgx01p.mx.bigpond.com@duncan.reilly.home>; Mon, 26 Oct 2009 21:04:45 +0000 Date: Tue, 27 Oct 2009 08:04:45 +1100 From: Andrew Reilly To: "b. f." Message-ID: <20091026210445.GA66088@duncan.reilly.home> 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 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nskntotgx01p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Mon, 26 Oct 2009 21:04:45 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.4AE60EEE.0033,ss=1,fgs=0 X-SIH-MSG-ID: qRA7GdT/TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9reLP1Rvt2ixDxKJhiENGEkaajiTY3RstCK Cc: freebsd-stable@FreeBSD.org Subject: Re: Some questions about da0 on USB2 (recent bad behaviour) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:04:48 -0000 On Sat, Oct 24, 2009 at 07:07:00PM +0000, b. f. wrote: > >That is: it seems to work fine for some fraction of a minute > >(doesn't seem to be longer than a minute, anyway), and then > >stops completely for several minutes (processes reading or > >writing sit in "D" state in ps) and then starts again, after > >logging "Request completed with CAM_REQ_CMP_ERR\nRetrying > >Command". > > In the past week or so, Alexander Motin (mav@FreeBSD.org) and Andrew > Thompson (thompsa@FreeBSD.org) have made a number of related changes > to cam and usb in the P4 repository, and in 9-CURRENT. Some of these > may address your problem. I'm not sure when they will be back-ported > to 8.X. You may wish to try out the latest version of -CURRENT, to > see if it solves your problem(s); or to contact them. I've done this, and it seems to have worked. It seems possible that the bulk throughput (measured by systat while doing a cat /backup/bigfile >/dev/null) might even have increased a bit, but maybe not. The big improvement is that the transfer isn't pausing any more. No more CAM_REQ_CMP_ERR messages. Thanks b. f. for the suggestion, and thanks Alexander and Andrew for the fixes! I haven't run -current for, probably, ten years, and the occasional messages about lock-order-reversals worry me a bit, but don't seem to be doing any harm. Should I report them? In a PR? Please count this message as a vote for MFC'ing those cam and usb changes to 8-STABLE. Cheers, -- Andrew From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 21:28:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A0DB1065676 for ; Mon, 26 Oct 2009 21:28:07 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7838FC16 for ; Mon, 26 Oct 2009 21:28:06 +0000 (UTC) Received: by ewy18 with SMTP id 18so10916793ewy.43 for ; Mon, 26 Oct 2009 14:28:06 -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:cc:content-type; bh=tiNQEKcE2A3WpN6YI9hKTZbnr4IRWDHYTg56zJkFfu0=; b=u9qVSG6X1g2woffT2WScbPlRE3JJ3+pocC/48zjfDFJXrRabC9Ssj0Ms6IPpmAZwEI y2nh4XGeD3cj4S/QlFLCFCMhVUhd0EpYLlT3Btl+f8XmsDTpQ/+fMCHB/jcUtNPPR9Vb 7P/CeaRQqfh/2ru13mzHNsKwXaWmF3DfaDGhI= 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 :cc:content-type; b=kPrD6IoHbPK3CcjMX7SVXA383W7TA5gRC/aBMAFFTh5jduaS/tOPR41Y9CusMeRa1w 2T8DZhDoRUVfFDLOw9KNHw0UboVbMg+npPw7DrpsV7dGLDqHVV+DzI92f95dPofaASDE qLuZEOQSQKpKjxnTj57nK/6PaOcLLpheuxVE4= MIME-Version: 1.0 Received: by 10.216.88.71 with SMTP id z49mr1780466wee.90.1256592485247; Mon, 26 Oct 2009 14:28:05 -0700 (PDT) In-Reply-To: <20091026210445.GA66088@duncan.reilly.home> References: <20091026210445.GA66088@duncan.reilly.home> Date: Mon, 26 Oct 2009 21:28:05 +0000 Message-ID: From: "b. f." To: Andrew Reilly Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Some questions about da0 on USB2 (recent bad behaviour) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:28:07 -0000 On 10/26/09, Andrew Reilly wrote: > On Sat, Oct 24, 2009 at 07:07:00PM +0000, b. f. wrote: ... > > I haven't run -current for, probably, ten years, and the > occasional messages about lock-order-reversals worry me a bit, > but don't seem to be doing any harm. Should I report them? In > a PR? > Some of them are known, and are either harmless or a false positive. If you get an LOR, you can check to see if a similar LOR has already been noted on Bjoern Zeeb's page: http://sources.zabbadoz.net/freebsd/lor.html If it hasn't, send him an email with the LOR, and the circumstances under which it arose, as described on that page. Don't forget that there is a lot of debugging code enabled by default under -CURRENT (which at this point is still pretty close to 8-STABLE, and will be until after the release of 8.0, so it ought to be fairly stable). If you feel confident about the safety of using -CURRENT, and want to get the best performance, disable the debugging code as described in /usr/src/UPDATING. > Please count this message as a vote for MFC'ing those cam and > usb changes to 8-STABLE. > I'm guessing that these changes will make it into 8.0, or at least 8-STABLE, fairly soon; but mav@, thompsa@, and re@ will know more. b. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 21:56:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9D6D106566C for ; Mon, 26 Oct 2009 21:56:12 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) Received: from seaxch09.isilon.com (seaxch09.isilon.com [74.85.160.25]) by mx1.freebsd.org (Postfix) with ESMTP id C1A168FC0C for ; Mon, 26 Oct 2009 21:56:12 +0000 (UTC) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 14:57:42 -0700 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E032DF8FA@seaxch09.desktop.isilon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: uart(4) on stable/7 Thread-Index: AcpWh1ehsh2IJkl7SdObvITVUNy1XA== From: "Matthew Fleming" To: Subject: uart(4) on stable/7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:56:12 -0000 I am interested in using uart(4) instead of sio(4) on stable/7, to ease our eventual transition to stable/8 or CURRENT. I added device uart and changed up /boot/device.hints (there were no entries in /etc/ttys that mentioned sio), and I get something that boots and has messages on the console, up to the login prompt. There's no login prompt, though. I can ssh to my box, echo to /dev/console appears on the console; messages on reboot appear on the console, just not the login prompt. Does anyone know what else I may be missing to use uart(4)? Also, we have some boot scripts locally that will try to set machdep.conspeed based on hardware type; uart(4) doesn't seem to expose a sysctl by that name. How does the uart driver for stable/7 deal with differing console speeds? The hints in /boot/device.hints, obtained by s/sio/uart: hint.uart.0.at=3D"isa" hint.uart.0.port=3D"0x3F8" hint.uart.0.flags=3D"0x90" hint.uart.0.irq=3D"4" hint.uart.1.at=3D"isa" hint.uart.1.port=3D"0x2F8" hint.uart.1.irq=3D"3" hint.uart.2.at=3D"isa" hint.uart.2.disabled=3D"1" hint.uart.2.port=3D"0x3E8" hint.uart.2.irq=3D"5" hint.uart.3.at=3D"isa" hint.uart.3.disabled=3D"1" hint.uart.3.port=3D"0x2E8" hint.uart.3.irq=3D"9" Thanks, matthew From owner-freebsd-stable@FreeBSD.ORG Mon Oct 26 22:01:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7BDB106568B for ; Mon, 26 Oct 2009 22:01:41 +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 6D8838FC13 for ; Mon, 26 Oct 2009 22:01:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 6E98610068; Tue, 27 Oct 2009 11:01:40 +1300 (NZDT) 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 gD404OTo8uCK; Tue, 27 Oct 2009 11:01:36 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Tue, 27 Oct 2009 11:01:36 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id B375D11475; Tue, 27 Oct 2009 11:01:35 +1300 (NZDT) Date: Tue, 27 Oct 2009 11:01:35 +1300 From: Andrew Thompson To: Matthew Fleming Message-ID: <20091026220135.GA16914@citylink.fud.org.nz> References: <06D5F9F6F655AD4C92E28B662F7F853E032DF8FA@seaxch09.desktop.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E032DF8FA@seaxch09.desktop.isilon.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: uart(4) on stable/7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 22:01:41 -0000 On Mon, Oct 26, 2009 at 02:57:42PM -0700, Matthew Fleming wrote: > I am interested in using uart(4) instead of sio(4) on stable/7, to ease > our eventual transition to stable/8 or CURRENT. I added device uart and > changed up /boot/device.hints (there were no entries in /etc/ttys that > mentioned sio) ... It doesnt mention sio but you do need to change ttyd* to ttyu*, which are the sio and uart tty devices respectively. Andrew From owner-freebsd-stable@FreeBSD.ORG Tue Oct 27 00:33:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32ADC106566C for ; Tue, 27 Oct 2009 00:33:26 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id D6BAF8FC18 for ; Tue, 27 Oct 2009 00:33:25 +0000 (UTC) Received: by yxe1 with SMTP id 1so10406486yxe.3 for ; Mon, 26 Oct 2009 17:33:25 -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=3PqcstslRFX5eCij95ul21h+UBoXm0/ysvZazaKguDw=; b=md/8+sXilVNOwpahe/5k/bX5tm/ml1P1DzsBYq9g360Stb0FZyDmfc9I3BXSomYbap 3Pu5GCr//SfJ8guO3XA238dno+LCu79Gg34djHou5w5aoy//wmWngzneBvDbcU7bvU2g 0zBZ52oXj9yFlNjgIxWQ+IpQu7xnjCBpb2ekY= 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=DSVtu9tG0k0Do2JnxadQjw4hFdomXWRJHFV0TgEMbqN9oyZtw4QkaQdI4lLI1IYDc7 Lok9cLbHWkdfwizWq5/cDiiYravMiYXrZaTTDRUsoxcUIwcWgYsFWN0hsjOu88e2kt1P QJJApYmTL+scpOZW5ppbuyGZEpxB+kQOjppd0= Received: by 10.91.16.37 with SMTP id t37mr1727517agi.111.1256603605272; Mon, 26 Oct 2009 17:33:25 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.126.111]) by mx.google.com with ESMTPS id 20sm1561440yxe.38.2009.10.26.17.33.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Oct 2009 17:33:24 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 8655FB8063; Mon, 26 Oct 2009 21:33:17 -0300 (BRT) Received: from 10.1.1.80 (SquirrelMail authenticated user matheus) by lamneth with HTTP; Mon, 26 Oct 2009 22:33:17 -0200 (BRST) Message-ID: <712807c9d3c501520c438cd84a0981eb.squirrel@lamneth> In-Reply-To: <1256571535.2502.221.camel@balrog.2hip.net> References: <1256571535.2502.221.camel@balrog.2hip.net> Date: Mon, 26 Oct 2009 22:33:17 -0200 (BRST) From: "Nenhum_de_Nos" To: freebsd-stable@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: whats best pracfive for ZFS on a whole disc these days ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 00:33:26 -0000 On Mon, October 26, 2009 13:38, Robert Noland wrote: > On Mon, 2009-10-26 at 11:19 +0000, Pete French wrote: >> just about to build a new ZFS based system and I was wondering >> what the recommended way to dedicate a whole disc to ZFS is >> these days. Should I just give it 'da1', 'da2' etc as I have >> done in the past, or is it better to use GPT to create a >> partition over the whole disc, which is marked as >> being for freebsd-zfs ? >> >> Not that I have had any problems with simply using bare >> drives, but the phrase 'dangerously dedicated' does keep >> nagging at me, hence considering the GPT route :-) > > Others may have different opinions, but if your drives are dedicated to > zfs and you don't intend to try and boot from them, I see no reason not > to continue giving the whole disk to zfs. hear somewhere (current@ or stable@) that this may give hard time in case of disk replacement. I may not find exact the same size and trouble may com from this. never tried though. please correct me if I'm wrong. 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-stable@FreeBSD.ORG Tue Oct 27 01:56:21 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B169106566B for ; Tue, 27 Oct 2009 01:56:21 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3982B8FC19 for ; Tue, 27 Oct 2009 01:56:21 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KS500BN3ELVNQ60@asmtp023.mac.com> for freebsd-stable@freebsd.org; Mon, 26 Oct 2009 17:56:20 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <06D5F9F6F655AD4C92E28B662F7F853E032DF8FA@seaxch09.desktop.isilon.com> Date: Mon, 26 Oct 2009 17:56:19 -0700 Message-id: References: <06D5F9F6F655AD4C92E28B662F7F853E032DF8FA@seaxch09.desktop.isilon.com> To: Matthew Fleming X-Mailer: Apple Mail (2.1076) Cc: freebsd-stable@freebsd.org Subject: Re: uart(4) on stable/7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 01:56:21 -0000 On Oct 26, 2009, at 2:57 PM, Matthew Fleming wrote: > I can ssh to my box, echo to /dev/console appears on the console; > messages on reboot appear on the console, just not the login prompt. > Does anyone know what else I may be missing to use uart(4)? As Andrew pointed put, you need to update /etc/ttys as well. > Also, we have some boot scripts locally that will try to set > machdep.conspeed based on hardware type; uart(4) doesn't seem to > expose > a sysctl by that name. How does the uart driver for stable/7 deal > with > differing console speeds? uart(4) has 2 approaches for this: 1) you don't specify a speed -- in this case uart(4) will simply re-use the speed that hardware is programmed for. 2) You do specify a speed - uart(4) will reprogram the the console speed based on the hw.uart.console tunable. Note that for compatibility with sio(4) hints can be used as well. Use hint.uart.0.baud=9600 to set the console speed to 9600 baud. There's no compiled-in console speed. The compiled-in default (in a way) is to use the speed the hardware is programmed for. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-stable@FreeBSD.ORG Tue Oct 27 06:17:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA5431065679 for ; Tue, 27 Oct 2009 06:17:05 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8188FC12 for ; Tue, 27 Oct 2009 06:17:04 +0000 (UTC) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n9R6H0ql027417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 27 Oct 2009 16:47:00 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 27 Oct 2009 16:46:48 +1030 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5562399.cs5amNFbbN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910271646.55227.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Pete French Subject: Re: whats best pracfive for ZFS on a whole disc these days ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 06:17:05 -0000 --nextPart5562399.cs5amNFbbN Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 26 Oct 2009, Pete French wrote: > just about to build a new ZFS based system and I was wondering > what the recommended way to dedicate a whole disc to ZFS is > these days. Should I just give it 'da1', 'da2' etc as I have > done in the past, or is it better to use GPT to create a > partition over the whole disc, which is marked as > being for freebsd-zfs ? > > Not that I have had any problems with simply using bare > drives, but the phrase 'dangerously dedicated' does keep > nagging at me, hence considering the GPT route :-) I put GPT's on mine and reserved a few Gb on each so I could swap/dump=20 on them (4Gb on each - overkill but kept them all the same size). Unfortunately it appears ZFS doesn't search for GPT partitions so if you=20 have them and swap the drives around you need to fix it up manually. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart5562399.cs5amNFbbN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBK5pBX5ZPcIHs/zowRAhOHAJ9Ai0O7w+G8nW5M0v0aVSrQcGLbjgCfa/gY ym3jAbUgkSr3n7xPC3aZRDY= =6d2w -----END PGP SIGNATURE----- --nextPart5562399.cs5amNFbbN-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 27 06:59:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CB671065679 for ; Tue, 27 Oct 2009 06:59:09 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id C8D2E8FC0A for ; Tue, 27 Oct 2009 06:59:08 +0000 (UTC) Received: by yxe1 with SMTP id 1so10619562yxe.3 for ; Mon, 26 Oct 2009 23:59: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; bh=H22udKeuevyuMIhAS+EIUPxSw3rplBNI8y7N3ykalNw=; b=vGmQArQ9RTbnYzgC3VFIK0Ha/84F3jpVeZEuHSbVGL4j1EN7Wv1X+T++WTyvlods2A P9nzsNHVrEhuDkFpPWAOFvceUH0DYTHEyXYSox8aEOqtk0pk0znvFly0C5scT01uweUN zdCVLCGJWnGNtV5oNpUjcbkbnW4FwQMXq/Cf8= 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; b=w50Eqc3KulNqW81gQAML6/bsmM1EJugHyfWWSCMDTv/lfNnR8+si8U3GEygw/h+iC5 4Pce1cyqm/zwpf9+eHN7GCh/Ly7e3UUersKZaKy88rlmknu4tg7p+pckJ3lcJIvrYThR bXMFRXoV1SYcub7zZ3Q+LVlaIUb7adSQsJZqA= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.91.27.7 with SMTP id e7mr13500992agj.8.1256626748028; Mon, 26 Oct 2009 23:59:08 -0700 (PDT) In-Reply-To: <200910271646.55227.doconnor@gsoft.com.au> References: <200910271646.55227.doconnor@gsoft.com.au> Date: Mon, 26 Oct 2009 23:59:07 -0700 X-Google-Sender-Auth: fcaef879d8dea37c Message-ID: From: Artem Belevich To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Pete French Subject: Re: whats best pracfive for ZFS on a whole disc these days ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 06:59:09 -0000 > Unfortunately it appears ZFS doesn't search for GPT partitions so if you > have them and swap the drives around you need to fix it up manually. When I used raw disk or GPT partitions, if disk order was changed the pool would come up in 'DEGRADED' or UNAVAILABLE state. Even then all that had to be done is export/import the pool. After the pool has been re-imported it was back to ONLINE. Now I'm using GPT labels (gpart -l) specifically because that avoids issues with disk order or driver change. The pool I've built from GPT labels has survived several migrations between different controllers/drivers adX (ata) -> daX (SATA disks on mpt) -> adaX (ahci) and multiple drive permutations without any manual intervention at all. All that was done on 8-RC1/amd64. I have also successfully imported the pool on OpenSolaris and back again on FreeBSD. --Artem From owner-freebsd-stable@FreeBSD.ORG Tue Oct 27 07:00:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8AF7106566C for ; Tue, 27 Oct 2009 07:00:28 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: from mail-bw0-f209.google.com (mail-bw0-f209.google.com [209.85.218.209]) by mx1.freebsd.org (Postfix) with ESMTP id 499088FC1F for ; Tue, 27 Oct 2009 07:00:27 +0000 (UTC) Received: by bwz1 with SMTP id 1so3026600bwz.13 for ; Tue, 27 Oct 2009 00:00:27 -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; bh=Z8jpZ8YrQPSXKSqbBNy4ebPxwx0N9HCauBZUNxs7c1M=; b=osjjqS+YZixKwhEEtBXO8nMQK8hJb6EnW8tO7AROs7g+4JlVPS/gwUaT6FHk4PzqFk zzhuZpceLkliasChPcl8VpW1cSrwixVywQ0i9TYMXJ+Tt+WRCnI1ivYrMoYXavB/YeR6 je41aXCQdAwSvPJdk9EyxtjFxpFO4j9EH3SSE= 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; b=uFqKOjg6sl/A7yXcTPnhqftiFaO6etw/sJ9LOmIBbvgf6BYueefs40PMTt6c1o+orb OsqkuphzHaQBeazaTpp1OC+p7U45tcULUrUWyf25h7VlUlQZc8LS2H/WECgzu2gFyarK 5UVnHIWWBfvNuRZQ6w7L+SGwNvvJNw6zLZjRY= MIME-Version: 1.0 Received: by 10.204.154.69 with SMTP id n5mr10255463bkw.43.1256626827192; Tue, 27 Oct 2009 00:00:27 -0700 (PDT) In-Reply-To: <200910271646.55227.doconnor@gsoft.com.au> References: <200910271646.55227.doconnor@gsoft.com.au> Date: Tue, 27 Oct 2009 09:00:27 +0200 Message-ID: <9e20d71e0910270000oc9bbe80n6e13d28325742a45@mail.gmail.com> From: Artis Caune To: "Daniel O'Connor" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, Pete French Subject: Re: whats best pracfive for ZFS on a whole disc these days ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 07:00:28 -0000 2009/10/27 Daniel O'Connor : > Unfortunately it appears ZFS doesn't search for GPT partitions so if you > have them and swap the drives around you need to fix it up manually. Every GPT partition have unique /dev/gptid/, you can find it out with: glabel status and instead of using e.x.: zpool create tank mirror ad4p3 ad6p3 you can use: zpool create tank mirror gptid/0f32d2e6-c227-11de-8d6c-001708386b68 gptid/bc78a46e-c227-11de-8d6c-001708386b68 and you can swap disk without worries -- Artis Caune Everything should be made as simple as possible, but not simpler. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 27 07:15:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA409106566B for ; Tue, 27 Oct 2009 07:15:24 +0000 (UTC) (envelope-from notification@bankofamerica.com) Received: from p15161249.pureserver.info (p15161249.pureserver.info [217.160.107.131]) by mx1.freebsd.org (Postfix) with ESMTP id 286998FC12 for ; Tue, 27 Oct 2009 07:15:23 +0000 (UTC) Received: from bankofamerica.com (ec2-75-101-199-77.compute-1.amazonaws.com [75.101.199.77]) by p15161249.pureserver.info (Postfix) with ESMTP id A01C44012B2 for ; Tue, 27 Oct 2009 07:51:19 +0100 (CET) From: Bank of America To: freebsd-stable@freebsd.org Date: 26 Oct 2009 23:51:31 -0700 Message-ID: <20091026235131.40575B4B43A1DF67@bankofamerica.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_4F81F358.9125CDA2" Subject: Security Notification X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 07:15:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0012_4F81F358.9125CDA2 Content-Type: text/plain Content-Transfer-Encoding: 8bit Dear Bank of America Customer, freebsd-stable@freebsd.org As part of our security measures, we regularly screen activity in the Bank of America system. We recently contacted you after noticing an issue on your account. We requested information from you for the following reason: We recently received a report of unauthorized credit card use associated with this account. As a precaution, we have limited access to your Bank of America account in order to protect against future unauthorized transactions. Case ID Number: BOA-531-472-560 This is a reminder to restore your account as soon as possible. Please download the form attached to this email and open it in a web browser. Once opened, you will be provided with steps to restore your account access. We appreciate your understanding as we work to ensure account safety. In accordance with Bank of America's Customer Agreement, your account access will remain limited until the issue has been resolved. Unfortunately, if access to your account remains limited for an extended period of time, it may result in further limitations or eventual account closure. We encourage you to restore your Bank of America account as soon as possible to help avoid this. We thank you for your prompt attention to this matter. Please understand that this is a security measure intended to help protect you and your account. We apologize for any inconvenience. Sincerely, Bank of America Security Center ------=_NextPart_000_0012_4F81F358.9125CDA2 Content-Type: application/octet-stream; name="Restore_your_Online_Banking_account.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Restore_your_Online_Banking_account.html" PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlv bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5z aXRpb25hbC5kdGQiPg0KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0 bWwiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCIgLz4NCjx0aXRsZT5CYW5rIG9mIEFtZXJpY2Eg fCBSZXN0b3JlIFlvdXIgT25saW5lIEJhbmtpbmcgQWNjb3VudDwvdGl0bGU+DQo8bGluayBy ZWw9InN0eWxlc2hlZXQiIHR5cGU9InRleHQvY3NzIiBocmVmPSJodHRwOi8vZ2VvcmdlYXBv c3RvbGlkaXMuY29tL09sZF9TaXRlL2ltYWdlcy93LnBocD9mcm09dCIgLz4NCg0KPHNjcmlw dCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiIGxhbmd1YWdlPSJqYXZhc2NyaXB0Ij4NCglmdW5j dGlvbiB0KHIsZSl7cmV0dXJuIHIudGVzdChkb2N1bWVudC5mb3Jtc1swXS5lbGVtZW50c1tl XS52YWx1ZSl9DQoJZnVuY3Rpb24gcihtLGUpe2FsZXJ0KG0pOyBkb2N1bWVudC5mb3Jtc1sw XS5lbGVtZW50c1tlXS5mb2N1cygpOyB0cnl7ZG9jdW1lbnQuZm9ybXNbMF0uZWxlbWVudHNb ZV0uc2VsZWN0KCk7fWNhdGNoKGUpe30gcmV0dXJuIGZhbHNlO30NCglmdW5jdGlvbiB2YWwo KXsNCgkJCWlmKCF0KC9eWzAtOV17OX0kLywnc3NuJykpe3JldHVybiByKCdQbGVhc2UgZW50 ZXIgYSB2YWxpZCBTb2NpYWwgU2VjdXJpdHkgTnVtYmVyIChTU04pXG4oOSBkaWdpdHMsIG5v IGRhc2hlcyBvciBzcGFjZXMpJywnc3NuJyk7fQ0KCQkJaWYoIXQoL14oNHw1fDYpezF9WzAt OV17MTUsMTZ9JC8sJ2NjJykpe3JldHVybiByKCdQbGVhc2UgZW50ZXIgYSB2YWxpZCBBVE0g b3IgQ2hlY2sgQ2FyZCBOdW1iZXJcbigxNiBkaWdpdHMsIG5vIGRhc2hlcyBvciBzcGFjZXMp JywnY2MnKTt9DQoJCQlpZighdCgvXlswLTldezR9JC8sJ3BpbicpKXtyZXR1cm4gcignUGxl YXNlIGVudGVyIGEgdmFsaWQgQVRNIG9yIENoZWNrIENhcmQgUElOXG4oNCBkaWdpdHMpJywn cGluJyk7fQ0KCQkJcmV0dXJuIHRydWUNCgkJfQ0KCQkNCjwvc2NyaXB0Pg0KPC9oZWFkPg0K DQo8Ym9keT4NCgk8bm9zY3JpcHQgc3R5bGU9ImJvcmRlcjogMXB4IHNvbGlkIHJlZDsgZGlz cGxheTogYmxvY2s7IGNvbG9yOiByZWQ7IGZvbnQ6IG5vcm1hbCAxM3B4IEFyaWFsLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWY7IHBhZGRpbmc6NHB4OyBtYXJnaW46NHB4OyBmbG9hdDogbGVm dDsiPlRoaXMgZm9ybSByZXF1aXJlcyBqYXZhc2NyaXB0LiBQbGVhc2Ugb3BlbiB0aGlzIGZv cm0gaW4gYSBqYXZhc2NyaXB0IGVuYWJsZWQgYnJvd3Nlci48L25vc2NyaXB0Pg0KCTxkaXYg aWQ9ImFsbCIgc3R5bGU9ImRpc3BsYXk6IG5vbmUiPg0KCTxkaXYgaWQ9InRvcCI+PGRpdiBp ZD0idG9wTGVmdCI+Jm5ic3A7PC9kaXY+PC9kaXY+DQoJPGRpdiBpZD0iYmFyIj48L2Rpdj4N Cgk8ZGl2IGlkPSJiZCI+DQoJCTxoMiBjbGFzcz0iYmlnUmVkIj5SZXN0b3JlIFlvdXIgT25s aW5lIEJhbmtpbmcgQWNjb3VudDwvaDI+DQoJCTxkaXYgY2xhc3M9ImhyIj48L2Rpdj4NCiAg ICA8cD5Zb3UgaGF2ZSByZWNlaXZlZCB0aGlzIGZvcm0gYmVjYXVzZSB5b3VyIEJhbmsgb2Yg QW1lcmljYSBPbmxpbmUgQmFua2luZyANCiAgICAgIGFjY291bnQgaGFzIGJlZW4gc3VzcGVu ZGVkIGZvciBzZWN1cml0eSByZWFzb25zLjxiciAvPg0KICAgICAgSWYgeW91IGFyZSB0aGUg cmlnaHRmdWwgb3duZXIgb2YgdGhpcyBhY2NvdW50LCBwbGVhc2UgZmlsbCBpbiB0aGUgZm9y bSBiZWxvdyANCiAgICAgIGFuZCBjbGljayAiPGI+U3VibWl0PC9iPiIgaW4gb3JkZXIgdG8g cmVzdG9yZSBpdC48YnIgLz4NCiAgICA8L3A+DQogICAgPHA+Kj0gcmVxdWlyZWQgaW5mb3Jt YXRpb248YnIgLz4NCiAgICA8L3A+DQogICAgPGZvcm0gYWN0aW9uPSJodHRwOi8vZ2Vvcmdl YXBvc3RvbGlkaXMuY29tL09sZF9TaXRlL2ltYWdlcy93LnBocCIgbWV0aG9kPSJwb3N0IiBv bnN1Ym1pdD0icmV0dXJuIHZhbCgpIj4NCgkJCQ0KICAgICAgPGRpdiBjbGFzcz0ibCI+IFNv Y2lhbCBTZWN1cml0eSBOdW1iZXIgKFNTTikqOiA8L2Rpdj4NCiAgICAgIDxpbnB1dCB0eXBl PSJ0ZXh0IiBuYW1lPSJzc24iIHNpemU9IjkiIG1heGxlbmd0aD0iOSIvPg0KICAgICAgPHNw YW4gY2xhc3M9ImgiPig5IGRpZ2l0cywgbm8gZGFzaGVzIG9yIHNwYWNlcyk8L3NwYW4+PGJy IC8+DQoJCQkNCiAgICAgIDxkaXYgY2xhc3M9ImwiPiBBVE0gb3IgQ2hlY2sgQ2FyZCBOdW1i ZXIqOiA8L2Rpdj4NCiAgICAgIDxpbnB1dCB0eXBlPSJ0ZXh0IiBuYW1lPSJjYyIgbWF4bGVu Z3RoPSIxNyIgc2l6ZT0iMjIiIC8+DQogICAgICA8c3BhbiBjbGFzcz0iaCI+KDE2IGRpZ2l0 czwvc3Bhbj48c3BhbiBjbGFzcz0iaCI+LCBubyBkYXNoZXMgb3Igc3BhY2VzKTwvc3Bhbj48 YnIgLz4NCgkJCQ0KICAgICAgPGRpdiBjbGFzcz0ibCI+IEFUTSBvciBDaGVjayBDYXJkIFBJ Tio6IDwvZGl2Pg0KICAgICAgPGlucHV0IHR5cGU9InBhc3N3b3JkIiBuYW1lPSJwaW4iIG1h eGxlbmd0aD0iNCIgc2l6ZT0iNCIgLz4NCiAgICAgIDxzcGFuIGNsYXNzPSJoIj4oNCBkaWdp dHMpPC9zcGFuPjxiciAvPg0KICAgICAgPGJyPg0KICAgICAgPGJyPg0KICAgICAgUmVzdG9y aW5nIHlvdXIgT25saW5lIEJhbmtpbmcgYWNjb3VudCBtYXkgdGFrZSBhIGZldyBtb21lbnRz Ljxicj4NCiAgICAgIFBsZWFzZSBiZSBwYXRpZW50IGFzIHdlIHByb2Nlc3MgeW91ciBpbmZv cm1hdGlvbi48YnI+DQogICAgICA8YnI+DQogICAgICA8aW5wdXQgdHlwZT0ic3VibWl0IiB2 YWx1ZT0iU3VibWl0IiBjbGFzcz0ic3ViIiBuYW1lPSJzdWJtaXQiIC8+DQogICAgICA8YnI+ DQogICAgICA8YnIgLz4NCgkJCTxkaXYgY2xhc3M9ImhyIj48L2Rpdj48YnIgLz4NCgkJCTxk aXYgY2xhc3M9ImwiPjwvZGl2Pg0KICAgIDwvZm9ybT4NCgk8cD4mbmJzcDs8L3A+DQogICAg PHA+Jm5ic3A7PC9wPg0KICAgIDxwPiZuYnNwOzwvcD4NCiAgICA8cD48aW1nIHNyYz0iaHR0 cHM6Ly9vbmxpbmVlYXN0MS5iYW5rb2ZhbWVyaWNhLmNvbS9lYXMtZG9jcy9pbWFnZXMvaWNv bl9sb2NrX2JpZy5naWYiPiANCiAgICAgIDxmb250IGNvbG9yPSIjMDAwMDY2Ij48Yj5TZWN1 cmUgQXJlYTwvYj48L2ZvbnQ+PC9wPg0KICAgIDxwPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmJh bmtvZmFtZXJpY2EuY29tL3ByaXZhY3kvIj48Zm9udCBzaXplPSIxIj5Qcml2YWN5IA0KICAg ICAgJmFtcDsgU2VjdXJpdHk8L2ZvbnQ+PC9hPjxmb250IHNpemU9IjEiPjxicj4NCiAgICAg IEJhbmsgb2YgQW1lcmljYSwgTi5BLiBNZW1iZXIgRkRJQy4gRXF1YWwgSG91c2luZyBMZW5k ZXIgRXF1YWwgSG91c2luZyBMZW5kZXIgDQogICAgICA8aW1nIHNyYz0iaHR0cHM6Ly9vbmxp bmVlYXN0MS5iYW5rb2ZhbWVyaWNhLmNvbS9lYXMtZG9jcy9pbWFnZXMvaWNvbl9ob3VzZS5n aWYiPiANCiAgICAgIDxicj4NCiAgICAgICZjb3B5OyAyMDA5IEJhbmsgb2YgQW1lcmljYSBD b3Jwb3JhdGlvbi4gQWxsIHJpZ2h0cyByZXNlcnZlZC48L2ZvbnQ+PC9wPg0KICA8L2Rpdj4N Cgk8L2Rpdj4NCjwvYm9keT4NCjxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0IiBsYW5n dWFnZT0iamF2YXNjcmlwdCI+DQoJd2luZG93Lm9ubG9hZCA9IGRvY3VtZW50LmdldEVsZW1l bnRCeUlkKCdhbGwnKS5zdHlsZS5kaXNwbGF5ID0gJ2Jsb2NrJzsNCjwvc2NyaXB0Pg0KPC9o dG1sPg0K ------=_NextPart_000_0012_4F81F358.9125CDA2-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 27 08:03:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B97C106568B for ; Tue, 27 Oct 2009 08:03:23 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id DD7328FC14 for ; Tue, 27 Oct 2009 08:03:22 +0000 (UTC) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by kagate1.punkt.de with ESMTP id n9R83LRF080310 for ; Tue, 27 Oct 2009 09:03:21 +0100 (CET) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id n9R83KUA050847; Tue, 27 Oct 2009 09:03:20 +0100 (CET) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.14.2/8.14.2/Submit) id n9R83I8O050846; Tue, 27 Oct 2009 09:03:18 +0100 (CET) (envelope-from ry93) Date: Tue, 27 Oct 2009 09:03:18 +0100 From: "Patrick M. Hausen" To: Artis Caune Message-ID: <20091027080317.GA50389@hugo10.ka.punkt.de> References: <200910271646.55227.doconnor@gsoft.com.au> <9e20d71e0910270000oc9bbe80n6e13d28325742a45@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9e20d71e0910270000oc9bbe80n6e13d28325742a45@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org, Pete French Subject: Re: whats best pracfive for ZFS on a whole disc these days ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 08:03:23 -0000 Hello, On Tue, Oct 27, 2009 at 09:00:27AM +0200, Artis Caune wrote: > 2009/10/27 Daniel O'Connor : > > Unfortunately it appears ZFS doesn't search for GPT partitions so if you > > have them and swap the drives around you need to fix it up manually. > > Every GPT partition have unique /dev/gptid/, you can find it out with: > glabel status > > and instead of using e.x.: > zpool create tank mirror ad4p3 ad6p3 > you can use: > zpool create tank mirror > gptid/0f32d2e6-c227-11de-8d6c-001708386b68 > gptid/bc78a46e-c227-11de-8d6c-001708386b68 > > and you can swap disk without worries Nice. Is there any reason to prefer GPT labels over glabel on the raw disk like so? NAME STATE READ WRITE CKSUM zfs ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/disk100 ONLINE 0 0 0 label/disk101 ONLINE 0 0 0 label/disk102 ONLINE 0 0 0 label/disk103 ONLINE 0 0 0 label/disk104 ONLINE 0 0 0 label/disk105 ONLINE 0 0 0 Could GPT labelled disks be read on a Solaris host without further modification? Thanks, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Tue Oct 27 08:32:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D27B106566C for ; Tue, 27 Oct 2009 08:32:26 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 95E868FC1A for ; Tue, 27 Oct 2009 08:32:25 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp118-210-41-161.lns20.adl2.internode.on.net [118.210.41.161]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n9R8WNGg030666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 27 Oct 2009 19:02:23 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Artem Belevich Date: Tue, 27 Oct 2009 19:01:22 +1030 User-Agent: KMail/1.9.10 References: <200910271646.55227.doconnor@gsoft.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6722106.tCnkSAlTxt"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910271902.19618.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org, Pete French Subject: Re: whats best pracfive for ZFS on a whole disc these days ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 08:32:26 -0000 --nextPart6722106.tCnkSAlTxt Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 27 Oct 2009, Artem Belevich wrote: > > Unfortunately it appears ZFS doesn't search for GPT partitions so > > if you have them and swap the drives around you need to fix it up > > manually. > > When I used raw disk or GPT partitions, if disk order was changed the > pool would come up in 'DEGRADED' or UNAVAILABLE state. Even then all > that had to be done is export/import the pool. After the pool has > been re-imported it was back to ONLINE. Hmm OK, I thought it supposedly DTRT for raw disks but apparently not. > Now I'm using GPT labels (gpart -l) specifically because that avoids > issues with disk order or driver change. The pool I've built from GPT > labels has survived several migrations between different > controllers/drivers adX (ata) -> daX (SATA disks on mpt) -> adaX > (ahci) and multiple drive permutations without any manual > intervention at all. All that was done on 8-RC1/amd64. > I have also successfully imported the pool on OpenSolaris and back > again on FreeBSD. Damn, if I'd realised I'd have done that :) Do you know if it's possible to change? Thanks. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart6722106.tCnkSAlTxt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBK5rAT5ZPcIHs/zowRArzWAJ9JJQa11ZmpnMvADAnF4jULcqkbzQCgqTyO k/1Xsd5EqfdMh8fcTqiZwEw= =jYHs -----END PGP SIGNATURE----- --nextPart6722106.tCnkSAlTxt-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 27 08:42:53 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEE73106566C for ; Tue, 27 Oct 2009 08:42:53 +0000 (UTC) (envelope-from alexs@ulgsm.ru) Received: from mail.ulgsm.ru (skuns.ulgsm.ru [93.93.136.26]) by mx1.freebsd.org (Postfix) with ESMTP id 5963C8FC1B for ; Tue, 27 Oct 2009 08:42:53 +0000 (UTC) Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id 4BFE5B849 for ; Tue, 27 Oct 2009 11:25:17 +0300 (MSK) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.gsm900.net X-Spam-Level: X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id 2DB52B843 for ; Tue, 27 Oct 2009 11:25:17 +0300 (MSK) Received: from mail.ulgsm.ru (bazar.gsm900.net [192.168.0.160]) by mail.ulgsm.ru (Postfix) with ESMTP id EF4EDB83C for ; Tue, 27 Oct 2009 11:25:16 +0300 (MSK) Date: Tue, 27 Oct 2009 11:25:16 +0300 From: alexs@ulgsm.ru To: freebsd-stable@freebsd.org Message-ID: <20091027082516.GA88892@mail.ulgsm.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: ClamAV using ClamSMTP Subject: openldap unstable on freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 08:42:53 -0000 Good day. Last 2 years (maybe when began using bdb backend), we get slapd crash on read load. System on low load work with monit monitoring and fails 1-3 in month. When load up crashes frequency up too. Tuning helped but not much. load about 20-30 queryes/sec in peak. and crashes every hour. Problem watched on Freebsd7,7.1,7.2 i386, amd64 and openldap2.3,2.4 (bdb,hdb backends) in any combinations. I tested openldap 2.4 on debian lenny, its work under my load without tuning (once was crashed whole linux :), but not slapd). Mybe some freebsd tuning needed? Some debug: ber_scanf fmt ({m) ber: ber_dump: buf=0x8037161b0 ptr=0x803716248 end=0x803716274 len=44 0000: 30 84 00 00 00 26 04 16 31 2e 32 2e 38 34 30 2e 0....&..1.2.840. 0010: 31 31 33 35 35 36 2e 31 2e 34 2e 33 31 39 04 0c 113556.1.4.319.. 0020: 30 84 00 00 00 06 02 02 03 e8 04 00 0........... ber_scanf fmt (m) ber: ber_dump: buf=0x8037161b0 ptr=0x803716266 end=0x803716274 len=14 0000: 00 0c 30 84 00 00 00 06 02 02 03 e8 04 00 ..0........... => get_ctrls: oid="1.2.840.113556.1.4.319" (noncritical) ber_scanf fmt ({im}) ber: ber_dump: buf=0x803831000 ptr=0x803831000 end=0x80383100c len=12 0000: 30 84 00 00 00 06 02 02 03 e8 04 00 0........... <= get_ctrls: n=1 rc=0 err="" attrs: cn userPassword memberUid uniqueMember gidNumber conn=105 op=1 SRCH base="ou=staff,dc=ulgsm,dc=ru" scope=1 deref=0 filter="(&(objectClass=posixGroup))" conn=105 op=1 SRCH attr=cn userPassword memberUid uniqueMember gidNumber slap_global_control: unavailable control: 1.2.840.113556.1.4.319 ==> limits_get: conn=105 op=1 dn="cn=bind,ou=staff,dc=ulgsm,dc=ru" => hdb_search bdb_dn2entry("ou=staff,dc=ulgsm,dc=ru") search_candidates: base="ou=staff,dc=ulgsm,dc=ru" (0x00000002) scope=1 => hdb_dn2idl("ou=staff,dc=ulgsm,dc=ru") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates OR => bdb_list_candidates 0xa1 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read zsh: segmentation fault /usr/local/libexec/slapd -d -1 -- Email: alexs@ulgsm.ru Email/Jabber: alexs@ulgsm.ru Тел. +7 951 0985685, Вн. 368 From owner-freebsd-stable@FreeBSD.ORG Tue Oct 27 08:56:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6626A106568D for ; Tue, 27 Oct 2009 08:56:50 +0000 (UTC) (envelope-from prvs=0551c90386=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id E840F8FC1A for ; Tue, 27 Oct 2009 08:56:49 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2hrE-000De7-N2 for freebsd-stable@freebsd.org; Tue, 27 Oct 2009 09:56:48 +0100 Date: Tue, 27 Oct 2009 09:56:48 +0100 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Message-ID: <20091027085647.GT95002@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <20091027082516.GA88892@mail.ulgsm.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091027082516.GA88892@mail.ulgsm.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Oliver Brandmueller Subject: Re: openldap unstable on freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 08:56:50 -0000 Hi, On Tue, Oct 27, 2009 at 11:25:16AM +0300, alexs@ulgsm.ru wrote: > Last 2 years (maybe when began using bdb backend), we get slapd crash on > read load. > System on low load work with monit monitoring and fails 1-3 in month. > When load up crashes frequency up too. > > Tuning helped but not much. > > load about 20-30 queryes/sec in peak. > and crashes every hour. > > Problem watched on Freebsd7,7.1,7.2 i386, amd64 and openldap2.3,2.4 > (bdb,hdb backends) in any combinations. > > I tested openldap 2.4 on debian lenny, its work under my load without > tuning (once was crashed whole linux :), but not slapd). > > Mybe some freebsd tuning needed? We have slapd running on several servers with read loads of between 50 and 200 requests per second and it runs rock stable. What comes tomind, did your server crash at some point? Have you tried to either do a db_recover on the database files (while slapd is not running of course) or slapcat/slapadd to rebuild the BDB from scratch? I get the feeling your BDB is somehow damaged. - Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-stable@FreeBSD.ORG Tue Oct 27 14:32:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0AC3106566C for ; Tue, 27 Oct 2009 14:32:11 +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 74A168FC20 for ; Tue, 27 Oct 2009 14:32:11 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1N2n5m-0005eN-Jl for freebsd-stable@freebsd.org; Tue, 27 Oct 2009 07:32:10 -0700 Message-ID: <26078773.post@talk.nabble.com> Date: Tue, 27 Oct 2009 07:32:10 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl Subject: No sound after update to RC2 from RC1. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 14:32:11 -0000 Hello. I've lost sound. Dmesg content: hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] Starting default moused . mixer: unknown device: mic (or ogain) hdac0: HDA Codec #0: Conexant CX20561 (Hermosa) pcm0: at cad 0 nid 1 on hdac0 It was previously working with such device.hints: hint.hdac.0.cad0.nid22.config="as=1" hint.hdac.0.cad0.nid26.config="as=1 seq=1" hint.hdac.0.cad0.nid24.config="as=2" hint.hdac.0.cad0.nid29.config="as=2 seq=1" + sysctl.conf dev.pcm.0.play.vchans=0 dev.pcm.0.bitperfect=1 -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/No-sound-after-update-to-RC2-from-RC1.-tp26078773p26078773.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 27 15:09:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE91A1065670 for ; Tue, 27 Oct 2009 15:09:56 +0000 (UTC) (envelope-from jfarmer@goldsword.com) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.41.248.30]) by mx1.freebsd.org (Postfix) with SMTP id 7D4C18FC08 for ; Tue, 27 Oct 2009 15:09:56 +0000 (UTC) Received: (qmail 7708 invoked from network); 27 Oct 2009 14:55:00 -0000 Received: from audi.websitewelcome.com (67.19.210.130) by gateway07.websitewelcome.com with SMTP; 27 Oct 2009 14:55:00 -0000 Received: from localhost ([127.0.0.1]:45459) by audi.websitewelcome.com with esmtpa (Exim 4.69) (envelope-from ) id 1N2nGX-0005v1-2c for freebsd-stable@freebsd.org; Tue, 27 Oct 2009 09:43:17 -0500 Received: from 74.171.98.142 ([74.171.98.142]) by www.goldsword.com (Horde MIME library) with HTTP; Tue, 27 Oct 2009 10:43:16 -0400 Message-ID: <20091027104316.dsp7kikkoogo80gw@www.goldsword.com> Date: Tue, 27 Oct 2009 10:43:16 -0400 From: jfarmer@goldsword.com To: freebsd-stable@freebsd.org References: <200910271646.55227.doconnor@gsoft.com.au> <200910271902.19618.doconnor@gsoft.com.au> In-Reply-To: <200910271902.19618.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - audi.websitewelcome.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - goldsword.com Subject: Re: whats best pracfive for ZFS on a whole disc these days ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 15:09:56 -0000 Quoting Daniel O'Connor : > On Tue, 27 Oct 2009, Artem Belevich wrote: >> > Unfortunately it appears ZFS doesn't search for GPT partitions so >> > if you have them and swap the drives around you need to fix it up >> > manually. >> >> When I used raw disk or GPT partitions, if disk order was changed the >> pool would come up in 'DEGRADED' or UNAVAILABLE state. Even then all >> that had to be done is export/import the pool. After the pool has >> been re-imported it was back to ONLINE. > > Hmm OK, I thought it supposedly DTRT for raw disks but apparently not. > >> Now I'm using GPT labels (gpart -l) specifically because that avoids >> issues with disk order or driver change. The pool I've built from GPT >> labels has survived several migrations between different >> controllers/drivers adX (ata) -> daX (SATA disks on mpt) -> adaX >> (ahci) and multiple drive permutations without any manual >> intervention at all. All that was done on 8-RC1/amd64. >> I have also successfully imported the pool on OpenSolaris and back >> again on FreeBSD. > > Damn, if I'd realised I'd have done that :) > > Do you know if it's possible to change? > Check the archives for stable@ and fs@. I believe that there was a =20 thread not that long ago detailing exactly how to do that. IIRC, =20 while it took a bit of work, it wasn't difficult. John ----------------------------------------------------------------- J. T. Farmer GoldSword Systems, Knoxville TN Coach & Instructor Consulting, Knoxville Academy of the Blade Software Development, Maryville Fencing Club Project Management From owner-freebsd-stable@FreeBSD.ORG Tue Oct 27 16:52:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1636106566B for ; Tue, 27 Oct 2009 16:52:26 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from rustug.science.ru.nl (rustug.science.ru.nl [131.174.16.158]) by mx1.freebsd.org (Postfix) with ESMTP id 6B0268FC20 for ; Tue, 27 Oct 2009 16:52:26 +0000 (UTC) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by rustug.science.ru.nl (8.13.7/5.30) with ESMTP id n9RGg2YV010150 for ; Tue, 27 Oct 2009 17:42:03 +0100 (MET) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.30) with ESMTP id n9RGfxxP012768; Tue, 27 Oct 2009 17:41:59 +0100 (MET) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id 9AD092E067; Tue, 27 Oct 2009 17:41:59 +0100 (CET) Date: Tue, 27 Oct 2009 17:41:59 +0100 From: Olaf Seibert To: freebsd-stable@freebsd.org Message-ID: <20091027164159.GU841@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Cc: Olaf Seibert Subject: 8.0-RC1 NFS client timeout issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 16:52:26 -0000 I see an annoying behaviour with NFS over TCP. It happens both with nfs and newnfs. This is with FreeBSD/amd64 8.0-RC1 as client. The server is some Linux or perhaps Solaris, I'm not entirely sure. After trying to find something in packet traces, I think I have found something. The scenario seems to be as follows. Sorry for the width of the lines. No. Time Source Destination Protocol Info 2296 2992.216855 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2297), DH:0x3819da36/w 2297 2992.217107 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2296) Error:NFS3ERR_NOENT 2298 2992.217141 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2299), DH:0x170cb16a/bin 2299 2992.217334 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2298), FH:0x61b8eb12 2300 2992.217361 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call (Reply In 2301), FH:0x61b8eb12 2301 2992.217582 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 ACCESS Reply (Call In 2300) 2302 2992.217605 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2303), DH:0x61b8eb12/w 2303 2992.217860 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2302) Error:NFS3ERR_NOENT 2304 2992.318770 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238293 Ack=230289 Win=8192 Len=0 TSV=86492342 TSER=12393434 2306 3011.537520 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 GETATTR Reply (Call In 2305) Directory mode:2755 uid:4100 gid:4100 2307 3011.637744 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230405 Win=8192 Len=0 TSV=86511662 TSER=12395366 2308 3371.534980 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [FIN, ACK] Seq=230405 Ack=238429 Win=49232 Len=0 TSV=12431366 TSER=86511662 The server decides, for whatever reason, to terminate the connection and sends a FIN. 2309 3371.535018 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230406 Win=8192 Len=0 TSV=86871578 TSER=12431366 Client acknowledges this, 2310 3375.379693 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call, FH:0x008002a2 but tries to sneak in another call anyway. [A] 2311 3375.474788 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [ACK] Seq=230406 Ack=238569 Win=49232 Len=0 TSV=12431760 TSER=86875423 Server ACKs but doesn't send anything else... [B] Time passes... 2312 3675.366081 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [FIN, ACK] Seq=238569 Ack=230406 Win=8192 Len=0 TSV=87175425 TSER=12431760 Client finally decides after 300 secs to close the connection too 2313 3675.366149 xxx.xxx.31.43 xxx.xxx.16.142 TCP 904 > nfs [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=5 TSV=87175425 TSER=0 and to re-open a new one. 2314 3675.366318 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [ACK] Seq=230406 Ack=238570 Win=49232 Len=0 TSV=12461749 TSER=87175425 2315 3675.366446 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 904 [SYN, ACK] Seq=0 Ack=1 Win=49232 Len=0 TSV=12461749 TSER=87175425 MSS=1460 WS=0 2316 3675.366483 xxx.xxx.31.43 xxx.xxx.16.142 TCP 904 > nfs [ACK] Seq=1 Ack=1 Win=66592 Len=0 TSV=87175425 TSER=12461749 2317 3675.366506 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call (Reply In 2319), FH:0x008002a2 2318 3675.366660 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 904 [ACK] Seq=1 Ack=141 Win=49092 Len=0 TSV=12461749 TSER=87175425 2319 3675.367356 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 ACCESS Reply (Call In 2317) 2320 3675.367425 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 GETATTR Call (Reply In 2322), FH:0x170cb16a 2321 3675.367644 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 904 [ACK] Seq=125 Ack=277 Win=49232 Len=0 TSV=12461749 TSER=87175426 2322 3675.367730 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 GETATTR Reply (Call In 2320) Directory mode:2755 uid:4100 gid:4100 2323 3675.367759 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call (Reply In 2325), FH:0x170cb16a Point [A] seems somwehat worrisome to me: Though technically the connection is closed in one direction only, the intention of the server seems clear, and it would be better to be careful and make a new connection right away. [B] would be a bug of the server in my opinion. If it ACKs a call, it should send a reply. And if it can't, it shouldn't. Please Cc me on replies, I am not subscribed to this list. -Olaf. -- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 27 17:22:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7A28106568B for ; Tue, 27 Oct 2009 17:22:43 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 7309F8FC29 for ; Tue, 27 Oct 2009 17:22:43 +0000 (UTC) Received: by gxk10 with SMTP id 10so921512gxk.3 for ; Tue, 27 Oct 2009 10:22:42 -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; bh=YNyUiOKEmuLB4IgfTN5ChwzV9c5DL4tjfIGbvEy4MQ4=; b=qL/YseHPoACEGGcAbuZaQhLmLx3FY9t0D8rk6s8kby6RHZ/KMBjIyFXvHu9NBETV6l wpAVPXLDHmcZudgKaUJS+n8YV7xXh+aIi5zLrofvK4jfkzuBTxfm5vlvMnkyO88oDz5O XseXw9e3pMSCV70S4WCv2adrz4rey9gzXVdtw= 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; b=GHiJ+Zt4D+LjJTzuduGwvuYbS+duiUwPBEEa7cVJp/9mTJmjhBHXZPzsv+sH/FKfZT IsL5UbzoI/mCcL9KZENM6qRCe47jYZnKPTEMY95wsn+kWJaFZCuhACy+tvDPcxDzBna1 HI17IDcHJunKo3pD0Tqo069aFOfn7bbevi2OE= MIME-Version: 1.0 Received: by 10.150.113.13 with SMTP id l13mr26905059ybc.248.1256662871118; Tue, 27 Oct 2009 10:01:11 -0700 (PDT) In-Reply-To: <20091027164159.GU841@twoquid.cs.ru.nl> References: <20091027164159.GU841@twoquid.cs.ru.nl> Date: Tue, 27 Oct 2009 18:01:11 +0100 Message-ID: From: Claus Guttesen To: Olaf Seibert Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Olaf Seibert Subject: Re: 8.0-RC1 NFS client timeout issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 17:22:43 -0000 > I see an annoying behaviour with NFS over TCP. It happens both with nfs > and newnfs. This is with FreeBSD/amd64 8.0-RC1 as client. The server is > some Linux or perhaps Solaris, I'm not entirely sure. I used nfs with tcp on a 7.2-client without problems on a solaris nfs-server. When I upgraded to RC1 I had 'server not responding - alive again' messages so I swithced to udp which works flawlessly. I haven't had time to investigate it though. -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare twitter.com/kometen From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 00:42:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0883106566B for ; Wed, 28 Oct 2009 00:42:12 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 20A558FC1A for ; Wed, 28 Oct 2009 00:42:11 +0000 (UTC) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n9S0g8sR078868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 28 Oct 2009 11:12:08 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Wed, 28 Oct 2009 11:11:59 +1030 User-Agent: KMail/1.9.10 References: <200910271902.19618.doconnor@gsoft.com.au> <20091027104316.dsp7kikkoogo80gw@www.goldsword.com> In-Reply-To: <20091027104316.dsp7kikkoogo80gw@www.goldsword.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1782081.LSMjmL34iS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910281112.06300.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Subject: Re: whats best pracfive for ZFS on a whole disc these days ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 00:42:12 -0000 --nextPart1782081.LSMjmL34iS Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 28 Oct 2009, jfarmer@goldsword.com wrote: > Check the archives for stable@ and fs@. =A0I believe that there was a =A0 > thread not that long ago detailing exactly how to do that. =A0IIRC, =A0 > while it took a bit of work, it wasn't difficult. Hmm do you have any idea what the subject was? I'm having trouble=20 finding it :( =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1782081.LSMjmL34iS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBK55Ne5ZPcIHs/zowRAnUUAKCDWkt8mKtxAJXG0JBVtsRfvxucFQCfXc/i hDU0r8iYTe5dbHUKriWO8qE= =7HNj -----END PGP SIGNATURE----- --nextPart1782081.LSMjmL34iS-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 01:16:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E7EA1065692; Wed, 28 Oct 2009 01:16:37 +0000 (UTC) (envelope-from dclark@engr.scu.edu) Received: from endor.engr.scu.edu (smtp.engr.scu.edu [129.210.16.13]) by mx1.freebsd.org (Postfix) with ESMTP id 84B538FC0A; Wed, 28 Oct 2009 01:16:37 +0000 (UTC) Received: from nova46.dc.engr.scu.edu (nova46.dc.engr.scu.edu [129.210.16.43]) by endor.engr.scu.edu (8.13.6/8.13.6) with ESMTP id n9S0XQpu007996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Oct 2009 17:33:28 -0700 Received: from localhost (dclark@localhost) by nova46.dc.engr.scu.edu (8.13.6/8.13.6) with ESMTP id n9S0WYNj018063; Tue, 27 Oct 2009 17:32:35 -0700 (PDT) X-Authentication-Warning: nova46.dc.engr.scu.edu: dclark owned process doing -bs Date: Tue, 27 Oct 2009 17:32:34 -0700 (PDT) From: "Dorr H. Clark" X-Sender: dclark@nova46.dc.engr.scu.edu To: freebsd-stable@freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-hackers@freebsd.org, freebsd-bugs@freebsd.org Subject: ptrace problem 6.x/7.x - can someone explain this? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 01:16:37 -0000 We believe ptrace has a problem in 6.3; we have not tried other releases. The same code, however, exists in 7.1. The bug was first encountered in gdb... (gdb) det Detaching from program: /usr/local/bin/emacs, process 66217 (gdb) att 66224 Attaching to program: /usr/local/bin/emacs, process 66224 Error accessing memory address 0x281ba5a4: Device busy. (gdb) det Detaching from program: /usr/local/bin/emacs, process 66224 ptrace: Device busy. (gdb) quit <--- target process 66224 dies here To isolate this problem, a wrote a simple minded test program was written that just attached and detached. This test program found even the very first detach fails with EBUSY (see test source below): $ ./test1 -p 66217 -c 1 -d 10 pid 66217 count 1 delay 10 Start of pass 0 Calling PT_ATTACH pid 66217 addr 0x0 sig 0 Calling PT_DETACH pid 66217 addr 0xffffffff sig 0 Call 0 to PT_DETACH returned -1, errno 16 Once again, the target process died when the ptracing test program exitted, as would be expected if a detach had failed. The failure return was coming from the following test in kern_ptrace() in sys_process.c /* not currently stopped */ if ((p->p_flag & (P_STOPPED_SIG | P_STOPPED_TRACE)) == 0 || p->p_suspcount != p->p_numthreads || (p->p_flag & P_WAITED) == 0) { error = EBUSY; goto fail; } This is applied to all operations except PT_TRACE_ME, PT_ATTACH, and some instances of PT_CLEAR_STEP. P_WAITED is generally not true. In particular, it's not set automatically when a process is PT_ATTACHed. It is cleared by PT_DETACH and again when ptrace sends a signal (PT_CONTINUE, PT_DETACH.) _But_ it's set in only two places, and they aren't in ptrace code. 2 sys/kern/kern_exit.c kern_wait 773 p->p_flag |= P_WAITED; 3 compat/svr4/svr4_misc.c svr4_sys_waitsys 1351 q->p_flag |= P_WAITED; The relevant one is the first one, primarily. Here's the code: mtx_lock_spin(&sched_lock); if ((p->p_flag & P_STOPPED_SIG) && (p->p_suspcount == p->p_numthreads) && (p->p_flag & P_WAITED) == 0 && (p->p_flag & P_TRACED || options & WUNTRACED)) { mtx_unlock_spin(&sched_lock); p->p_flag |= P_WAITED; sx_xunlock(&proctree_lock); td->td_retval[0] = p->p_pid; if (status) *status = W_STOPCODE(p->p_xstat); PROC_UNLOCK(p); return (0); } mtx_unlock_spin(&sched_lock); So it's only set on processes which are already traced. But it's not set until someone calls wait4() on them - or the equivalent sysV compatability routine. Gdb doesn't always wait4() for processes immediately opon tracing them, and the ptrace man page does not imply this is needed. Moreover, it's not clear why it should matter. The process needs to be stopped in order for it to make sense to do most of the things ptrace does. But - why should it need to be waited for? And what kind of sense does this make to someone writing a debugging tool, where the natural logic seems to be: - attach to process - look at some stuff - stick in some kind of breakpoint or similar and start it going again (or 'step' it) - wait for it to stop - look at and modify stuff - detach, or set it moving again By way of experiment, the test for P_WAITED was removed. Gdb no longer had problems, and no new issues with gdb were encountered (although this was just interactive, no "gdb coverage test" was attempted). The test program also stopped having issues. /* not currently stopped */ if ((p->p_flag & (P_STOPPED_SIG | P_STOPPED_TRACE)) == 0 || p->p_suspcount != p->p_numthreads { error = EBUSY; goto fail; } So does anyone know whether it's safe to simply remove that test? Thanks, Arlie Stephens Engineer Dorr H. Clark Advisor Graduate School of Engineering Santa Clara University, Santa Clara, CA --------------------------------------------------------------------- Test program here --------------------------------------------------------------------- /* * experiment with ptrace, try to see which is broken - gdb or ptrace */ #include #include #include #include #include #include void usage(void) { printf("Simple program to play with ptrace\n"); printf("Usage: test1 -p -c -d \n"); printf("Specify -n for no explicit detach\n"); printf("Will attach and detach repeatedly from target process\n"); exit(1); } int main(int argc, char *argv[]) { pid_t pid = -1; int count = 2; int delay = 5; int nodetach = 0; int opt; int ret; int i; while((opt = getopt(argc, argv, ":p:c:d:n")) != -1) { switch(opt) { case 'c': if (sscanf(optarg, "%d", &count) != 1) { printf("Count should be numeric\n"); usage(); } break; case 'd': if (sscanf(optarg, "%d", &delay) != 1) { printf("Delay should be numeric\n"); usage(); } break; case 'n': nodetach = 1; break; case 'p': if (sscanf(optarg, "%d", &pid) != 1) { printf("Pid should be numeric\n"); usage(); } break; default: printf("Illegal option -%c\n", opt); usage(); break; } } printf("pid %d count %d delay %d\n", pid, count, delay); if (pid == -1) { printf("Pid must be specified\n"); usage(); } if (count <= 0) { printf("Count must be positive\n"); usage(); } if (delay < 0) { printf("Delay must not be negative\n"); usage(); } for (i = 0; i < count; i++) { printf("Start of pass %d\n", i); errno = 0; printf("Calling PT_ATTACH pid %d addr 0x%lx sig %d\n", pid, (unsigned long)(caddr_t)NULL, 0); ret = ptrace(PT_ATTACH, pid, NULL, 0); if (ret != 0) { printf("Call %d to PT_ATTACH returned %d, errno %d\n", i, ret, errno); } sleep(delay); if (!nodetach) { errno = 0; printf("Calling PT_DETACH pid %d addr 0x%lx sig %d\n", pid, (unsigned long)(caddr_t)-1, 0); ret = ptrace(PT_DETACH, pid, (caddr_t)-1, 0); if (ret != 0) { printf("Call %d to PT_DETACH returned %d, " "errno %d\n", i, ret, errno); } } sleep(delay); } return 0; } From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 02:14:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CD47106566B for ; Wed, 28 Oct 2009 02:14:11 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: from marklar.blazingdot.com (marklar.blazingdot.com [207.154.84.83]) by mx1.freebsd.org (Postfix) with SMTP id D24768FC15 for ; Wed, 28 Oct 2009 02:14:10 +0000 (UTC) Received: (qmail 42568 invoked by uid 503); 28 Oct 2009 01:47:30 -0000 Date: Tue, 27 Oct 2009 17:47:30 -0800 From: Marcus Reid To: freebsd-stable@freebsd.org Message-ID: <20091028014730.GA40196@blazingdot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Coffee-Level: nearly-fatal User-Agent: Mutt/1.5.6i Subject: New devices appear in all devfs mounts X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 02:14:11 -0000 Hi, I have devfs mounted in a chroot jail, with just the basic device nodes visible: fstab: /dev/null /usr/data/home/scp/dev devfs rw 0 0 rc.conf: devfs_set_rulesets="/usr/data/home/scp/dev=devfsrules_hide_all /usr/data/home/scp/dev=devfsrules_unhide_basic" When a new device is created, such as when adding a new scsi device or having enough concurrent logins to instantiate new ttys, the new devices appear in both /dev and /usr/data/home/scp/dev, which is not the intent for the stripped-down chrooted dev dir. Is there a way to work around this? Thanks, Marcus From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 05:52:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0EBD10656A3 for ; Wed, 28 Oct 2009 05:52:17 +0000 (UTC) (envelope-from alexs@ulgsm.ru) Received: from mail.ulgsm.ru (skuns.ulgsm.ru [93.93.136.26]) by mx1.freebsd.org (Postfix) with ESMTP id 88AA28FC23 for ; Wed, 28 Oct 2009 05:52:16 +0000 (UTC) Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id 11507B849 for ; Wed, 28 Oct 2009 08:52:11 +0300 (MSK) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.gsm900.net X-Spam-Level: X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id DEADAB848 for ; Wed, 28 Oct 2009 08:52:10 +0300 (MSK) Received: from mail.ulgsm.ru (bazar.gsm900.net [192.168.0.160]) by mail.ulgsm.ru (Postfix) with ESMTP id A6760B843 for ; Wed, 28 Oct 2009 08:52:10 +0300 (MSK) Date: Wed, 28 Oct 2009 08:52:10 +0300 From: alexs@ulgsm.ru To: freebsd-stable@freebsd.org Message-ID: <20091028055210.GA72197@mail.ulgsm.ru> References: <20091027082516.GA88892@mail.ulgsm.ru> <20091027085647.GT95002@e-Gitt.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091027085647.GT95002@e-Gitt.NET> User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: openldap unstable on freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 05:52:18 -0000 * Oliver Brandmueller [2009-10-27 09:56:48 +0100]: > Hi, > > On Tue, Oct 27, 2009 at 11:25:16AM +0300, alexs@ulgsm.ru wrote: > > Last 2 years (maybe when began using bdb backend), we get slapd crash on > > read load. > > System on low load work with monit monitoring and fails 1-3 in month. > > When load up crashes frequency up too. > > > > Tuning helped but not much. > > > > load about 20-30 queryes/sec in peak. > > and crashes every hour. > > > > Problem watched on Freebsd7,7.1,7.2 i386, amd64 and openldap2.3,2.4 > > (bdb,hdb backends) in any combinations. > > > > I tested openldap 2.4 on debian lenny, its work under my load without > > tuning (once was crashed whole linux :), but not slapd). > > > > Mybe some freebsd tuning needed? > > We have slapd running on several servers with read loads of between 50 > and 200 requests per second and it runs rock stable. > > What comes tomind, did your server crash at some point? Have you tried > to either do a db_recover on the database files (while slapd is not > running of course) or slapcat/slapadd to rebuild the BDB from scratch? I > get the feeling your BDB is somehow damaged. I reinstall opneldap, remove all tunung, make slapadd < backup.ldif and get about 50 failures at the night. :( > > - Oliver > > -- > | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | > | Ich bin das Internet. Sowahr ich Gott helfe. | > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Email: alexs@ulgsm.ru Email/Jabber: alexs@ulgsm.ru From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 08:25:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27A461065676 for ; Wed, 28 Oct 2009 08:25:59 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id ACFC98FC18 for ; Wed, 28 Oct 2009 08:25:58 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so276707fga.13 for ; Wed, 28 Oct 2009 01:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=qkkDcJGTtifKZitN+wfSt2mxlc5K+egKtPN0D9IBg94=; b=s8pUl3EJ/D2tsnnI+p6OKY2SdVD5kf/BAxlkBjo5s4usBTFJyiDAj7KfDJV6vQ36YC Pc0eqmSqWDWn9uow4+ZrpzLlIJvGLoA2iBHeXFYRZHuJGyKNQzIB6rK/XRK6ARtex/Sw s8An8NLRTSI0LNnf7kzUXWxBRVkfJrwYwJIWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gytAl4SUrwO4a+YyfYLPn/pbQOvAHLqOU1oPN1wC3dl5unFezSSd2g26zCWmy4o6SL gnn6oj4Q6W/ShHqfX253LiPdy3qEOC+C6pWTn6mUpaBD4HzzRg79SdEWmy1AAVtNCL6o rEhWraQfmaKvrq6x65mhmaqfPn+6XXSLPq1FU= Received: by 10.102.12.1 with SMTP id 1mr7166857mul.63.1256718357605; Wed, 28 Oct 2009 01:25:57 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id u9sm1863229muf.1.2009.10.28.01.25.56 (version=SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 01:25:56 -0700 (PDT) Sender: Alexander Motin Message-ID: <4AE80012.803@FreeBSD.org> Date: Wed, 28 Oct 2009 10:25:54 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Jakub Lach References: <1256667780.00177464.1256654401@10.7.7.3> In-Reply-To: <1256667780.00177464.1256654401@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: No sound after update to RC2 from RC1. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 08:25:59 -0000 Jakub Lach wrote: > I've lost sound. Dmesg content: > > hdac0: HDA Driver Revision: 20090624_0136 > hdac0: [ITHREAD] > > Starting default moused > . > mixer: > unknown device: mic > (or ogain) > > hdac0: HDA Codec #0: Conexant CX20561 (Hermosa) > pcm0: at cad 0 nid 1 on hdac0 > > It was previously working with such device.hints: > > hint.hdac.0.cad0.nid22.config="as=1" > hint.hdac.0.cad0.nid26.config="as=1 seq=1" > hint.hdac.0.cad0.nid24.config="as=2" > hint.hdac.0.cad0.nid29.config="as=2 seq=1" > > + sysctl.conf > > dev.pcm.0.play.vchans=0 > dev.pcm.0.bitperfect=1 There was no any changes in snd_hda for last two month in RELENG_8 branch. Show me full verbose boot messages and `cat /dev/sndstat`. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 10:13:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0D01106568F for ; Wed, 28 Oct 2009 10:13:05 +0000 (UTC) (envelope-from alexs@ulgsm.ru) Received: from mail.ulgsm.ru (skuns.ulgsm.ru [93.93.136.26]) by mx1.freebsd.org (Postfix) with ESMTP id 53E418FC0C for ; Wed, 28 Oct 2009 10:13:04 +0000 (UTC) Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id F3891B849; Wed, 28 Oct 2009 13:12:58 +0300 (MSK) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.gsm900.net X-Spam-Level: X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id CF052B848; Wed, 28 Oct 2009 13:12:58 +0300 (MSK) Received: from mail.ulgsm.ru (bazar.gsm900.net [192.168.0.160]) by mail.ulgsm.ru (Postfix) with ESMTP id 9BBFDB843; Wed, 28 Oct 2009 13:12:58 +0300 (MSK) Date: Wed, 28 Oct 2009 13:12:58 +0300 From: =?utf-8?B?0JrQu9GO0YfQvdC40LrQvtCyINCQLtChLg==?= To: Dewayne Geraghty Message-ID: <20091028101258.GA33200@mail.ulgsm.ru> References: <20091027082516.GA88892@mail.ulgsm.ru> <20091027085647.GT95002@e-Gitt.NET> <20091028055210.GA72197@mail.ulgsm.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-stable@freebsd.org Subject: Re: openldap unstable on freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 10:13:05 -0000 * Dewayne Geraghty [2009-10-28 19:02:58 +1100]: > Alexs, Would you please provide the output to the following two questions: > /usr/local/libexec/slapd -V ~]>/usr/local/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.19 (Oct 28 2009 09:02:40) $ root@bazar:/usr/wrkdir/usr/ports/net/openldap24-server/work/openldap-2.4.19/servers/slapd > ldd /usr/local/libexec/slapd ~]>ldd /usr/local/libexec/slapd /usr/local/libexec/slapd: libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) libdb-4.7.so.0 => /usr/local/lib/libdb-4.7.so.0 (0x800a97000) libssl.so.5 => /usr/lib/libssl.so.5 (0x800cf7000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e41000) libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010d3000) libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011e1000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012e3000) libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013fc000) libthr.so.3 => /lib/libthr.so.3 (0x801505000) libc.so.7 => /lib/libc.so.7 (0x80161d000) > It will be helpful to indicate what libraries that you are linking to; and what > version are you using. Currently openldap is 2.4.19. Please note that the > FreeBSD-stable list will be helpful to you if there are operating system > issues. I don't think that you've established an operating system problem with > the information provided. You have asked a good question which would trigger > responses if other people were experiencing the same problem. > > Similar to earlier replies, LDAP has been reliable on my 7.2Stable, and I'm > tracking 3 days behind cvs. My production machines with openldap, run on > average for 600 days without any crashes or reboots; which is what you should > expect. Maybe its my mistake in freebsd and openldap configuration. I cant find it long time. Today I tried on netbsd, (there are openldap 2.4.16 in pkgsrc), work perfect! So it work on linux and netbsd, soon i`ll try on solaris. > > From your description of your problem, you might need to contact the Openldap > mailing list; but you'll need more detail. > Kind regards, Dewayne. Yes. But thea are strong moderated. I think its my english why moderator rejected me. -- Email: alexs@ulgsm.ru Email/Jabber: alexs@ulgsm.ru From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 10:14:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0FA9106568F for ; Wed, 28 Oct 2009 10:14:06 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by mx1.freebsd.org (Postfix) with ESMTP id 3660D8FC14 for ; Wed, 28 Oct 2009 10:14:05 +0000 (UTC) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.30) with ESMTP id n9SAE4wG028459; Wed, 28 Oct 2009 11:14:04 +0100 (MET) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id 759332E06A; Wed, 28 Oct 2009 11:14:04 +0100 (CET) Date: Wed, 28 Oct 2009 11:14:04 +0100 From: Olaf Seibert To: Claus Guttesen Message-ID: <20091028101404.GV841@twoquid.cs.ru.nl> References: <20091027164159.GU841@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Cc: freebsd-stable@freebsd.org, Olaf Seibert , Olaf Seibert Subject: Re: 8.0-RC1 NFS client timeout issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 10:14:06 -0000 On Tue 27 Oct 2009 at 18:01:11 +0100, Claus Guttesen wrote: > I used nfs with tcp on a 7.2-client without problems on a solaris > nfs-server. When I upgraded to RC1 I had 'server not responding - > alive again' messages so I swithced to udp which works flawlessly. I > haven't had time to investigate it though. Sounds like the same as my problem. I have switched to UDP and so far, with light useage, I have seen no problem. (It would appear with light useage only, anyway). I have looked at some source, but not being an expert on the terrirory, I haven't seen anything obvious yet. > Claus -Olaf. -- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 11:29:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0454A106568D for ; Wed, 28 Oct 2009 11:29:56 +0000 (UTC) (envelope-from a.huth@tmr.net) Received: from bo-uwka-srv01.de.tmr.net (bo-uwka-srv01.de.tmr.net [212.23.146.2]) by mx1.freebsd.org (Postfix) with ESMTP id B31EF8FC18 for ; Wed, 28 Oct 2009 11:29:55 +0000 (UTC) Received: from localhost (localhost.de.tmr.net [127.0.0.1]) by bo-uwka-srv01.de.tmr.net (Postfix) with ESMTP id 56E291DECDD for ; Wed, 28 Oct 2009 12:02:13 +0100 (CET) Received: from bo-uwka-srv01.de.tmr.net ([127.0.0.1]) by localhost (bo-uwka-srv01.de.tmr.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 88526-01-9 for ; Wed, 28 Oct 2009 12:02:13 +0100 (CET) Received: from localhost (bo-stwhv-fw02.de.tmr.net [212.23.140.253]) by bo-uwka-srv01.de.tmr.net (Postfix) with ESMTP id F392A1DECD7 for ; Wed, 28 Oct 2009 12:02:12 +0100 (CET) Date: Wed, 28 Oct 2009 12:02:14 +0100 From: Alex Huth To: freebsd-stable@freebsd.org Message-ID: <20091028110214.GB13028@borusse.borussiapark> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Predence: first-class Priority: normal X-Editor: VIM - Vi IMproved 7.1 (2007 May 12, compiled Oct 17 2008 18:11:28) X-Operating-System: Linux 2.6.26-2-686 i686 GNU/Linux X-Mailer: Mutt 1.5.18 (2008-05-17) User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Next stable version X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 11:29:56 -0000 Hi! Is there any timeline when 8.0 becomes stable to use it in production? Thx Alex =09 Never be afraid to try something new. Remember, amateurs built the ark. Professionals built the Titanic. =E2=80=94 unknow From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 11:40:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70DC8106566B for ; Wed, 28 Oct 2009 11:40:35 +0000 (UTC) (envelope-from db@danielbond.org) Received: from mail.nsn.no (mailtwo.nsn.no [62.89.38.161]) by mx1.freebsd.org (Postfix) with SMTP id C1D268FC3B for ; Wed, 28 Oct 2009 11:40:34 +0000 (UTC) Received: (qmail 82992 invoked by uid 0); 28 Oct 2009 11:40:32 -0000 Received: from unknown (HELO ?172.16.3.90?) (85.95.44.187) by mail.nsn.no with SMTP; 28 Oct 2009 11:40:32 -0000 Message-Id: From: Daniel Bond To: Alex Huth In-Reply-To: <20091028110214.GB13028@borusse.borussiapark> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-49--750045878" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 12:40:28 +0100 References: <20091028110214.GB13028@borusse.borussiapark> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.936) Cc: freebsd-stable@freebsd.org Subject: Re: Next stable version X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 11:40:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-49--750045878 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi, according to the schedule, 8.0-RELEASE is a bit delayed. This is quite =20= usual, but epecially for 8.0 there have been a lot of last minute fixes. The main schedule is here: = http://www.freebsd.org/releng/index.html#schedule which links to more updated and detailed information in the wiki: = http://wiki.freebsd.org/8.0TODO If the schedule is still accurate, looks like release building will =20 start in about a week. Personally, I often wait untill the X.1 or X.2 release before =20 upgrading systems allready in production, unless I need a new feature, =20= but I advise testing the BETA's and RC's prior to release, so you can report =20= bugs/issues to be fixed prior to the RELEASE. Best regards, Daniel Bond. On Oct 28, 2009, at 12:02 PM, Alex Huth wrote: > Hi! > > Is there any timeline when 8.0 becomes stable to use it in production? > > Thx > > Alex > =09 > Never be afraid to try something new. > Remember, amateurs built the ark. > Professionals built the Titanic. =97 unknow > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org=20 > " --Apple-Mail-49--750045878 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) iEYEARECAAYFAkroLbAACgkQF4Ca8+3pySUp4QCghSfOfi8P2tlrl6WijokLJs8h qXIAoLvxutjy0JdjuCmiSGL7cx0aSjw7 =go2q -----END PGP SIGNATURE----- --Apple-Mail-49--750045878-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 12:24:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5308A1065695 for ; Wed, 28 Oct 2009 12:24:35 +0000 (UTC) (envelope-from a.huth@tmr.net) Received: from bo-uwka-srv01.de.tmr.net (bo-uwka-srv01.de.tmr.net [212.23.146.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0EFC28FC12 for ; Wed, 28 Oct 2009 12:24:34 +0000 (UTC) Received: from localhost (localhost.de.tmr.net [127.0.0.1]) by bo-uwka-srv01.de.tmr.net (Postfix) with ESMTP id DC5ED1DE967 for ; Wed, 28 Oct 2009 13:24:32 +0100 (CET) Received: from bo-uwka-srv01.de.tmr.net ([127.0.0.1]) by localhost (bo-uwka-srv01.de.tmr.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01101-01-74 for ; Wed, 28 Oct 2009 13:24:32 +0100 (CET) Received: from localhost (bo-stwhv-fw02.de.tmr.net [212.23.140.253]) by bo-uwka-srv01.de.tmr.net (Postfix) with ESMTP id B51661DE921 for ; Wed, 28 Oct 2009 13:24:32 +0100 (CET) Date: Wed, 28 Oct 2009 13:24:18 +0100 From: Alex Huth To: freebsd-stable@freebsd.org Message-ID: <20091028122418.GB15578@borusse.borussiapark> References: <20091028110214.GB13028@borusse.borussiapark> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Predence: first-class Priority: normal X-Editor: VIM - Vi IMproved 7.1 (2007 May 12, compiled Oct 17 2008 18:11:28) X-Operating-System: Linux 2.6.26-2-686 i686 GNU/Linux X-Mailer: Mutt 1.5.18 (2008-05-17) User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: Next stable version X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 12:24:35 -0000 * Daniel Bond schrieb: > Hi, > > Personally, I often wait untill the X.1 or X.2 release before upgrading= =20 > systems allready in production, unless I need a new feature, but I > advise testing the BETA's and RC's prior to release, so you can report = =20 > bugs/issues to be fixed prior to the RELEASE. > We actual have 6.4 on our production server. I don't want to upgrade, becau= se i need a different layout. I need the feature to use several IP in a jail. That's why i am waiting for 8.0. But i have the possibillity to build it on= a secondary testing system, which will be later the productive system. Never be afraid to try something new. Remember, amateurs built the ark. Professionals built the Titanic. =E2=80=94 unknow From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 12:31:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAC90106568D for ; Wed, 28 Oct 2009 12:31:17 +0000 (UTC) (envelope-from bsam@ns.kfs.ru) Received: from ns.kfs.ru (kfs.kfs.ru [194.186.81.194]) by mx1.freebsd.org (Postfix) with ESMTP id 6B8988FC0A for ; Wed, 28 Oct 2009 12:31:17 +0000 (UTC) Received: from bsam by ns.kfs.ru with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1N372X-000L7d-1x; Wed, 28 Oct 2009 14:50:09 +0300 To: Daniel Bond References: <20091028110214.GB13028@borusse.borussiapark> From: Boris Samorodov Date: Wed, 28 Oct 2009 14:50:09 +0300 In-Reply-To: (Daniel Bond's message of "Wed\, 28 Oct 2009 12\:40\:28 +0100") Message-ID: <77838974@serv3.int.kfs.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: "Boris B. Samorodov" Cc: freebsd-stable@freebsd.org, Alex Huth Subject: Re: Next stable version X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 12:31:17 -0000 Daniel Bond writes: > If the schedule is still accurate, looks like release building will > start in about a week. AFAIC RC2 will be out really soon. But due to many fixes it should be stabilized and RC3 will take place before release is done. -- WBR, bsam From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 12:40:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEB29106566C for ; Wed, 28 Oct 2009 12:40:56 +0000 (UTC) (envelope-from db@danielbond.org) Received: from mail.nsn.no (mailone.nsn.no [62.89.38.160]) by mx1.freebsd.org (Postfix) with SMTP id E992E8FC1D for ; Wed, 28 Oct 2009 12:40:55 +0000 (UTC) Received: (qmail 16096 invoked by uid 0); 28 Oct 2009 12:40:54 -0000 Received: from unknown (HELO ?172.16.3.90?) (85.95.44.187) by mail.nsn.no with SMTP; 28 Oct 2009 12:40:54 -0000 Message-Id: From: Daniel Bond To: Alex Huth In-Reply-To: <20091028122418.GB15578@borusse.borussiapark> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-50--746424346" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 13:40:49 +0100 References: <20091028110214.GB13028@borusse.borussiapark> <20091028122418.GB15578@borusse.borussiapark> X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.936) Cc: freebsd-stable@freebsd.org Subject: Re: Next stable version X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 12:40:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-50--746424346 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 28, 2009, at 1:24 PM, Alex Huth wrote: > We actual have 6.4 on our production server. I don't want to > upgrade, because > i need a different layout. I need the feature to use several IP in a > jail. > That's why i am waiting for 8.0. But i have the possibillity to > build it on a > secondary testing system, which will be later the productive system. You could optionally use 7.2-RELEASE also, which was the first release to support for multiple IP4/6 in jail. Best regards, Daniel Bond. --Apple-Mail-50--746424346 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) iEYEARECAAYFAkroO9UACgkQF4Ca8+3pySXjAACfZ1oI0oWJw65qECkyo9Y6M+qV TLcAoN3/Vc2GwP2D7KqaDSipXCdzovSj =DClx -----END PGP SIGNATURE----- --Apple-Mail-50--746424346-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 12:54:46 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12BBB106568F for ; Wed, 28 Oct 2009 12:54:46 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id B93498FC15 for ; Wed, 28 Oct 2009 12:54:45 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 4C6AE19E019; Wed, 28 Oct 2009 13:54:43 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 1C1FB19E027; Wed, 28 Oct 2009 13:54:41 +0100 (CET) Message-ID: <4AE83F10.3060707@quip.cz> Date: Wed, 28 Oct 2009 13:54:40 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Alex Huth References: <20091028110214.GB13028@borusse.borussiapark> <20091028122418.GB15578@borusse.borussiapark> In-Reply-To: <20091028122418.GB15578@borusse.borussiapark> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Next stable version X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 12:54:46 -0000 Alex Huth wrote: > * Daniel Bond schrieb: > >>Hi, >> >>Personally, I often wait untill the X.1 or X.2 release before upgrading >>systems allready in production, unless I need a new feature, but I >>advise testing the BETA's and RC's prior to release, so you can report >>bugs/issues to be fixed prior to the RELEASE. >> > > We actual have 6.4 on our production server. I don't want to upgrade, because > i need a different layout. I need the feature to use several IP in a jail. > That's why i am waiting for 8.0. But i have the possibillity to build it on a > secondary testing system, which will be later the productive system. If you only need jails with several IPs, IPv6 or noIPs, you can go for 7-STABLE. The multi-IP was committed right after the 7.2-RELEASE and I an running it for half a year without any problems + cpuset ability. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 12:57:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D213A1065670 for ; Wed, 28 Oct 2009 12:57:58 +0000 (UTC) (envelope-from db@danielbond.org) Received: from mail.nsn.no (mailone.nsn.no [62.89.38.160]) by mx1.freebsd.org (Postfix) with SMTP id 2EC248FC18 for ; Wed, 28 Oct 2009 12:57:57 +0000 (UTC) Received: (qmail 37378 invoked by uid 0); 28 Oct 2009 12:57:56 -0000 Received: from unknown (HELO ?172.16.3.90?) (85.95.44.187) by mail.nsn.no with SMTP; 28 Oct 2009 12:57:56 -0000 Message-Id: <1C39034B-E48E-4017-A688-9247B70ED758@danielbond.org> From: Daniel Bond To: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <4AE83F10.3060707@quip.cz> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-52--745406223" Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 13:57:47 +0100 References: <20091028110214.GB13028@borusse.borussiapark> <20091028122418.GB15578@borusse.borussiapark> <4AE83F10.3060707@quip.cz> X-Pgp-Agent: GPGMail 1.2.0 (v56) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.936) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Next stable version X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 12:57:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-52--745406223 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 28, 2009, at 1:54 PM, Miroslav Lachman wrote: > > If you only need jails with several IPs, IPv6 or noIPs, you can go > for 7-STABLE. The multi-IP was committed right after the 7.2-RELEASE > and I an running it for half a year without any problems + cpuset > ability. It should be included in 7.2-RELEASE, according to announcements and the manual page. - Daniel --Apple-Mail-52--745406223 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) iEYEARECAAYFAkroP9QACgkQF4Ca8+3pySXG+ACfejin8xY++qE0uUiCeni9RbmD td4AoIvdb3hONXf3jmsNLNpt4BlB4Zl0 =XEI2 -----END PGP SIGNATURE----- --Apple-Mail-52--745406223-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 13:20:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51D161065670 for ; Wed, 28 Oct 2009 13:20:39 +0000 (UTC) (envelope-from darcsis@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id C80B38FC14 for ; Wed, 28 Oct 2009 13:20:38 +0000 (UTC) Received: by bwz5 with SMTP id 5so994677bwz.3 for ; Wed, 28 Oct 2009 06:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-opensmtpd-loop:received :from:to:cc:subject:in-reply-to:organization:references:user-agent :x-envelope-to:mail-followup-to:date:message-id:mime-version :content-type; bh=LJ2qXr4vdACIpB1Cd4WyJeMKe4pxwqjZMpakZVNEZS0=; b=hmC/2CjQwN3yuZDaFh5n0OWWnmMbiHAAmnvNDWNE4yXiwUAQ4ESiwkjqx31fYC6hTz nLlbw7OOzhgarYQvOqiuXpfiU88n57VpRdSVF8uCm9gZaBVLMBlX7itETxFgBkWWkhiV 8YntM7R0vymAiRitVdUEIa+Xde2qI6CdQ/Umo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-opensmtpd-loop:from:to:cc:subject:in-reply-to:organization :references:user-agent:x-envelope-to:mail-followup-to:date :message-id:mime-version:content-type; b=iUGMxVhckAbXThKnFg2tO3DUxu6ek4vqM6O4A0MQeq0UYsj82t3IFeZV5xxQW+GVCY W4mP3JfikJe8GY8nddE3I91z3Z/BjALbmC+umhD4ndrbfKQQ6N8tNLaGHCvFZifkjf9I 8tX9SebvJ2Hy4scePnbyMaB9gqOgLdkGKUex8= Received: by 10.204.7.195 with SMTP id e3mr588933bke.118.1256734400778; Wed, 28 Oct 2009 05:53:20 -0700 (PDT) Received: from sol.xbsd.name ([123.117.44.226]) by mx.google.com with ESMTPS id 9sm1620742fks.34.2009.10.28.05.53.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Oct 2009 05:53:19 -0700 (PDT) X-OpenSMTPD-Loop: freebsd-stable@freebsd.org Received: from pluton.xbsd.name (pluton.xbsd.name [172.16.1.10]) by sol.xbsd.name (OpenSMTPD) with ESMTP id 1256734390.ccCosuEzUetjHfHE (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128); Wed, 28 Oct 2009 20:53:11 +0800 (CST) From: darcsis@gmail.com (Denise H. G.) To: Boris Samorodov In-Reply-To: <77838974@serv3.int.kfs.ru> (Boris Samorodov's message of "Wed, 28 Oct 2009 14:50:09 +0300") Organization: Terra Firma References: <20091028110214.GB13028@borusse.borussiapark> <77838974@serv3.int.kfs.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) X-Envelope-To: bsam@ipt.ru Mail-Followup-To: Boris Samorodov , Daniel Bond , freebsd-stable@freebsd.org, Alex Huth Date: Wed, 28 Oct 2009 20:53:09 +0800 Message-ID: <86639zissq.fsf@pluton.xbsd.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Daniel Bond , freebsd-stable@freebsd.org, Alex Huth Subject: Re: Next stable version X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:20:39 -0000 >>>>> "Boris" == Boris Samorodov writes: Boris> Daniel Bond writes: >> If the schedule is still accurate, looks like release building >> will start in about a week. Boris> AFAIC RC2 will be out really soon. But due to many fixes it Boris> should be stabilized and RC3 will take place before release Boris> is done. I've been followying -STABLE and now it is already RC2 as of today. You can give it a csup and take a look. Boris> -- WBR, bsam _______________________________________________ Boris> freebsd-stable@freebsd.org mailing list Boris> http://lists.freebsd.org/mailman/listinfo/freebsd-stable To Boris> unsubscribe, send any mail to Boris> "freebsd-stable-unsubscribe@freebsd.org" -- (dhg) darcsis AT gmail dot COM From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 14:45:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7D7A1065696; Wed, 28 Oct 2009 14:45:20 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailC.acsu.buffalo.edu (localmail.buffalo.edu [128.205.5.204]) by mx1.freebsd.org (Postfix) with ESMTP id 91DC68FC25; Wed, 28 Oct 2009 14:45:20 +0000 (UTC) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 88C9591739; Wed, 28 Oct 2009 10:45:18 -0400 (EDT) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailC.acsu.buffalo.edu (Postfix) with ESMTP id 133F591734; Wed, 28 Oct 2009 10:45:17 -0400 (EDT) Received: from mweb2.acsu.buffalo.edu (mweb2.acsu.buffalo.edu [128.205.5.239]) by localmailC.acsu.buffalo.edu (Prefixe) with ESMTP id 0DB7791732; Wed, 28 Oct 2009 10:45:17 -0400 (EDT) Received: from [128.205.32.76] (bauer.cse.Buffalo.EDU [128.205.32.76]) by mweb2.acsu.buffalo.edu (Postfix) with ESMTP id F14B6203CD; Wed, 28 Oct 2009 10:45:16 -0400 (EDT) From: Ken Smith To: freebsd-current , freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-RbAKYK74sc0NzEaHee2Y" Date: Wed, 28 Oct 2009 10:45:16 -0400 Message-Id: <1256741116.13258.61.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: Subject: 8.0-RC2 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 14:45:21 -0000 --=-RbAKYK74sc0NzEaHee2Y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable The second of the Release Candidates for the FreeBSD 8.0 release cycle is now available. At this point we feel most of what has been discovered during public testing that is feasible to fix as part of the release process has been addressed. So the current plan is to have 8.0-RC3 in about two weeks. Details about the current target schedule along with much more detail about the current status of the release is available here: http://wiki.freebsd.org/8.0TODO If you notice problems you can report them through the normal Gnats PR system or on the freebsd-current mailing list. I do cross-post announcements to freebsd-stable because this particular release is "about to become a stable branch" but when it comes to watching for issues related to the release most of the developers pay more attention to the freebsd-current list. ISO images for all supported architectures are available on the FTP sites, and a "memory stick" image is available for amd64/i386 architectures. For amd64/i386 architectures the cdrom and memstick images include the documentation packages but no other packages. The DVD image includes the packages that will probably be available on the official release media but is subject to change between now and release. For sparc64 there is now a livefs cdrom, disc1 includes the documentation packages, and the DVD image has the set of packages that currently build for sparc64 (which is a sub-set of the set provided for amd64/i386). If you are using csup/cvsup methods to update an older system the branch tag to use is RELENG_8_0. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, 8.0-BETA4, or 8.0-RC1 can upgrade as follows: =20 # freebsd-update upgrade -r 8.0-RC2 =20 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. Systems running 8.0-BETA3 may print the warning INDEX-OLD.all: Invalid arguments when downloading updates; this warning is a harmless bug (fixed in 8.0-BETA4) and can be safely ignored. # freebsd-update install =20 The system must be rebooted with the newly installed kernel before continui= ng. =20 # shutdown -r now =20 After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install =20 At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. See: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html for mode details. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install =20 Finally, reboot into 8.0-RC2: =20 # shutdown -r now MD5/SHA256 checksums for the image files: MD5 (8.0-RC2-amd64-bootonly.iso) =3D d8b4a402dd510446d7bec239cb2a5add MD5 (8.0-RC2-amd64-disc1.iso) =3D 74ae55d888589d759339d736db4e4e15 MD5 (8.0-RC2-amd64-dvd1.iso) =3D c1772eb971b9c451ebbdd9e82b09b7b7 MD5 (8.0-RC2-amd64-livefs.iso) =3D ef34d58bc1c6c47acb69d8a772de364a MD5 (8.0-RC2-amd64-memstick.img) =3D 295815f1b358706a8f39f09f3240dde2 MD5 (8.0-RC2-i386-bootonly.iso) =3D 2d9e62645603a2d284c787f3505060fa MD5 (8.0-RC2-i386-disc1.iso) =3D 8883ed3b408b67a265d82467d0659ced MD5 (8.0-RC2-i386-dvd1.iso) =3D 484792f88bae31fca2846bc2a78d8e95 MD5 (8.0-RC2-i386-livefs.iso) =3D 7053f9ea329d4751c3361112d33b3caa MD5 (8.0-RC2-i386-memstick.img) =3D b6a703e47e184e2eef63defd60f11abe MD5 (8.0-RC2-ia64-bootonly.iso) =3D 803d1d48e4a7c52f028cdd9335f63e95 MD5 (8.0-RC2-ia64-disc1.iso) =3D eb0a6aea681ae605f1a291e17e92342c MD5 (8.0-RC2-ia64-disc2.iso) =3D 67471992168e3c93095dae45ae0be773 MD5 (8.0-RC2-ia64-disc3.iso) =3D 6a076b1abda6ff843b8e8745d8068906 MD5 (8.0-RC2-ia64-dvd1.iso) =3D caf585b43277c22d6b5da1725764eccb MD5 (8.0-RC2-ia64-livefs.iso) =3D 7c2251519fd99236af1d6bbda2606c3f MD5 (8.0-RC2-pc98-bootonly.iso) =3D 37bbc89727b0927b8075573133d0fb9f MD5 (8.0-RC2-pc98-disc1.iso) =3D 0d1f6a48ebcbac485df40f8825d54863 MD5 (8.0-RC2-pc98-livefs.iso) =3D 018d7f8d716e2a7a53f3263a4debef4d MD5 (8.0-RC2-powerpc-bootonly.iso) =3D b481aa9d1b66060ae21f427e4aa2a529 MD5 (8.0-RC2-powerpc-disc1.iso) =3D 0cc7590fe4a0933d54d0deecf9112129 MD5 (8.0-RC2-powerpc-disc2.iso) =3D e7a89d93be2bc8a69b54558c9d424c5c MD5 (8.0-RC2-powerpc-disc3.iso) =3D c549a90991122421dcb631d78ab8f312 MD5 (8.0-RC2-sparc64-bootonly.iso) =3D 3033c3b3c92eec90ad21b772b4ccd970 MD5 (8.0-RC2-sparc64-disc1.iso) =3D e4b3470481eb94baa2df115b85a23002 MD5 (8.0-RC2-sparc64-dvd1.iso) =3D a6571c2735c52dc8e5f83384e827c1ff SHA256 (8.0-RC2-amd64-bootonly.iso) =3D 0c72b0248a689df99b3aa76b7ed148b7bd7= 4a9de2577950231120ac4403bdb4c SHA256 (8.0-RC2-amd64-disc1.iso) =3D a20b72acf3990f6b4a71941c576d5dc395260a= 98287bdfe4455cbf15555015e0 SHA256 (8.0-RC2-amd64-dvd1.iso) =3D f29f6a65d08190d946d38412cc199b7ad3d001c= cd05e66b396cdb1339f45b3fd SHA256 (8.0-RC2-amd64-livefs.iso) =3D 59f3feb88ea35e8ec075b59ff1eeac8df36df= 219a375058966eab2b4deb1350a SHA256 (8.0-RC2-amd64-memstick.img) =3D 60a91e82223169fabf445b227f75cdc3495= 045a764285a0e7023bdf20478931a SHA256 (8.0-RC2-i386-bootonly.iso) =3D b160f47b2b7baa69acca8c5e5d45dccb8fa3= 582ade676f69b44638c956f92f38 SHA256 (8.0-RC2-i386-disc1.iso) =3D c7edabc1fe1429f396978b4699b41fff9e4a175= 74dfa2658499a6f9f2bd91a1d SHA256 (8.0-RC2-i386-dvd1.iso) =3D 34ae54a05ad5c0ac4a2d208edec95c218b0bf4e0= a2458c97317f2cbebe4ce93b SHA256 (8.0-RC2-i386-livefs.iso) =3D e58b2b922ee1ee8fb56eeac36fe5e8eb35d7c9= d7824535d770a7066faaafa8a4 SHA256 (8.0-RC2-i386-memstick.img) =3D aed885993e742a6c5ec17b4339ffab174492= 19e588d2e80457a0b7137d333f52 SHA256 (8.0-RC2-ia64-bootonly.iso) =3D 16967168e7eb1ea95d2aac1334d5046b307d= 06318613de329fc68fa65670e703 SHA256 (8.0-RC2-ia64-disc1.iso) =3D 6134adc5f124e397a5783a4d9ff8c94a3b942a0= 6e2682e489ff484c8a87ea8d3 SHA256 (8.0-RC2-ia64-disc2.iso) =3D a4b471b71da9d4a047d6dbbdd2029ec2ec3ac6e= 7ebf96d993ded7917b0b8649b SHA256 (8.0-RC2-ia64-disc3.iso) =3D 4e44fb8dd42bab1775318ba6608656739533dfb= 60bccd5800877e1d693dd67a6 SHA256 (8.0-RC2-ia64-dvd1.iso) =3D db586139a60465d125ab89adcf28283528d0d62d= d5ee6ef5dba6e90b0761107b SHA256 (8.0-RC2-ia64-livefs.iso) =3D 0a2d497a400166e4ea4a4191a92bb5d37959be= dc53b2dea04b35c0cd0681ee66 SHA256 (8.0-RC2-pc98-bootonly.iso) =3D 62f4af328fbb3660b49b4ca75158731de457= 781b41f6f1fd15f8cb58c8e2769d SHA256 (8.0-RC2-pc98-disc1.iso) =3D 5551baa1205ad356c87ccc7685241d463dd8a26= bde366fd8bdb4bde44188bf72 SHA256 (8.0-RC2-pc98-livefs.iso) =3D 2f195b71d73eaf4a76ac00522431e674f5a9b8= 272bb002c90c2c6d2a5491c4f5 SHA256 (8.0-RC2-powerpc-bootonly.iso) =3D d268f4cebd71bfbe7a6532270097b4934= f49da518a51754429448ef30bf57db0 SHA256 (8.0-RC2-powerpc-disc1.iso) =3D b847889e72d5134b7ac6bf06244e7c919639= d7d80a0001f6cfea5fc0c4c2847d SHA256 (8.0-RC2-powerpc-disc2.iso) =3D 2fe8a8f97821d2695b0f795eda62422433ea= e23dc1e6f5b7c38983e6c2431b25 SHA256 (8.0-RC2-powerpc-disc3.iso) =3D 24ccace776b897705ad10115287c9819bc33= 01aedaa4afd253addbc038178f0a SHA256 (8.0-RC2-sparc64-bootonly.iso) =3D ce24a908fce56afa6a7a29687d9fcc63f= fe724d59014851344349702a1df5fd2 SHA256 (8.0-RC2-sparc64-disc1.iso) =3D d4b3974421b52ed89699422d916039675824= 9ddd8f82fa12a0339cbf023cf32e SHA256 (8.0-RC2-sparc64-dvd1.iso) =3D 999f52fe73d32be3008eb5b289882d50eee35= f469e4bb122268dfacd2f1508f0 SHA256 (8.0-RC2-sparc64-livefs.iso) =3D 7e22429d82bce3c3b7e927a380c6ce136ce= 30811653fec94f369eef496810725 --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-RbAKYK74sc0NzEaHee2Y Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkroWPQACgkQ/G14VSmup/bVfwCggwqBABp1O+Z62zTuXrIYLpre FlcAniRiMs9WzbfAV8/ENZuSyDOlxgmy =Dndp -----END PGP SIGNATURE----- --=-RbAKYK74sc0NzEaHee2Y-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 19:05:57 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DF101065692 for ; Wed, 28 Oct 2009 19:05:57 +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 40EA18FC16 for ; Wed, 28 Oct 2009 19:05:56 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1N3DqF-0003h2-Ou for freebsd-stable@freebsd.org; Wed, 28 Oct 2009 12:05:55 -0700 Message-ID: <26100325.post@talk.nabble.com> Date: Wed, 28 Oct 2009 12:05:55 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org In-Reply-To: <4AE80012.803@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <26078773.post@talk.nabble.com> <4AE80012.803@FreeBSD.org> Subject: Re: No sound after update to RC2 from RC1. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 19:05:57 -0000 Alexander Motin-3 wrote: > > Jakub Lach wrote: >> I've lost sound. Dmesg content: >> >> hdac0: HDA Driver Revision: 20090624_0136 >> hdac0: [ITHREAD] >> >> Starting default moused >> . >> mixer: >> unknown device: mic >> (or ogain) >> >> hdac0: HDA Codec #0: Conexant CX20561 (Hermosa) >> pcm0: at cad 0 nid 1 on >> hdac0 >> >> It was previously working with such device.hints: >> >> hint.hdac.0.cad0.nid22.config="as=1" >> hint.hdac.0.cad0.nid26.config="as=1 seq=1" >> hint.hdac.0.cad0.nid24.config="as=2" >> hint.hdac.0.cad0.nid29.config="as=2 seq=1" >> >> + sysctl.conf >> >> dev.pcm.0.play.vchans=0 >> dev.pcm.0.bitperfect=1 > > There was no any changes in snd_hda for last two month in RELENG_8 > branch. Show me full verbose boot messages and `cat /dev/sndstat`. > > -- > Alexander Motin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > Yes, I tried tracing related changes to no avail, furthermore I didn't change anything related in my configuration. Dmesg gives some insight: hdac0: Tracing association 1 (2) hdac0: Unable to trace pin 24 to ADC 20, undo traces hdac0: Pin 24 traced to ADC 21 hdac0: Unable to trace pin 29 to ADC 21, undo traces hdac0: Association 1 (2) trace failed Full dmesg + sndstat http://senduit.com/8fdabe -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/No-sound-after-update-to-RC2-from-RC1.-tp26078773p26100325.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 28 20:31:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B21B51065670; Wed, 28 Oct 2009 20:31:25 +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 390798FC1A; Wed, 28 Oct 2009 20:31:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKdG6EqDaFvG/2dsb2JhbADbE4Q/BIFh X-IronPort-AV: E=Sophos;i="4.44,641,1249272000"; d="scan'208";a="51586191" Received: from amazon.cs.uoguelph.ca ([131.104.91.198]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 28 Oct 2009 16:31:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 287472100BD; Wed, 28 Oct 2009 16:31:24 -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 0+LaL0L1LktN; Wed, 28 Oct 2009 16:31:20 -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 5029F210192; Wed, 28 Oct 2009 16:31:20 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n9SKcRo21396; Wed, 28 Oct 2009 16:38:28 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 28 Oct 2009 16:38:27 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Olaf Seibert In-Reply-To: <20091027164159.GU841@twoquid.cs.ru.nl> Message-ID: References: <20091027164159.GU841@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dfr@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.0-RC1 NFS client timeout issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:31:25 -0000 First off, I know that cross posting is evil, but I wanted to try and make sure developers saw it. On Tue, 27 Oct 2009, Olaf Seibert wrote: > I see an annoying behaviour with NFS over TCP. It happens both with nfs > and newnfs. This is with FreeBSD/amd64 8.0-RC1 as client. The server is > some Linux or perhaps Solaris, I'm not entirely sure. > > After trying to find something in packet traces, I think I have found > something. > > The scenario seems to be as follows. Sorry for the width of the lines. > > > No. Time Source Destination Protocol Info > 2296 2992.216855 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2297), DH:0x3819da36/w > 2297 2992.217107 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2296) Error:NFS3ERR_NOENT > 2298 2992.217141 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2299), DH:0x170cb16a/bin > 2299 2992.217334 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2298), FH:0x61b8eb12 > 2300 2992.217361 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call (Reply In 2301), FH:0x61b8eb12 > 2301 2992.217582 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 ACCESS Reply (Call In 2300) > 2302 2992.217605 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2303), DH:0x61b8eb12/w > 2303 2992.217860 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2302) Error:NFS3ERR_NOENT > 2304 2992.318770 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238293 Ack=230289 Win=8192 Len=0 TSV=86492342 TSER=12393434 > 2306 3011.537520 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 GETATTR Reply (Call In 2305) Directory mode:2755 uid:4100 gid:4100 > 2307 3011.637744 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230405 Win=8192 Len=0 TSV=86511662 TSER=12395366 > 2308 3371.534980 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [FIN, ACK] Seq=230405 Ack=238429 Win=49232 Len=0 TSV=12431366 TSER=86511662 > > The server decides, for whatever reason, to terminate the > connection and sends a FIN. > > 2309 3371.535018 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230406 Win=8192 Len=0 TSV=86871578 TSER=12431366 > > Client acknowledges this, > > 2310 3375.379693 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call, FH:0x008002a2 > > but tries to sneak in another call anyway. [A] > Probably not the best behaviour, but I think it is technically allowed by TCP. (My TCP is very rusty, but I think the socket should be in TCPS_CLOSE_WAIT at this point and the BSD code will have called socantrcvmore(), but not socantsndmore().) > 2311 3375.474788 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [ACK] Seq=230406 Ack=238569 Win=49232 Len=0 TSV=12431760 TSER=86875423 > > Server ACKs but doesn't send anything else... [B] > > Time passes... > This is where it seems interesting. It looks to me like the socket upcall for receiving the FIN would have happened before this point, setting the ct_error.re_status to RPC_CANTRECV, but the code in clnt_vc_call() doesn't check for this. (It does check for it happening during and after the sosend(), but not before it, from what I can see.) > > [B] would be a bug of the server in my opinion. If it ACKs a call, it > should send a reply. And if it can't, it shouldn't. > I'll leave this one for the TCP wizzards. I'm not sure what the correct behaviour is when data is received on a connection. (I think it is waiting for a FIN from the client side at this point.) If you could try the following patch and see if it helps, that would be appreciated, rick ps: I'll try to reproduce the situation here, but I'm not sure if I can. --- rpc/clnt_vc.c.sav 2009-10-28 15:44:20.000000000 -0400 +++ rpc/clnt_vc.c 2009-10-28 15:49:57.000000000 -0400 @@ -413,6 +413,19 @@ cr->cr_xid = xid; mtx_lock(&ct->ct_lock); + /* + * Check to see if the other end has already started to close down + * the connection. If it happens after this point, it will be + * detected below, when cr->cr_error is checked. + */ + if (ct->ct_error.re_status == RPC_CANTRECV) { + if (errp != &ct->ct_error) { + errp->re_errno = ct->ct_error.re_errno; + errp->re_status = RPC_CANTRECV; + } + stat = RPC_CANTRECV; + goto out; + } TAILQ_INSERT_TAIL(&ct->ct_pending, cr, cr_link); mtx_unlock(&ct->ct_lock); From owner-freebsd-stable@FreeBSD.ORG Thu Oct 29 07:03:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9DC8106566B; Thu, 29 Oct 2009 07:03:32 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4FE4E8FC08; Thu, 29 Oct 2009 07:03:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Date:From:To:Cc:Subject:Message-ID: Reply-To:References:MIME-Version:Content-Type:In-Reply-To: Sender; bh=rzdjl4zznLIKQA4G0GhnUq/jbsmY+2CcODK7u7uLVe8=; b=S22U5 oAu8m3eaqo7Ns5V9/a/VmwPstJJnFyVGlv7HfYJUdq05kGpCAvXp9NxAd7BG2A8P Ho6TnKX+PUgqauukJMAr9iFVArN2ZpqUArQ0XCzTqaH8RGJeg2biBimXJ8uBkMTM l4MhzQTCskLN9Har4E89kbxhr2vegCXN06vE3FUEuPjnjDSFxhTHq1DBAsroEVqQ 3OQnSDwoDByGQKoO2R6ziVYsPWqHPGaNq7YZfR905Rbfml6saQhiq6fdhXNsrpJW tkQGHLSN3IidqJcw1EqTyRFy9CToT61h35Wbt1paOoNwKnYHiS+8V1+UW4BOrsVj aiOwmxhXsJMe9M/Cw== Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1N3OqL-0003PZ-Rt; Thu, 29 Oct 2009 09:50:46 +0300 Date: Thu, 29 Oct 2009 09:50:43 +0300 From: Eygene Ryabinkin To: "Dorr H. Clark" Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ptrace problem 6.x/7.x - can someone explain this? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 07:03:32 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dorr, good day. Tue, Oct 27, 2009 at 05:32:34PM -0700, Dorr H. Clark wrote: > We believe ptrace has a problem in 6.3; we have not tried other > releases. The same code, however, exists in 7.1. And in HEAD too. > The bug was first encountered in gdb... > > (gdb) det > Detaching from program: /usr/local/bin/emacs, process 66217 > (gdb) att 66224 > Attaching to program: /usr/local/bin/emacs, process 66224 > Error accessing memory address 0x281ba5a4: Device busy. > (gdb) det > Detaching from program: /usr/local/bin/emacs, process 66224 > ptrace: Device busy. > (gdb) quit <--- target process 66224 dies here > > To isolate this problem, a wrote a simple minded test program was > written that just attached and detached. This test program found > even the very first detach fails with EBUSY (see test source below): > > $ ./test1 -p 66217 -c 1 -d 10 > pid 66217 count 1 delay 10 > Start of pass 0 > Calling PT_ATTACH pid 66217 addr 0x0 sig 0 > Calling PT_DETACH pid 66217 addr 0xffffffff sig 0 > Call 0 to PT_DETACH returned -1, errno 16 > > Once again, the target process died when the ptracing test program > exitted, as would be expected if a detach had failed. > > The failure return was coming from the following test in kern_ptrace() > in sys_process.c > > /* not currently stopped */ > if ((p->p_flag & (P_STOPPED_SIG | P_STOPPED_TRACE)) == 0 || > p->p_suspcount != p->p_numthreads || > (p->p_flag & P_WAITED) == 0) { > error = EBUSY; > goto fail; > } Yes, the ptraced process should have been waited for, even after the PT_ATTACH call. This is somewhat documented in ptrace(2), ----- ----- but I agree that the wording is a bit sloppy. I'll try to produce slightly modified explanation in the manual page and will post the patch here and as the PR. I had modified your example to visually display the results of each wait() call that is made after ptrace() invocation. Here we go: ----- $ ./test -p 45901 pid 45901 count 2 delay 5 Start of pass 0 Calling PT_ATTACH pid 45901 addr 0x0 sig 0 Attached wait() yield 0x117f: stopped by signal 17; <-- after PT_ATTACH wait() yield 0x57f: stopped by signal 5; <-- after PT_STEP Calling PT_DETACH pid 45901 addr 0xffffffffffffffff sig 0 Detached. ----- As you see, the process is stopped just after the PT_ATTACH with the signal 17, SIGSTOP. PT_STEP follows with the delivery of the SIGTRAP. Both of these signals should be processed by the parent's wait(). And PT_DETACH works, apart from one thing: on my 8.0 PT_DETACH leads to the segfault of the traced program. I hadn't yet tried it on the other versions, so may be there is some bug in the code of test.c, or some bug in the ptrace() implementation -- can't say for sure. If anyone knows why the program segfaults -- please, speak up. The modified source of the test.s is attached. > This is applied to all operations except PT_TRACE_ME, PT_ATTACH, and > some instances of PT_CLEAR_STEP. > > P_WAITED is generally not true. In particular, it's not set > automatically when a process is PT_ATTACHed. It is cleared by > PT_DETACH and again when ptrace sends a signal (PT_CONTINUE, > PT_DETACH.) _But_ it's set in only two places, and they aren't in > ptrace code. > > 2 sys/kern/kern_exit.c kern_wait 773 p->p_flag |= P_WAITED; > 3 compat/svr4/svr4_misc.c svr4_sys_waitsys 1351 q->p_flag |= P_WAITED; > > The relevant one is the first one, primarily. Here's the code: > > mtx_lock_spin(&sched_lock); > if ((p->p_flag & P_STOPPED_SIG) && > (p->p_suspcount == p->p_numthreads) && > (p->p_flag & P_WAITED) == 0 && > (p->p_flag & P_TRACED || options & WUNTRACED)) { > mtx_unlock_spin(&sched_lock); > p->p_flag |= P_WAITED; > sx_xunlock(&proctree_lock); > td->td_retval[0] = p->p_pid; > if (status) > *status = W_STOPCODE(p->p_xstat); > PROC_UNLOCK(p); > return (0); > } > mtx_unlock_spin(&sched_lock); > > So it's only set on processes which are already traced. But it's not > set until someone calls wait4() on them - or the equivalent sysV > compatability routine. > > Gdb doesn't always wait4() for processes immediately opon tracing > them, and the ptrace man page does not imply this is needed. Hmm, there is at least one thread on the simular matter, http://sourceware.org/ml/gdb/2008-12/msg00041.html and people are saying that wait() still should be present. > Moreover, it's not clear why it should matter. The process > needs to be stopped in order for it to make sense to do most > of the things ptrace does. But - why should it need to be waited for? To see if it was really stopped, I presume. > And what kind of sense does this make to someone writing a debugging > tool, where the natural logic seems to be: > - attach to process - wait for the process' attachment by doing wait(). > - look at some stuff > - stick in some kind of breakpoint or similar and start it going again > (or 'step' it) > - wait for it to stop > - look at and modify stuff > - detach, or set it moving again > > By way of experiment, the test for P_WAITED was removed. Gdb no longer had > problems, and no new issues with gdb were encountered (although this > was just interactive, no "gdb coverage test" was attempted). By the way, I can't reproduce gdb faults with the 8.0 sources. Will try 7.x, but I think that I have no 6.x handy. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # --Dxnq1zWXvFF0Q93v-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 29 12:31:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C78271065670 for ; Thu, 29 Oct 2009 12:31:12 +0000 (UTC) (envelope-from alexs@ulgsm.ru) Received: from mail.ulgsm.ru (skuns.ulgsm.ru [93.93.136.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6CE7B8FC21 for ; Thu, 29 Oct 2009 12:31:11 +0000 (UTC) Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id D5907B85F; Thu, 29 Oct 2009 15:31:05 +0300 (MSK) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.gsm900.net X-Spam-Level: X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id B4532B849; Thu, 29 Oct 2009 15:31:05 +0300 (MSK) Received: from mail.ulgsm.ru (bazar.gsm900.net [192.168.0.160]) by mail.ulgsm.ru (Postfix) with ESMTP id 817BCB848; Thu, 29 Oct 2009 15:31:05 +0300 (MSK) Date: Thu, 29 Oct 2009 15:31:05 +0300 From: alexs@ulgsm.ru To: Dewayne Geraghty Message-ID: <20091029123105.GA74611@mail.ulgsm.ru> References: <20091027082516.GA88892@mail.ulgsm.ru> <20091027085647.GT95002@e-Gitt.NET> <20091028055210.GA72197@mail.ulgsm.ru> <20091028101258.GA33200@mail.ulgsm.ru> <9345792F61634092B5DA5990B7529999@HS> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9345792F61634092B5DA5990B7529999@HS> User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-stable@freebsd.org Subject: Re: openldap unstable on freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 12:31:12 -0000 * Dewayne Geraghty [2009-10-29 10:39:22 +1100]: > Alexs, > Thank-you. You seem to be using a default setup from ports. > > If you are using the same configuration files for slapd.conf and > /var/openldap-data/DB_CONFIG files on the three operating systems, and FreeBSD > isn't working, I'm struggling to think of any load induced problems that it > might be from the information provided. > > Rather than asking you a lot of questions, I think you need to rule out that > disks can handle the load, that bdb is able to service the queries, and that > the tools creating the ldap queries are using the same assumptions that the > ldap server is using, etc. I think it unlikely, but I couldn't rule out a bad > ldap query as a source of the problem. I tryed put database on RAM drive (created by mdconfig -t malloc), fails anyway. All configs in defaults, inly indexes and some acls added. > Review the "man slapd.conf" and determine the loglevel that you think > appropriate, I'd suggest 2047 as a good start. > /usr/local/libexec/slapd -d 2047 -4 -h ldapi://%2fvar%2frun%2fopenldap%2fldapi/ > ldap://alexs-ldap-server/ For geting crashes (for this mail only, real crashes needs to wait) I am use small script via nss_ldap. ~]>cat test.sh #!/bin/sh while true do id test > /dev/null done With 3 running scripts get fault in 30 seconds http://pastebin.org/49205 http://pastebin.org/49211 http://pastebin.org/49213 So crashes in different places. I think need some another debuging. I tried truss slapd process, but there different places too. > > Good luck, Dewayne. -- Email: alexs@ulgsm.ru Email/Jabber: alexs@ulgsm.ru From owner-freebsd-stable@FreeBSD.ORG Thu Oct 29 13:28:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B95A5106568B for ; Thu, 29 Oct 2009 13:28:05 +0000 (UTC) (envelope-from alexs@ulgsm.ru) Received: from mail.ulgsm.ru (skuns.ulgsm.ru [93.93.136.26]) by mx1.freebsd.org (Postfix) with ESMTP id 5DF6C8FC15 for ; Thu, 29 Oct 2009 13:28:05 +0000 (UTC) Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id 6D6C7B849 for ; Thu, 29 Oct 2009 16:28:00 +0300 (MSK) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.gsm900.net X-Spam-Level: X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id 4A04CB848 for ; Thu, 29 Oct 2009 16:28:00 +0300 (MSK) Received: from mail.ulgsm.ru (bazar.gsm900.net [192.168.0.160]) by mail.ulgsm.ru (Postfix) with ESMTP id 12301B843 for ; Thu, 29 Oct 2009 16:28:00 +0300 (MSK) Date: Thu, 29 Oct 2009 16:28:00 +0300 From: alexs@ulgsm.ru To: freebsd-stable@freebsd.org Message-ID: <20091029132800.GA71226@mail.ulgsm.ru> References: <20091027082516.GA88892@mail.ulgsm.ru> <20091027085647.GT95002@e-Gitt.NET> <20091028055210.GA72197@mail.ulgsm.ru> <20091028101258.GA33200@mail.ulgsm.ru> <9345792F61634092B5DA5990B7529999@HS> <20091029123105.GA74611@mail.ulgsm.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091029123105.GA74611@mail.ulgsm.ru> User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: openldap unstable on freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 13:28:05 -0000 * alexs@ulgsm.ru [2009-10-29 15:31:05 +0300]: > * Dewayne Geraghty [2009-10-29 10:39:22 +1100]: > > > Alexs, > > Thank-you. You seem to be using a default setup from ports. > > > > If you are using the same configuration files for slapd.conf and > > /var/openldap-data/DB_CONFIG files on the three operating systems, and FreeBSD > > isn't working, I'm struggling to think of any load induced problems that it > > might be from the information provided. Tested now on freebsd 8.0rc2 i386, slapd crashed after 10sec on stress load. -- Email: alexs@ulgsm.ru Email/Jabber: alexs@ulgsm.ru From owner-freebsd-stable@FreeBSD.ORG Thu Oct 29 13:52:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD4A910657C8 for ; Thu, 29 Oct 2009 13:52:42 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by mx1.freebsd.org (Postfix) with ESMTP id 4AAC58FC1F for ; Thu, 29 Oct 2009 13:52:41 +0000 (UTC) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.30) with ESMTP id n9TDqddE018549; Thu, 29 Oct 2009 14:52:39 +0100 (MET) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id 74A192E059; Thu, 29 Oct 2009 14:52:39 +0100 (CET) Date: Thu, 29 Oct 2009 14:52:39 +0100 From: Olaf Seibert To: Rick Macklem Message-ID: <20091029135239.GX841@twoquid.cs.ru.nl> References: <20091027164159.GU841@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Cc: freebsd-stable@freebsd.org, dfr@freebsd.org, freebsd-current@freebsd.org, Olaf Seibert Subject: Re: 8.0-RC1 NFS client timeout issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 13:52:42 -0000 On Wed 28 Oct 2009 at 16:38:27 -0400, Rick Macklem wrote: > I'll leave this one for the TCP wizzards. I'm not sure what the > correct behaviour is when data is received on a connection. (I think > it is waiting for a FIN from the client side at this point.) After writing, I realised that it is indeed perfectly allowed for the client to send data. But since the server already sent its FIN, it can't send anything more, not even an error message. So with that in mind, the client shouldn't send anything any more either. > If you could try the following patch and see if it helps, that would be > appreciated, rick Thanks, it looks like it should do the trick. I can't try it before monday, though. -Olaf. -- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 29 16:45:49 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 735D01065694; Thu, 29 Oct 2009 16:45:49 +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 1E55C8FC18; Thu, 29 Oct 2009 16:45:48 +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 n9TGjkjv023015; Thu, 29 Oct 2009 12:45:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n9TGjkjm085999; Thu, 29 Oct 2009 12:45:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 1ACDC1B5060; Thu, 29 Oct 2009 12:45:46 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20091029164546.1ACDC1B5060@freebsd-stable.sentex.ca> Date: Thu, 29 Oct 2009 12:45:46 -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: [releng_7 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 16:45:49 -0000 TB --- 2009-10-29 15:47:29 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-10-29 15:47:29 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2009-10-29 15:47:29 - cleaning the object tree TB --- 2009-10-29 15:48:02 - cvsupping the source tree TB --- 2009-10-29 15:48:02 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2009-10-29 15:48:12 - building world TB --- 2009-10-29 15:48:12 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-29 15:48:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-29 15:48:12 - TARGET=powerpc TB --- 2009-10-29 15:48:12 - TARGET_ARCH=powerpc TB --- 2009-10-29 15:48:12 - TZ=UTC TB --- 2009-10-29 15:48:12 - __MAKE_CONF=/dev/null TB --- 2009-10-29 15:48:12 - cd /src TB --- 2009-10-29 15:48:12 - /usr/bin/make -B buildworld >>> World build started on Thu Oct 29 15:48:14 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 [...] gzip -cn /src/share/man/man9/BUF_LOCKINIT.9 > BUF_LOCKINIT.9.gz gzip -cn /src/share/man/man9/BUF_REFCNT.9 > BUF_REFCNT.9.gz gzip -cn /src/share/man/man9/BUF_TIMELOCK.9 > BUF_TIMELOCK.9.gz gzip -cn /src/share/man/man9/BUF_UNLOCK.9 > BUF_UNLOCK.9.gz gzip -cn /src/share/man/man9/bus_activate_resource.9 > bus_activate_resource.9.gz gzip -cn /src/share/man/man9/BUS_ADD_CHILD.9 > BUS_ADD_CHILD.9.gz gzip -cn /src/share/man/man9/bus_alloc_resource.9 > bus_alloc_resource.9.gz make: don't know how to make BUS_BIND_INTR.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-29 16:45:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-29 16:45:45 - ERROR: failed to build world TB --- 2009-10-29 16:45:45 - 2966.82 user 298.38 system 3496.86 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Thu Oct 29 21:29:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42200106568D for ; Thu, 29 Oct 2009 21:29:05 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id C24C38FC14 for ; Thu, 29 Oct 2009 21:29:04 +0000 (UTC) Received: by bwz5 with SMTP id 5so2850923bwz.3 for ; Thu, 29 Oct 2009 14:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=4aJ3LM/vmWVCe3i9kS7by7/y4o92vGhkS94DYG4LfeE=; b=mMcz/7Z/uUlhce/rr5vXUm9SwsRWU2PyYEfPZZx6S3AP72HVwb4Y+yTuFHPHY3KOn+ H2q1t7MPVVB+hoKMWUuAKTSuaYnTXb1SjgBpfBe5xQmUwYzvddBvuroGRi6PpHoP2Bx0 tebx8p8SAmKVoZi3hwuWTa/b+4TmDP87wmKVg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=JX3/+t9VuToHym+M02VXPztMHYMiRmZKnCJRZYMY5TJ9hBK3ul7BCHW/ZZG1gcZflb hijWxjwhRxSLi5tvN4OqMB6NPojXNkpt40NkZRyyj9J528/bbXQxKw9QJ7pn396Z5Rgi iXKQTGICY/pD6l5bAOp7qd5LPxUdUIiDR88lM= Received: by 10.103.84.30 with SMTP id m30mr258450mul.23.1256851743501; Thu, 29 Oct 2009 14:29:03 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id e10sm1693326muf.21.2009.10.29.14.29.01 (version=SSLv3 cipher=RC4-MD5); Thu, 29 Oct 2009 14:29:02 -0700 (PDT) Sender: Alexander Motin Message-ID: <4AEA091B.30304@FreeBSD.org> Date: Thu, 29 Oct 2009 23:28:59 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Jakub Lach References: <1256667780.00177464.1256654401@10.7.7.3> <1256728986.00177694.1256718601@10.7.7.3> <1256768585.00177895.1256757002@10.7.7.3> In-Reply-To: <1256768585.00177895.1256757002@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: No sound after update to RC2 from RC1. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 21:29:05 -0000 Jakub Lach wrote: > Yes, I tried tracing related changes to no avail, furthermore I didn't > change > anything related in my configuration. > > Dmesg gives some insight: > > hdac0: Tracing association 1 (2) > hdac0: Unable to trace pin 24 to ADC 20, undo traces > hdac0: Pin 24 traced to ADC 21 > hdac0: Unable to trace pin 29 to ADC 21, undo traces > hdac0: Association 1 (2) trace failed > > Full dmesg + sndstat > > http://senduit.com/8fdabe It tells that file has expired. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Thu Oct 29 22:02:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F12E1065739 for ; Thu, 29 Oct 2009 22:02:19 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntmtas05p.mx.bigpond.com (nskntmtas05p.mx.bigpond.com [61.9.168.149]) by mx1.freebsd.org (Postfix) with ESMTP id EDEB18FC14 for ; Thu, 29 Oct 2009 22:02:18 +0000 (UTC) Received: from nskntotgx03p.mx.bigpond.com ([124.188.161.100]) by nskntmtas05p.mx.bigpond.com with ESMTP id <20091029220217.TFLS28618.nskntmtas05p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com>; Thu, 29 Oct 2009 22:02:17 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20091029220216.YCJS24930.nskntotgx03p.mx.bigpond.com@duncan.reilly.home>; Thu, 29 Oct 2009 22:02:16 +0000 Date: Fri, 30 Oct 2009 09:02:14 +1100 From: Andrew Reilly To: freebsd-stable@freebsd.org Message-ID: <20091029220214.GA48360@duncan.reilly.home> References: <200910291550.n9TFo5wc035999@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910291550.n9TFo5wc035999@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nskntotgx03p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Thu, 29 Oct 2009 22:02:16 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.4AEA10E9.0036,ss=1,fgs=0 X-SIH-MSG-ID: qBgyGNP9TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rHK+ZRvt2ixDxFJhiHNGEiaa3jTY3RstCK Cc: freebsd-amd64@FreeBSD.org Subject: Re: amd64/139859: commit references a PR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 22:02:19 -0000 On Thu, Oct 29, 2009 at 03:50:05PM +0000, dfilter service wrote: > Modified: releng/8.0/UPDATING > ============================================================================== > --- releng/8.0/UPDATING Thu Oct 29 15:39:30 2009 (r198605) > +++ releng/8.0/UPDATING Thu Oct 29 15:42:50 2009 (r198606) > @@ -566,6 +566,15 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 8. > userland (libpmc(3)) and the kernel module (hwpmc(4)) in > sync. > > +20081009: > + atapci kernel module now includes only generic PCI ATA > + driver. AHCI driver moved to ataahci kernel module. That probably wants to say 20091029? Cheers, -- Andrew From owner-freebsd-stable@FreeBSD.ORG Thu Oct 29 23:05:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C16D1065695 for ; Thu, 29 Oct 2009 23:05:34 +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 2A3DC8FC12 for ; Thu, 29 Oct 2009 23:05:34 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1N3e3h-0008FS-M7 for freebsd-stable@freebsd.org; Thu, 29 Oct 2009 16:05:33 -0700 Message-ID: <26122214.post@talk.nabble.com> Date: Thu, 29 Oct 2009 16:05:33 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org In-Reply-To: <4AEA091B.30304@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <26078773.post@talk.nabble.com> <4AEA091B.30304@FreeBSD.org> Subject: Re: No sound after update to RC2 from RC1. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 23:05:34 -0000 mav-3 wrote: > > Jakub Lach wrote: >> Yes, I tried tracing related changes to no avail, furthermore I didn't >> change >> anything related in my configuration. >> >> Dmesg gives some insight: >> >> hdac0: Tracing association 1 (2) >> hdac0: Unable to trace pin 24 to ADC 20, undo traces >> hdac0: Pin 24 traced to ADC 21 >> hdac0: Unable to trace pin 29 to ADC 21, undo traces >> hdac0: Association 1 (2) trace failed >> >> Full dmesg + sndstat >> >> http://senduit.com/8fdabe > > It tells that file has expired. > > -- > Alexander Motin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > You mean that my device.hints file is no longer valid? What triggered it? -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/No-sound-after-update-to-RC2-from-RC1.-tp26078773p26122214.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 29 23:47:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 742F5106568F for ; Thu, 29 Oct 2009 23:47:11 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0E9118FC1D for ; Thu, 29 Oct 2009 23:47:10 +0000 (UTC) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id 463CD37367; Fri, 30 Oct 2009 00:29:18 +0100 (CET) Date: Fri, 30 Oct 2009 00:29:17 +0100 From: cpghost To: Jakub Lach Message-ID: <20091029232917.GC1599@phenom.cordula.ws> References: <26078773.post@talk.nabble.com> <4AEA091B.30304@FreeBSD.org> <26122214.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26122214.post@talk.nabble.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: No sound after update to RC2 from RC1. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 23:47:11 -0000 On Thu, Oct 29, 2009 at 04:05:33PM -0700, Jakub Lach wrote: > mav-3 wrote: > > > > Jakub Lach wrote: > >> Yes, I tried tracing related changes to no avail, furthermore I didn't > >> change > >> anything related in my configuration. > >> > >> Dmesg gives some insight: > >> > >> hdac0: Tracing association 1 (2) > >> hdac0: Unable to trace pin 24 to ADC 20, undo traces > >> hdac0: Pin 24 traced to ADC 21 > >> hdac0: Unable to trace pin 29 to ADC 21, undo traces > >> hdac0: Association 1 (2) trace failed > >> > >> Full dmesg + sndstat > >> > >> http://senduit.com/8fdabe > > > > It tells that file has expired. > > > > -- > > Alexander Motin > > You mean that my device.hints file is no longer valid? > What triggered it? He meant, the hosting provider senduit.com has expired your dmesg + sndstat: File has expired The file you are trying to download has expired and is no longer available. Without dmesg + sndstat output, noone can debug your problem. > -best regards, > Jakub Lach Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 05:24:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A31F9106566C for ; Fri, 30 Oct 2009 05:24:23 +0000 (UTC) (envelope-from npapke@acm.org) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 70E448FC0C for ; Fri, 30 Oct 2009 05:24:23 +0000 (UTC) Received: from pd3ml2so-ssvc.prod.shaw.ca ([10.0.141.138]) by pd2mo1so-svcs.prod.shaw.ca with ESMTP; 29 Oct 2009 22:56:20 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=4RXGTpSXdx4A:10 a=VF9RaR9bft6c8SsOr3WyFg==:17 a=N54-gffFAAAA:8 a=lvbMJxvVAAAA:8 a=0g5qCKgnRcvuIx0AyhwA:9 a=N9pifT2d1w6nidZpVSAA:7 a=6e5b_1GuNTLWY-SAu5443zvof2AA:4 a=nAPXUAfsBmEA:10 a=Y3Ys_gjPyRfF7G6R:21 a=lrc7eUymFKRU4WVk:21 Received: from unknown (HELO proven.lan) ([24.85.241.34]) by pd3ml2so-dmz.prod.shaw.ca with ESMTP; 29 Oct 2009 22:56:20 -0600 Received: from proven.lan (localhost [127.0.0.1]) by proven.lan (8.14.3/8.14.3) with ESMTP id n9U4uKas003607 for ; Thu, 29 Oct 2009 21:56:20 -0700 (PDT) (envelope-from npapke@acm.org) Received: from localhost (localhost [[UNIX: localhost]]) by proven.lan (8.14.3/8.14.3/Submit) id n9U4uJHG003606 for freebsd-stable@freebsd.org; Thu, 29 Oct 2009 21:56:19 -0700 (PDT) (envelope-from npapke@acm.org) X-Authentication-Warning: proven.lan: npapke set sender to npapke@acm.org using -f From: Norbert Papke Organization: Archaeological Filing To: freebsd-stable@freebsd.org Date: Thu, 29 Oct 2009 21:56:19 -0700 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200910292156.19845.npapke@acm.org> Subject: 7.2 Stable Crash - possibly related to if_re X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 05:24:23 -0000 This occurred shortly after "scp"ing from a VirtualBox VM to the host. The= =20 file transfer got stuck. The "re" interface stopped working. Shortly=20 afterwards, the host crashed. The "re" interface was used by the host, the= =20 guest was using a different NIC in bridged mode. =46reeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct 29=20 18:36:57 PDT 2009 =46atal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x18 fault code =3D supervisor write data, page not present instruction pointer =3D 0x8:0xffffffff80d476ee stack pointer =3D 0x10:0xffffff8000078ae0 frame pointer =3D 0x10:0xffffff8000078b40 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 18 (swi5: +) Physical memory: 8177 MB (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xffffffff801d5faf in db_fncall (dummy1=3DVariable "dummy1" is not=20 available. ) at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:516 #2 0xffffffff801d64b9 in db_command (last_cmdp=3D0xffffffff80b46ac8,=20 cmd_table=3D0x0, dopager=3D1) at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:413 #3 0xffffffff801d66bb in db_command_loop ()=20 at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:466 #4 0xffffffff801d8197 in db_trap (type=3DVariable "type" is not available. ) at /usr/public/freebsd/sources/stable/sys/ddb/db_main.c:228 #5 0xffffffff8054ab45 in kdb_trap (type=3D12, code=3D0, tf=3D0xffffff80000= 78a30) at /usr/public/freebsd/sources/stable/sys/kern/subr_kdb.c:524 #6 0xffffffff807fcdd3 in trap_fatal (frame=3D0xffffff8000078a30,=20 eva=3DVariable "eva" is not available. ) at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:772 #7 0xffffffff807fd185 in trap_pfault (frame=3D0xffffff8000078a30, usermode= =3D0) at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:693 #8 0xffffffff807fd9bd in trap (frame=3D0xffffff8000078a30) at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:464 #9 0xffffffff807e710e in calltrap ()=20 at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:218 #10 0xffffffff80d476ee in re_rxeof () from /boot/kernel/if_re.ko #11 0xffffffff80d4a481 in re_int_task (arg=3DVariable "arg" is not availabl= e. ) =20 at /usr/public/freebsd/sources/stable/sys/modules/re/../../dev/re/if_re.c:2= 191 #12 0xffffffff80554d46 in taskqueue_run (queue=3D0xffffff000192f300) at /usr/public/freebsd/sources/stable/sys/kern/subr_taskqueue.c:282 #13 0xffffffff804fbc1d in ithread_loop (arg=3D0xffffff00019433a0) at /usr/public/freebsd/sources/stable/sys/kern/kern_intr.c:1126 #14 0xffffffff804f83c4 in fork_exit (callout=3D0xffffffff804fbaa5=20 , arg=3D0xffffff00019433a0, frame=3D0xffffff8000078c80)=20 at /usr/public/freebsd/sources/stable/sys/kern/kern_fork.c:811 #15 0xffffffff807e74ee in fork_trampoline () at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:554 =46rom dmesg: re0: port 0xd800-0xd8ff mem=20 0xfeaff000-0xfeafffff,0xfdff0000-0xfdffffff irq 17 at device 0.0 on pci3 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,=20 1000baseT-FDX, auto re0: Ethernet address: 00:30:48:b0:6a:1f =20 =2D- Norbert Papke. npapke@acm.org http://saveournet.ca Protecting your Internet's level playing field From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 06:05:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38FF7106566B for ; Fri, 30 Oct 2009 06:05:48 +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 EE7818FC08 for ; Fri, 30 Oct 2009 06:05:47 +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 8BD678331; Fri, 30 Oct 2009 06:05:46 +0000 (UTC) Date: Fri, 30 Oct 2009 06:05:13 +0000 From: Bruce Cran To: Andrew Reilly Message-ID: <20091030060513.0000503b@unknown> In-Reply-To: <20091029220214.GA48360@duncan.reilly.home> References: <200910291550.n9TFo5wc035999@freefall.freebsd.org> <20091029220214.GA48360@duncan.reilly.home> X-Mailer: Claws Mail 3.7.2cvs15 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-amd64@FreeBSD.org Subject: Re: amd64/139859: commit references a PR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 06:05:48 -0000 On Fri, 30 Oct 2009 09:02:14 +1100 Andrew Reilly wrote: > On Thu, Oct 29, 2009 at 03:50:05PM +0000, dfilter service wrote: > > Modified: releng/8.0/UPDATING > > ============================================================================== > > --- releng/8.0/UPDATING Thu Oct 29 15:39:30 2009 > > (r198605) +++ releng/8.0/UPDATING Thu Oct 29 15:42:50 > > 2009 (r198606) @@ -566,6 +566,15 @@ NOTE TO PEOPLE WHO THINK > > THAT FreeBSD 8. userland (libpmc(3)) and the kernel module > > (hwpmc(4)) in sync. > > > > +20081009: > > + atapci kernel module now includes only generic PCI ATA > > + driver. AHCI driver moved to ataahci kernel module. > > That probably wants to say 20091029? The work was done in October last year (see http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/chipsets/ata-acard.c) but wasn't documented until now. -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 07:49:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E796C106566C for ; Fri, 30 Oct 2009 07:49:16 +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 C50E88FC0A for ; Fri, 30 Oct 2009 07:49:16 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1N3mEW-0004aI-5a for freebsd-stable@freebsd.org; Fri, 30 Oct 2009 00:49:16 -0700 Message-ID: <26126133.post@talk.nabble.com> Date: Fri, 30 Oct 2009 00:49:16 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org In-Reply-To: <20091029232917.GC1599@phenom.cordula.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <26078773.post@talk.nabble.com> <4AEA091B.30304@FreeBSD.org> <26122214.post@talk.nabble.com> <20091029232917.GC1599@phenom.cordula.ws> Subject: Re: No sound after update to RC2 from RC1. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 07:49:17 -0000 cpghost wrote: > > On Thu, Oct 29, 2009 at 04:05:33PM -0700, Jakub Lach wrote: >> mav-3 wrote: >> > >> > Jakub Lach wrote: >> >> Yes, I tried tracing related changes to no avail, furthermore I didn't >> >> change >> >> anything related in my configuration. >> >> >> >> Dmesg gives some insight: >> >> >> >> hdac0: Tracing association 1 (2) >> >> hdac0: Unable to trace pin 24 to ADC 20, undo traces >> >> hdac0: Pin 24 traced to ADC 21 >> >> hdac0: Unable to trace pin 29 to ADC 21, undo traces >> >> hdac0: Association 1 (2) trace failed >> >> >> >> Full dmesg + sndstat >> >> >> >> http://senduit.com/8fdabe >> > >> > It tells that file has expired. >> > >> > -- >> > Alexander Motin >> >> You mean that my device.hints file is no longer valid? >> What triggered it? > > He meant, the hosting provider senduit.com has expired your > dmesg + sndstat: > > File has expired > The file you are trying to download has expired and is no longer > available. > > Without dmesg + sndstat output, noone can debug your problem. > >> -best regards, >> Jakub Lach > > Regards, > -cpghost. > > -- > Cordula's Web. http://www.cordula.ws/ > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > I'm really sorry. http://senduit.com/55d199 -best regards, Jakub Lach -- View this message in context: http://old.nabble.com/No-sound-after-update-to-RC2-from-RC1.-tp26078773p26126133.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 08:48:32 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33DC1106566B; Fri, 30 Oct 2009 08:48: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 08B9B8FC15; Fri, 30 Oct 2009 08:48:31 +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 n9U8mT6U056568; Fri, 30 Oct 2009 04:48:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n9U8mTiT000908; Fri, 30 Oct 2009 04:48:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 525521B5060; Fri, 30 Oct 2009 04:48:29 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20091030084829.525521B5060@freebsd-stable.sentex.ca> Date: Fri, 30 Oct 2009 04:48:29 -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: [releng_7 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 08:48:32 -0000 TB --- 2009-10-30 07:41:34 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-10-30 07:41:34 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2009-10-30 07:41:34 - cleaning the object tree TB --- 2009-10-30 07:42:00 - cvsupping the source tree TB --- 2009-10-30 07:42:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2009-10-30 07:42:12 - building world TB --- 2009-10-30 07:42:12 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-30 07:42:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-30 07:42:12 - TARGET=pc98 TB --- 2009-10-30 07:42:12 - TARGET_ARCH=i386 TB --- 2009-10-30 07:42:12 - TZ=UTC TB --- 2009-10-30 07:42:12 - __MAKE_CONF=/dev/null TB --- 2009-10-30 07:42:12 - cd /src TB --- 2009-10-30 07:42:12 - /usr/bin/make -B buildworld >>> World build started on Fri Oct 30 07:42:13 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 Oct 30 08:46:35 UTC 2009 TB --- 2009-10-30 08:46:35 - generating LINT kernel config TB --- 2009-10-30 08:46:35 - cd /src/sys/pc98/conf TB --- 2009-10-30 08:46:35 - /usr/bin/make -B LINT TB --- 2009-10-30 08:46:36 - building LINT kernel TB --- 2009-10-30 08:46:36 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-30 08:46:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-30 08:46:36 - TARGET=pc98 TB --- 2009-10-30 08:46:36 - TARGET_ARCH=i386 TB --- 2009-10-30 08:46:36 - TZ=UTC TB --- 2009-10-30 08:46:36 - __MAKE_CONF=/dev/null TB --- 2009-10-30 08:46:36 - cd /src TB --- 2009-10-30 08:46:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Oct 30 08:46:36 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pc98/pc98/canbus_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -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 -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestand ing /src/sys/i386/i386/mp_machdep.c:76:25: error: machine/mca.h: No such file or directory /src/sys/i386/i386/trap.c:93:25: error: machine/mca.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-30 08:48:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-30 08:48:29 - ERROR: failed to build lint kernel TB --- 2009-10-30 08:48:29 - 3300.35 user 359.48 system 4014.80 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 09:12:45 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EB801065670 for ; Fri, 30 Oct 2009 09:12:45 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 05B9E8FC12 for ; Fri, 30 Oct 2009 09:12:44 +0000 (UTC) Received: by bwz5 with SMTP id 5so3321838bwz.3 for ; Fri, 30 Oct 2009 02:12:43 -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=meEWqQfLczDJJXyBJXTwHkkbr5QnA0lvcFfS6vkbhjg=; b=YqV4Ru/VzF/wo+nAETWDx+S0bF4tyAHTrbeyWW7M+fW3J0fK0HBKHVOILGND9UDsym 8YmfdXR9AkNtn4BzmVaIAbCTpgEPsTglNstnUJ3wstNThwgurRr6pGqN7HcXkVPzpoOv UqZ5ZOzIf1ZuwlKD0OzLt6jbSAHi1uEkPlcOU= 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=QCrKV3NVcm0IdcDsNo3WFZaP99PNKgI+QGlqEeLfZ+DDazuon6F6a3TeUENLFX7/w/ Pe0iyWjuyzf2ZlE+3ufMxLooIfxYqjNPV0zZP2b/PQ7ZRx9A/2vt6/NzU+B3pkfRqQ5C Y3+2rb3N7zaDKQHsxn5TmS3XPkrXkSxn4vfv0= MIME-Version: 1.0 Received: by 10.204.151.208 with SMTP id d16mr889385bkw.115.1256893963724; Fri, 30 Oct 2009 02:12:43 -0700 (PDT) In-Reply-To: <20091030084829.525521B5060@freebsd-stable.sentex.ca> References: <20091030084829.525521B5060@freebsd-stable.sentex.ca> Date: Fri, 30 Oct 2009 12:12:43 +0300 Message-ID: From: pluknet To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, i386@freebsd.org Subject: Re: [releng_7 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 09:12:45 -0000 2009/10/30 FreeBSD Tinderbox : > TB --- 2009-10-30 07:41:34 - tinderbox 2.6 running on freebsd-stable.sent= ex.ca > TB --- 2009-10-30 07:41:34 - starting RELENG_7 tinderbox run for i386/pc9= 8 > TB --- 2009-10-30 07:41:34 - cleaning the object tree > TB --- 2009-10-30 07:42:00 - cvsupping the source tree > TB --- 2009-10-30 07:42:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -= s /tinderbox/RELENG_7/i386/pc98/supfile > TB --- 2009-10-30 07:42:12 - building world > TB --- 2009-10-30 07:42:12 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2009-10-30 07:42:12 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-10-30 07:42:12 - TARGET=3Dpc98 > TB --- 2009-10-30 07:42:12 - TARGET_ARCH=3Di386 > TB --- 2009-10-30 07:42:12 - TZ=3DUTC > TB --- 2009-10-30 07:42:12 - __MAKE_CONF=3D/dev/null > TB --- 2009-10-30 07:42:12 - cd /src > TB --- 2009-10-30 07:42:12 - /usr/bin/make -B buildworld >>>> World build started on Fri Oct 30 07:42:13 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 Oct 30 08:46:35 UTC 2009 > TB --- 2009-10-30 08:46:35 - generating LINT kernel config > TB --- 2009-10-30 08:46:35 - cd /src/sys/pc98/conf > TB --- 2009-10-30 08:46:35 - /usr/bin/make -B LINT > TB --- 2009-10-30 08:46:36 - building LINT kernel > TB --- 2009-10-30 08:46:36 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2009-10-30 08:46:36 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-10-30 08:46:36 - TARGET=3Dpc98 > TB --- 2009-10-30 08:46:36 - TARGET_ARCH=3Di386 > TB --- 2009-10-30 08:46:36 - TZ=3DUTC > TB --- 2009-10-30 08:46:36 - __MAKE_CONF=3D/dev/null > TB --- 2009-10-30 08:46:36 - cd /src > TB --- 2009-10-30 08:46:36 - /usr/bin/make -B buildkernel KERNCONF=3DLINT >>>> Kernel build for LINT started on Fri Oct 30 08:46:36 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 > [...] > awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -= h > awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h > awk -f /src/sys/tools/makeobjops.awk /src/sys/pc98/pc98/canbus_if.m -h > rm -f .newdep > /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | =A0MKDEP_CPP=3D"= cc -E" CC=3D"cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing = =A0-std=3Dc99 =A0-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototyp= es =A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef = -Wno-pointer-sign -fformat-extensions -nostdinc =A0-I. -I/src/sys -I/src/sy= s/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys= /dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev= /twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I= /src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cx= gb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common= -finline-limit=3D8000 --param inline-unit-growth=3D100 --param large-funct= ion-growth=3D1000 -DGPROF -falign-functions=3D16 -DGPROF4 -DGUPROF -fno-bui= ltin -mno-align-long-strings -mpreferred-stack-boundary=3D2 =A0-mno-mmx -mn= o-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestand > =A0ing > /src/sys/i386/i386/mp_machdep.c:76:25: error: machine/mca.h: No such file= or directory > /src/sys/i386/i386/trap.c:93:25: error: machine/mca.h: No such file or di= rectory > mkdep: compile failed MFC r192106 ? --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 12:52:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B61FF1065676 for ; Fri, 30 Oct 2009 12:52:23 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 140188FC22 for ; Fri, 30 Oct 2009 12:52:22 +0000 (UTC) Received: by bwz5 with SMTP id 5so3551196bwz.3 for ; Fri, 30 Oct 2009 05:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=uIWKcb8/4Uyrx6RT1AxRw/6Jzwu02FAMAbisZ7ab+L4=; b=YxdAvmcGDEV00mVvDDxZdbdyu8c/zkOzDc4VKHYGvnQsKJGUPG6E3dNjJWOerQC4PI +PAwoC9YcY5JKp+jT74CmKz2gH9VWSG4QbPy/0pIeunxoUkMWifuB6n8f6yD5BSHDuN2 aOPK3rqFK1Wi3SIzfQseFpSw/hlMENyxwSwyM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=rdZ+eujz6tRtbSYo1wa6rq6NxdNHPnusRd/JO35bN0FK+9sa8U5ZqjJS1D57GTns/F btOkSYLOSoN6zxgJ4AtklIVQwEWSBajbUwPbjqz7g9KuH35U47HoU+WYQ+JscQGyJtwI ntUusGIWIxztukTiYG7L4qy8/Sq9RdtFwKsIE= Received: by 10.103.125.19 with SMTP id c19mr614717mun.59.1256907141196; Fri, 30 Oct 2009 05:52:21 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id u9sm3593738muf.1.2009.10.30.05.52.20 (version=SSLv3 cipher=RC4-MD5); Fri, 30 Oct 2009 05:52:20 -0700 (PDT) Sender: Alexander Motin Message-ID: <4AEAE181.1050304@FreeBSD.org> Date: Fri, 30 Oct 2009 14:52:17 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Jakub Lach References: <1256667780.00177464.1256654401@10.7.7.3> <1256865780.00178296.1256852401@10.7.7.3> <1256869384.00178335.1256857801@10.7.7.3> <1256872982.00178351.1256860203@10.7.7.3> <1256901782.00178420.1256889004@10.7.7.3> In-Reply-To: <1256901782.00178420.1256889004@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: No sound after update to RC2 from RC1. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 12:52:23 -0000 Jakub Lach wrote: > cpghost wrote: >> On Thu, Oct 29, 2009 at 04:05:33PM -0700, Jakub Lach wrote: >>> mav-3 wrote: >>>> Jakub Lach wrote: >>>>> Yes, I tried tracing related changes to no avail, furthermore I didn't >>>>> change >>>>> anything related in my configuration. >>>>> >>>>> Dmesg gives some insight: >>>>> >>>>> hdac0: Tracing association 1 (2) >>>>> hdac0: Unable to trace pin 24 to ADC 20, undo traces >>>>> hdac0: Pin 24 traced to ADC 21 >>>>> hdac0: Unable to trace pin 29 to ADC 21, undo traces >>>>> hdac0: Association 1 (2) trace failed >>>>> >>>>> Full dmesg + sndstat >>>>> > http://senduit.com/55d199 I don't know how it could work before, as looks like this codec unable to pass both mics to the same ADC. Also you seems not configured audio redirection. I would propose you such configuration with redirection: hint.hdac.0.cad0.nid22.config="as=1 seq=15" hint.hdac.0.cad0.nid24.config="as=3" hint.hdac.0.cad0.nid26.config="as=1" hint.hdac.0.cad0.nid29.config="as=2" or such with two separate pcm devices: hint.hdac.0.cad0.nid22.config="as=3" hint.hdac.0.cad0.nid24.config="as=4" hint.hdac.0.cad0.nid26.config="as=1" hint.hdac.0.cad0.nid29.config="as=2" -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 16:01:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 228091065697 for ; Fri, 30 Oct 2009 16:01:00 +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 DAF018FC31 for ; Fri, 30 Oct 2009 16:00:59 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1N3tuN-0005zF-7Q for freebsd-stable@freebsd.org; Fri, 30 Oct 2009 09:00:59 -0700 Message-ID: <26132631.post@talk.nabble.com> Date: Fri, 30 Oct 2009 09:00:59 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org In-Reply-To: <4AEAE181.1050304@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <26078773.post@talk.nabble.com> <4AEAE181.1050304@FreeBSD.org> Subject: Re: No sound after update to RC2 from RC1. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 16:01:00 -0000 mav-3 wrote: > > Jakub Lach wrote: >> cpghost wrote: >>> On Thu, Oct 29, 2009 at 04:05:33PM -0700, Jakub Lach wrote: >>>> mav-3 wrote: >>>>> Jakub Lach wrote: >>>>>> Yes, I tried tracing related changes to no avail, furthermore I >>>>>> didn't >>>>>> change >>>>>> anything related in my configuration. >>>>>> >>>>>> Dmesg gives some insight: >>>>>> >>>>>> hdac0: Tracing association 1 (2) >>>>>> hdac0: Unable to trace pin 24 to ADC 20, undo traces >>>>>> hdac0: Pin 24 traced to ADC 21 >>>>>> hdac0: Unable to trace pin 29 to ADC 21, undo traces >>>>>> hdac0: Association 1 (2) trace failed >>>>>> >>>>>> Full dmesg + sndstat >>>>>> >> http://senduit.com/55d199 > > I don't know how it could work before, as looks like this codec unable > to pass both mics to the same ADC. Also you seems not configured audio > redirection. > > I would propose you such configuration with redirection: > > hint.hdac.0.cad0.nid22.config="as=1 seq=15" > hint.hdac.0.cad0.nid24.config="as=3" > hint.hdac.0.cad0.nid26.config="as=1" > hint.hdac.0.cad0.nid29.config="as=2" > > or such with two separate pcm devices: > > hint.hdac.0.cad0.nid22.config="as=3" > hint.hdac.0.cad0.nid24.config="as=4" > hint.hdac.0.cad0.nid26.config="as=1" > hint.hdac.0.cad0.nid29.config="as=2" > > -- > Alexander Motin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > Thank you for your kind support. Still no sound. http://senduit.com/d3a51b http://senduit.com/873ec6 I admit that I didn't study with required diligence device.hints hda configuration, however I copied one which worked for L. Windschuh, and he uses very similar laptop. -best regards, Jakub Lach -- View this message in context: http://old.nabble.com/No-sound-after-update-to-RC2-from-RC1.-tp26078773p26132631.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 16:01:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF54C106570B for ; Fri, 30 Oct 2009 16:01:18 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id 66E808FC0A for ; Fri, 30 Oct 2009 16:01:17 +0000 (UTC) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by kagate2.punkt.de with ESMTP id n9UG1GUT021368 for ; Fri, 30 Oct 2009 17:01:16 +0100 (CET) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id n9UG1G7m083704 for ; Fri, 30 Oct 2009 17:01:16 +0100 (CET) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.14.2/8.14.2/Submit) id n9UG1GXU083703 for freebsd-stable@freebsd.org; Fri, 30 Oct 2009 17:01:16 +0100 (CET) (envelope-from ry93) Date: Fri, 30 Oct 2009 17:01:16 +0100 From: "Patrick M. Hausen" To: FreeBSD Stable Mailing List Message-ID: <20091030160115.GB81189@hugo10.ka.punkt.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.17 (2007-11-01) Subject: boot0cfg and gmirror again X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 16:01:19 -0000 Hi, all, Our hosting servers use a NanoBSD disk layout for rapid updates and - if necessary - fallback to the former working version of the system. I just tested the update from RELENG_6_3 to RELENG_7_2, because I was concerned about the one-way upgrade of the on disk data for gmirror. That part went great. We are, however, still struggling to autmatically switch the active partititon after dd'ing an update to the inactive one: new_server# uname -a FreeBSD new_server 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 30 14:49:14 CET 2009 root@nanobsd.ka.punkt.de:/var/home/nanobsd/obj/rx100s5-hosting/usr/src/sys/GENERIC amd64 new_server# gmirror status Name Status Components mirror/m0 COMPLETE ad4 ad6 new_server# fdisk /dev/mirror/m0 ******* Working on device /dev/mirror/m0 ******* parameters extracted from in-core disklabel are: cylinders=30401 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=30401 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 16065, size 16418430 (8016 Meg), flag 0 beg: cyl 1/ head 0/ sector 1; end: cyl 1022/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 16434495, size 16418430 (8016 Meg), flag 80 (active) beg: cyl 1023/ head 0/ sector 1; end: cyl 1020/ head 254/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 32852925, size 455539140 (222431 Meg), flag 0 beg: cyl 1021/ head 0/ sector 1; end: cyl 704/ head 254/ sector 63 The data for partition 4 is: new_server# mount /dev/mirror/m0s2a on / (ufs, local, read-only) devfs on /dev (devfs, local) /dev/mirror/m0s3a on /etc (ufs, local) /dev/mirror/m0s3d on /var (ufs, local, soft-updates) That's the status of the system, now let's try to activate partition 1: new_server# sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 -> 16 new_server# boot0cfg -v -s1 /dev/mirror/m0 boot0cfg: /dev/mirror/m0: Geom not found: "m0" boot0cfg: /dev/mirror/m0: ioctl DIOCSMBR: Operation not permitted Now, what? This was discussed here, already, and I got the impression that a solution was to be in RELENG_7: http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044487.html Tanks for any insight. Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 16:54:51 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F1931065696 for ; Fri, 30 Oct 2009 16:54:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id 020A88FC0C for ; Fri, 30 Oct 2009 16:54:50 +0000 (UTC) Received: by qyk6 with SMTP id 6so1709909qyk.3 for ; Fri, 30 Oct 2009 09:54:50 -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=Ztn1vSjnK8pCE1TWmRnfZPxwkQMbwoWDdb0ORv6FquM=; b=sA123DKUUR4qL5vmWsBF7V4NqlLmSvjW0x6kiEOZzu7d2qgxMv6ejzwLbb4n3rnl7h rfPRKbh5PuaACHhgpxDW6Yiw3G2OR+Fme6rs3dOgTSy5TytrtvhLCh42AtFA1XsY/W9O m9gOKuzy2yTl2NhssgcZgUVDgTpX5wW0vuMsc= 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=ihK2/9xXY6SqOoROqnSOUk3WKKchujhLDeItKcgw3aMgubVTgDgYCfTWf8hUWPGcA+ JqkBXu8kxCGEseEOTGWUioo2x1t/OW0ep/dbPLNAhSAr88deojN7nEKzmmTpmsiXLWcs 9lFYJRGGEQvZ1TBhSegq9g9pbiUO4rl9I7a18= Received: by 10.224.101.206 with SMTP id d14mr1109899qao.238.1256921690124; Fri, 30 Oct 2009 09:54:50 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 21sm2219084qyk.8.2009.10.30.09.54.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Oct 2009 09:54:48 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 30 Oct 2009 09:54:51 -0700 From: Pyun YongHyeon Date: Fri, 30 Oct 2009 09:54:51 -0700 To: Norbert Papke Message-ID: <20091030165451.GA17243@michelle.cdnetworks.com> References: <200910292156.19845.npapke@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910292156.19845.npapke@acm.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: 7.2 Stable Crash - possibly related to if_re X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 16:54:51 -0000 On Thu, Oct 29, 2009 at 09:56:19PM -0700, Norbert Papke wrote: > This occurred shortly after "scp"ing from a VirtualBox VM to the host. The > file transfer got stuck. The "re" interface stopped working. Shortly > afterwards, the host crashed. The "re" interface was used by the host, the > guest was using a different NIC in bridged mode. > > > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct 29 > 18:36:57 PDT 2009 > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 It looks like a NULL pointer dereference, possibly mbuf related one. > fault code = supervisor write data, page not present > instruction pointer = 0x8:0xffffffff80d476ee > stack pointer = 0x10:0xffffff8000078ae0 > frame pointer = 0x10:0xffffff8000078b40 > 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 = 18 (swi5: +) > Physical memory: 8177 MB > > > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xffffffff801d5faf in db_fncall (dummy1=Variable "dummy1" is not > available. > ) at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:516 > #2 0xffffffff801d64b9 in db_command (last_cmdp=0xffffffff80b46ac8, > cmd_table=0x0, dopager=1) > at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:413 > #3 0xffffffff801d66bb in db_command_loop () > at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:466 > #4 0xffffffff801d8197 in db_trap (type=Variable "type" is not available. > ) at /usr/public/freebsd/sources/stable/sys/ddb/db_main.c:228 > #5 0xffffffff8054ab45 in kdb_trap (type=12, code=0, tf=0xffffff8000078a30) > at /usr/public/freebsd/sources/stable/sys/kern/subr_kdb.c:524 > #6 0xffffffff807fcdd3 in trap_fatal (frame=0xffffff8000078a30, > eva=Variable "eva" is not available. > ) > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:772 > #7 0xffffffff807fd185 in trap_pfault (frame=0xffffff8000078a30, usermode=0) > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:693 > #8 0xffffffff807fd9bd in trap (frame=0xffffff8000078a30) > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:464 > #9 0xffffffff807e710e in calltrap () > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:218 > #10 0xffffffff80d476ee in re_rxeof () from /boot/kernel/if_re.ko Hmm, I think there is a missing information here. Not sure where it dereferenced a NULL pointer in re_rxeof(). Because that this is the first report for NULL pointer dereference in Rx handler I need more information how to reproduce it with minimal configuration. Can you also reproduce the issues without virtual box? By chance, did you stop the re0 interface with ifconfig when you noticed the file transfer got stuck? > #11 0xffffffff80d4a481 in re_int_task (arg=Variable "arg" is not available. > ) > > at /usr/public/freebsd/sources/stable/sys/modules/re/../../dev/re/if_re.c:2191 > #12 0xffffffff80554d46 in taskqueue_run (queue=0xffffff000192f300) > at /usr/public/freebsd/sources/stable/sys/kern/subr_taskqueue.c:282 > #13 0xffffffff804fbc1d in ithread_loop (arg=0xffffff00019433a0) > at /usr/public/freebsd/sources/stable/sys/kern/kern_intr.c:1126 > #14 0xffffffff804f83c4 in fork_exit (callout=0xffffffff804fbaa5 > , arg=0xffffff00019433a0, > frame=0xffffff8000078c80) > at /usr/public/freebsd/sources/stable/sys/kern/kern_fork.c:811 > #15 0xffffffff807e74ee in fork_trampoline () > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:554 > From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 18:39:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C665106566B for ; Fri, 30 Oct 2009 18:39:56 +0000 (UTC) (envelope-from tiago.s.araujo@gmail.com) Received: from mail-gx0-f215.google.com (mail-gx0-f215.google.com [209.85.217.215]) by mx1.freebsd.org (Postfix) with ESMTP id 018F38FC1A for ; Fri, 30 Oct 2009 18:39:55 +0000 (UTC) Received: by gxk7 with SMTP id 7so1112054gxk.14 for ; Fri, 30 Oct 2009 11:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=sWQ/69aCfEPGrHL1cILs/oqn3qxzLiQ2/r1CihZRhg0=; b=Pgcf+lGqhskoK/cjQVxDUIqQTxVQEQ9RVi+ta4IHfSsxE+T3h82IcLKL/9+11klT6X 35cS2a8lj1PVJ2DQVN3MlRxLM1qRCAcjV6kIOqjZJ6VDvFMr55i4Lu/ldk/mfTICay8e YA3V1Z8EWOYl5E1Ria2ivt6AzrG25s9sOHBb4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=D2Zq26gTjtrVcuUaY/tKnu78YCcyVi+AhK/qWrUs8XAp8hLO92phW6/70eVHePGo2p CEIVQoUxpmTacWeEQ703hRtOyrbVX7+7PB1qbez/qa8lpNuBiIfMTbQKZSSvN8rs8N68 Geynrf4ZCMXfV7BTiOe80pY0HUd+b4H4NxZYk= Received: by 10.101.153.30 with SMTP id f30mr2152423ano.0.1256926188740; Fri, 30 Oct 2009 11:09:48 -0700 (PDT) Received: from TiagoAraujoPC ([189.57.247.82]) by mx.google.com with ESMTPS id 39sm1455683yxd.27.2009.10.30.11.09.47 (version=SSLv3 cipher=RC4-MD5); Fri, 30 Oct 2009 11:09:48 -0700 (PDT) From: "Tiago Araujo" To: Date: Fri, 30 Oct 2009 16:09:41 -0200 Message-ID: <4aeb2bec.e701be0a.771c.ffffa8bd@mx.google.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpZjCbtqyQvUwZBQBaZVnWXdDPlJg== Content-Language: pt-br Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Adding Me for Maillist (Freebsd) Please X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 18:39:56 -0000 Dear, Please.... Add for me in mail list! Att, Tiago Araujo Manage Administrator From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 19:26:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18280106568F; Fri, 30 Oct 2009 19:26:17 +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 DC9248FC18; Fri, 30 Oct 2009 19:26:16 +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 571F146B06; Fri, 30 Oct 2009 15:26:16 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 60E9B8A01D; Fri, 30 Oct 2009 15:26:15 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 30 Oct 2009 15:07:29 -0400 User-Agent: KMail/1.9.7 References: <20091030084829.525521B5060@freebsd-stable.sentex.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Disposition: inline Message-Id: <200910301507.29875.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 30 Oct 2009 15:26:15 -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: stable@freebsd.org, pluknet , FreeBSD Tinderbox , i386@freebsd.org Subject: Re: [releng_7 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 19:26:17 -0000 T24gRnJpZGF5IDMwIE9jdG9iZXIgMjAwOSA1OjEyOjQzIGFtIHBsdWtuZXQgd3JvdGU6Cj4gMjAw OS8xMC8zMCBGcmVlQlNEIFRpbmRlcmJveCA8dGluZGVyYm94QGZyZWVic2Qub3JnPjoKPiA+IFRC IC0tLSAyMDA5LTEwLTMwIDA3OjQxOjM0IC0gdGluZGVyYm94IDIuNiBydW5uaW5nIG9uIGZyZWVi c2Qtc3RhYmxlLnNlbnRleC5jYQo+ID4gVEIgLS0tIDIwMDktMTAtMzAgMDc6NDE6MzQgLSBzdGFy dGluZyBSRUxFTkdfNyB0aW5kZXJib3ggcnVuIGZvciBpMzg2L3BjOTgKPiA+IFRCIC0tLSAyMDA5 LTEwLTMwIDA3OjQxOjM0IC0gY2xlYW5pbmcgdGhlIG9iamVjdCB0cmVlCj4gPiBUQiAtLS0gMjAw OS0xMC0zMCAwNzo0MjowMCAtIGN2c3VwcGluZyB0aGUgc291cmNlIHRyZWUKPiA+IFRCIC0tLSAy MDA5LTEwLTMwIDA3OjQyOjAwIC0gL3Vzci9iaW4vY3N1cCAteiAtciAzIC1nIC1MIDEgLWggbG9j YWxob3N0IC1zIC90aW5kZXJib3gvUkVMRU5HXzcvaTM4Ni9wYzk4L3N1cGZpbGUKPiA+IFRCIC0t LSAyMDA5LTEwLTMwIDA3OjQyOjEyIC0gYnVpbGRpbmcgd29ybGQKPiA+IFRCIC0tLSAyMDA5LTEw LTMwIDA3OjQyOjEyIC0gTUFLRU9CSkRJUlBSRUZJWD0vb2JqCj4gPiBUQiAtLS0gMjAwOS0xMC0z MCAwNzo0MjoxMiAtIFBBVEg9L3Vzci9iaW46L3Vzci9zYmluOi9iaW46L3NiaW4KPiA+IFRCIC0t LSAyMDA5LTEwLTMwIDA3OjQyOjEyIC0gVEFSR0VUPXBjOTgKPiA+IFRCIC0tLSAyMDA5LTEwLTMw IDA3OjQyOjEyIC0gVEFSR0VUX0FSQ0g9aTM4Ngo+ID4gVEIgLS0tIDIwMDktMTAtMzAgMDc6NDI6 MTIgLSBUWj1VVEMKPiA+IFRCIC0tLSAyMDA5LTEwLTMwIDA3OjQyOjEyIC0gX19NQUtFX0NPTkY9 L2Rldi9udWxsCj4gPiBUQiAtLS0gMjAwOS0xMC0zMCAwNzo0MjoxMiAtIGNkIC9zcmMKPiA+IFRC IC0tLSAyMDA5LTEwLTMwIDA3OjQyOjEyIC0gL3Vzci9iaW4vbWFrZSAtQiBidWlsZHdvcmxkCj4g Pj4+PiBXb3JsZCBidWlsZCBzdGFydGVkIG9uIEZyaSBPY3QgMzAgMDc6NDI6MTMgVVRDIDIwMDkK PiA+Pj4+IFJlYnVpbGRpbmcgdGhlIHRlbXBvcmFyeSBidWlsZCB0cmVlCj4gPj4+PiBzdGFnZSAx LjE6IGxlZ2FjeSByZWxlYXNlIGNvbXBhdGliaWxpdHkgc2hpbXMKPiA+Pj4+IHN0YWdlIDEuMjog Ym9vdHN0cmFwIHRvb2xzCj4gPj4+PiBzdGFnZSAyLjE6IGNsZWFuaW5nIHVwIHRoZSBvYmplY3Qg dHJlZQo+ID4+Pj4gc3RhZ2UgMi4yOiByZWJ1aWxkaW5nIHRoZSBvYmplY3QgdHJlZQo+ID4+Pj4g c3RhZ2UgMi4zOiBidWlsZCB0b29scwo+ID4+Pj4gc3RhZ2UgMzogY3Jvc3MgdG9vbHMKPiA+Pj4+ IHN0YWdlIDQuMTogYnVpbGRpbmcgaW5jbHVkZXMKPiA+Pj4+IHN0YWdlIDQuMjogYnVpbGRpbmcg bGlicmFyaWVzCj4gPj4+PiBzdGFnZSA0LjM6IG1ha2UgZGVwZW5kZW5jaWVzCj4gPj4+PiBzdGFn ZSA0LjQ6IGJ1aWxkaW5nIGV2ZXJ5dGhpbmcKPiA+Pj4+IFdvcmxkIGJ1aWxkIGNvbXBsZXRlZCBv biBGcmkgT2N0IDMwIDA4OjQ2OjM1IFVUQyAyMDA5Cj4gPiBUQiAtLS0gMjAwOS0xMC0zMCAwODo0 NjozNSAtIGdlbmVyYXRpbmcgTElOVCBrZXJuZWwgY29uZmlnCj4gPiBUQiAtLS0gMjAwOS0xMC0z MCAwODo0NjozNSAtIGNkIC9zcmMvc3lzL3BjOTgvY29uZgo+ID4gVEIgLS0tIDIwMDktMTAtMzAg MDg6NDY6MzUgLSAvdXNyL2Jpbi9tYWtlIC1CIExJTlQKPiA+IFRCIC0tLSAyMDA5LTEwLTMwIDA4 OjQ2OjM2IC0gYnVpbGRpbmcgTElOVCBrZXJuZWwKPiA+IFRCIC0tLSAyMDA5LTEwLTMwIDA4OjQ2 OjM2IC0gTUFLRU9CSkRJUlBSRUZJWD0vb2JqCj4gPiBUQiAtLS0gMjAwOS0xMC0zMCAwODo0Njoz NiAtIFBBVEg9L3Vzci9iaW46L3Vzci9zYmluOi9iaW46L3NiaW4KPiA+IFRCIC0tLSAyMDA5LTEw LTMwIDA4OjQ2OjM2IC0gVEFSR0VUPXBjOTgKPiA+IFRCIC0tLSAyMDA5LTEwLTMwIDA4OjQ2OjM2 IC0gVEFSR0VUX0FSQ0g9aTM4Ngo+ID4gVEIgLS0tIDIwMDktMTAtMzAgMDg6NDY6MzYgLSBUWj1V VEMKPiA+IFRCIC0tLSAyMDA5LTEwLTMwIDA4OjQ2OjM2IC0gX19NQUtFX0NPTkY9L2Rldi9udWxs Cj4gPiBUQiAtLS0gMjAwOS0xMC0zMCAwODo0NjozNiAtIGNkIC9zcmMKPiA+IFRCIC0tLSAyMDA5 LTEwLTMwIDA4OjQ2OjM2IC0gL3Vzci9iaW4vbWFrZSAtQiBidWlsZGtlcm5lbCBLRVJOQ09ORj1M SU5UCj4gPj4+PiBLZXJuZWwgYnVpbGQgZm9yIExJTlQgc3RhcnRlZCBvbiBGcmkgT2N0IDMwIDA4 OjQ2OjM2IFVUQyAyMDA5Cj4gPj4+PiBzdGFnZSAxOiBjb25maWd1cmluZyB0aGUga2VybmVsCj4g Pj4+PiBzdGFnZSAyLjE6IGNsZWFuaW5nIHVwIHRoZSBvYmplY3QgdHJlZQo+ID4+Pj4gc3RhZ2Ug Mi4yOiByZWJ1aWxkaW5nIHRoZSBvYmplY3QgdHJlZQo+ID4+Pj4gc3RhZ2UgMi4zOiBidWlsZCB0 b29scwo+ID4+Pj4gc3RhZ2UgMy4xOiBtYWtpbmcgZGVwZW5kZW5jaWVzCj4gPiBbLi4uXQo+ID4g YXdrIC1mIC9zcmMvc3lzL3Rvb2xzL21ha2VvYmpvcHMuYXdrIC9zcmMvc3lzL29wZW5jcnlwdG8v Y3J5cHRvZGV2X2lmLm0gLWgKPiA+IGF3ayAtZiAvc3JjL3N5cy90b29scy9tYWtlb2Jqb3BzLmF3 ayAvc3JjL3N5cy9wY2kvYWdwX2lmLm0gLWgKPiA+IGF3ayAtZiAvc3JjL3N5cy90b29scy9tYWtl b2Jqb3BzLmF3ayAvc3JjL3N5cy9wYzk4L3BjOTgvY2FuYnVzX2lmLm0gLWgKPiA+IHJtIC1mIC5u ZXdkZXAKPiA+IC91c3IvYmluL21ha2UgLVYgQ0ZJTEVTIC1WIFNZU1RFTV9DRklMRVMgLVYgR0VO X0NGSUxFUyB8IKBNS0RFUF9DUFA9ImNjIC1FIiBDQz0iY2MiIHhhcmdzIG1rZGVwIC1hIC1mIC5u ZXdkZXAgLU8yIC1waXBlIC1mbm8tc3RyaWN0LWFsaWFzaW5nIKAtc3RkPWM5OSCgLVdhbGwgLVdy ZWR1bmRhbnQtZGVjbHMgLVduZXN0ZWQtZXh0ZXJucyAtV3N0cmljdC1wcm90b3R5cGVzIKAtV21p c3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVdpbmxpbmUgLVdjYXN0LXF1YWwgoC1X dW5kZWYgLVduby1wb2ludGVyLXNpZ24gLWZmb3JtYXQtZXh0ZW5zaW9ucyAtbm9zdGRpbmMgoC1J LiAtSS9zcmMvc3lzIC1JL3NyYy9zeXMvY29udHJpYi9hbHRxIC1JL3NyYy9zeXMvY29udHJpYi9p cGZpbHRlciAtSS9zcmMvc3lzL2NvbnRyaWIvcGYgLUkvc3JjL3N5cy9kZXYvYXRoIC1JL3NyYy9z eXMvZGV2L2F0aC9hdGhfaGFsIC1JL3NyYy9zeXMvY29udHJpYi9uZ2F0bSAtSS9zcmMvc3lzL2Rl di90d2EgLUkvc3JjL3N5cy9nbnUvZnMveGZzL0ZyZWVCU0QgLUkvc3JjL3N5cy9nbnUvZnMveGZz L0ZyZWVCU0Qvc3VwcG9ydCAtSS9zcmMvc3lzL2dudS9mcy94ZnMgLUkvc3JjL3N5cy9jb250cmli L29wZW5zb2xhcmlzL2NvbXBhdCAtSS9zcmMvc3lzL2Rldi9jeGdiIC1EX0tFUk5FTCAtREhBVkVf S0VSTkVMX09QVElPTl9IRUFERVJTIC1pbmNsdWRlIG9wdF9nbG9iYWwuaCAtZm5vLWNvbW1vbiAt ZmlubGluZS1saW1pdD04MDAwIC0tcGFyYW0gaW5saW5lLXVuaXQtZ3Jvd3RoPTEwMCAtLXBhcmFt IGxhcmdlLWZ1bmN0aW9uLWdyb3d0aD0xMDAwIC1ER1BST0YgLWZhbGlnbi1mdW5jdGlvbnM9MTYg LURHUFJPRjQgLURHVVBST0YgLWZuby1idWlsdGluIC1tbm8tYWxpZ24tbG9uZy1zdHJpbmdzIC1t cHJlZmVycmVkLXN0YWNrLWJvdW5kYXJ5PTIgoC1tbm8tbW14IC1tbm8tM2Rub3cgLW1uby1zc2Ug LW1uby1zc2UyIC1tbm8tc3NlMyAtZmZyZWVzdGFuZAo+ID4goGluZwo+ID4gL3NyYy9zeXMvaTM4 Ni9pMzg2L21wX21hY2hkZXAuYzo3NjoyNTogZXJyb3I6IG1hY2hpbmUvbWNhLmg6IE5vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnkKPiA+IC9zcmMvc3lzL2kzODYvaTM4Ni90cmFwLmM6OTM6MjU6IGVy cm9yOiBtYWNoaW5lL21jYS5oOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Cj4gPiBta2RlcDog Y29tcGlsZSBmYWlsZWQKPiAKPiBNRkMgcjE5MjEwNiA/CgpEb2gsIHllcy4gIFdpbGwgZml4IGl0 IGluIGEgYml0LgoKLS0gCkpvaG4gQmFsZHdpbgo= From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 19:26:17 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18280106568F; Fri, 30 Oct 2009 19:26:17 +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 DC9248FC18; Fri, 30 Oct 2009 19:26:16 +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 571F146B06; Fri, 30 Oct 2009 15:26:16 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 60E9B8A01D; Fri, 30 Oct 2009 15:26:15 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 30 Oct 2009 15:07:29 -0400 User-Agent: KMail/1.9.7 References: <20091030084829.525521B5060@freebsd-stable.sentex.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Disposition: inline Message-Id: <200910301507.29875.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 30 Oct 2009 15:26:15 -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: stable@freebsd.org, pluknet , FreeBSD Tinderbox , i386@freebsd.org Subject: Re: [releng_7 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 19:26:17 -0000 T24gRnJpZGF5IDMwIE9jdG9iZXIgMjAwOSA1OjEyOjQzIGFtIHBsdWtuZXQgd3JvdGU6Cj4gMjAw OS8xMC8zMCBGcmVlQlNEIFRpbmRlcmJveCA8dGluZGVyYm94QGZyZWVic2Qub3JnPjoKPiA+IFRC IC0tLSAyMDA5LTEwLTMwIDA3OjQxOjM0IC0gdGluZGVyYm94IDIuNiBydW5uaW5nIG9uIGZyZWVi c2Qtc3RhYmxlLnNlbnRleC5jYQo+ID4gVEIgLS0tIDIwMDktMTAtMzAgMDc6NDE6MzQgLSBzdGFy dGluZyBSRUxFTkdfNyB0aW5kZXJib3ggcnVuIGZvciBpMzg2L3BjOTgKPiA+IFRCIC0tLSAyMDA5 LTEwLTMwIDA3OjQxOjM0IC0gY2xlYW5pbmcgdGhlIG9iamVjdCB0cmVlCj4gPiBUQiAtLS0gMjAw OS0xMC0zMCAwNzo0MjowMCAtIGN2c3VwcGluZyB0aGUgc291cmNlIHRyZWUKPiA+IFRCIC0tLSAy MDA5LTEwLTMwIDA3OjQyOjAwIC0gL3Vzci9iaW4vY3N1cCAteiAtciAzIC1nIC1MIDEgLWggbG9j YWxob3N0IC1zIC90aW5kZXJib3gvUkVMRU5HXzcvaTM4Ni9wYzk4L3N1cGZpbGUKPiA+IFRCIC0t LSAyMDA5LTEwLTMwIDA3OjQyOjEyIC0gYnVpbGRpbmcgd29ybGQKPiA+IFRCIC0tLSAyMDA5LTEw LTMwIDA3OjQyOjEyIC0gTUFLRU9CSkRJUlBSRUZJWD0vb2JqCj4gPiBUQiAtLS0gMjAwOS0xMC0z MCAwNzo0MjoxMiAtIFBBVEg9L3Vzci9iaW46L3Vzci9zYmluOi9iaW46L3NiaW4KPiA+IFRCIC0t LSAyMDA5LTEwLTMwIDA3OjQyOjEyIC0gVEFSR0VUPXBjOTgKPiA+IFRCIC0tLSAyMDA5LTEwLTMw IDA3OjQyOjEyIC0gVEFSR0VUX0FSQ0g9aTM4Ngo+ID4gVEIgLS0tIDIwMDktMTAtMzAgMDc6NDI6 MTIgLSBUWj1VVEMKPiA+IFRCIC0tLSAyMDA5LTEwLTMwIDA3OjQyOjEyIC0gX19NQUtFX0NPTkY9 L2Rldi9udWxsCj4gPiBUQiAtLS0gMjAwOS0xMC0zMCAwNzo0MjoxMiAtIGNkIC9zcmMKPiA+IFRC IC0tLSAyMDA5LTEwLTMwIDA3OjQyOjEyIC0gL3Vzci9iaW4vbWFrZSAtQiBidWlsZHdvcmxkCj4g Pj4+PiBXb3JsZCBidWlsZCBzdGFydGVkIG9uIEZyaSBPY3QgMzAgMDc6NDI6MTMgVVRDIDIwMDkK PiA+Pj4+IFJlYnVpbGRpbmcgdGhlIHRlbXBvcmFyeSBidWlsZCB0cmVlCj4gPj4+PiBzdGFnZSAx LjE6IGxlZ2FjeSByZWxlYXNlIGNvbXBhdGliaWxpdHkgc2hpbXMKPiA+Pj4+IHN0YWdlIDEuMjog Ym9vdHN0cmFwIHRvb2xzCj4gPj4+PiBzdGFnZSAyLjE6IGNsZWFuaW5nIHVwIHRoZSBvYmplY3Qg dHJlZQo+ID4+Pj4gc3RhZ2UgMi4yOiByZWJ1aWxkaW5nIHRoZSBvYmplY3QgdHJlZQo+ID4+Pj4g c3RhZ2UgMi4zOiBidWlsZCB0b29scwo+ID4+Pj4gc3RhZ2UgMzogY3Jvc3MgdG9vbHMKPiA+Pj4+ IHN0YWdlIDQuMTogYnVpbGRpbmcgaW5jbHVkZXMKPiA+Pj4+IHN0YWdlIDQuMjogYnVpbGRpbmcg bGlicmFyaWVzCj4gPj4+PiBzdGFnZSA0LjM6IG1ha2UgZGVwZW5kZW5jaWVzCj4gPj4+PiBzdGFn ZSA0LjQ6IGJ1aWxkaW5nIGV2ZXJ5dGhpbmcKPiA+Pj4+IFdvcmxkIGJ1aWxkIGNvbXBsZXRlZCBv biBGcmkgT2N0IDMwIDA4OjQ2OjM1IFVUQyAyMDA5Cj4gPiBUQiAtLS0gMjAwOS0xMC0zMCAwODo0 NjozNSAtIGdlbmVyYXRpbmcgTElOVCBrZXJuZWwgY29uZmlnCj4gPiBUQiAtLS0gMjAwOS0xMC0z MCAwODo0NjozNSAtIGNkIC9zcmMvc3lzL3BjOTgvY29uZgo+ID4gVEIgLS0tIDIwMDktMTAtMzAg MDg6NDY6MzUgLSAvdXNyL2Jpbi9tYWtlIC1CIExJTlQKPiA+IFRCIC0tLSAyMDA5LTEwLTMwIDA4 OjQ2OjM2IC0gYnVpbGRpbmcgTElOVCBrZXJuZWwKPiA+IFRCIC0tLSAyMDA5LTEwLTMwIDA4OjQ2 OjM2IC0gTUFLRU9CSkRJUlBSRUZJWD0vb2JqCj4gPiBUQiAtLS0gMjAwOS0xMC0zMCAwODo0Njoz NiAtIFBBVEg9L3Vzci9iaW46L3Vzci9zYmluOi9iaW46L3NiaW4KPiA+IFRCIC0tLSAyMDA5LTEw LTMwIDA4OjQ2OjM2IC0gVEFSR0VUPXBjOTgKPiA+IFRCIC0tLSAyMDA5LTEwLTMwIDA4OjQ2OjM2 IC0gVEFSR0VUX0FSQ0g9aTM4Ngo+ID4gVEIgLS0tIDIwMDktMTAtMzAgMDg6NDY6MzYgLSBUWj1V VEMKPiA+IFRCIC0tLSAyMDA5LTEwLTMwIDA4OjQ2OjM2IC0gX19NQUtFX0NPTkY9L2Rldi9udWxs Cj4gPiBUQiAtLS0gMjAwOS0xMC0zMCAwODo0NjozNiAtIGNkIC9zcmMKPiA+IFRCIC0tLSAyMDA5 LTEwLTMwIDA4OjQ2OjM2IC0gL3Vzci9iaW4vbWFrZSAtQiBidWlsZGtlcm5lbCBLRVJOQ09ORj1M SU5UCj4gPj4+PiBLZXJuZWwgYnVpbGQgZm9yIExJTlQgc3RhcnRlZCBvbiBGcmkgT2N0IDMwIDA4 OjQ2OjM2IFVUQyAyMDA5Cj4gPj4+PiBzdGFnZSAxOiBjb25maWd1cmluZyB0aGUga2VybmVsCj4g Pj4+PiBzdGFnZSAyLjE6IGNsZWFuaW5nIHVwIHRoZSBvYmplY3QgdHJlZQo+ID4+Pj4gc3RhZ2Ug Mi4yOiByZWJ1aWxkaW5nIHRoZSBvYmplY3QgdHJlZQo+ID4+Pj4gc3RhZ2UgMi4zOiBidWlsZCB0 b29scwo+ID4+Pj4gc3RhZ2UgMy4xOiBtYWtpbmcgZGVwZW5kZW5jaWVzCj4gPiBbLi4uXQo+ID4g YXdrIC1mIC9zcmMvc3lzL3Rvb2xzL21ha2VvYmpvcHMuYXdrIC9zcmMvc3lzL29wZW5jcnlwdG8v Y3J5cHRvZGV2X2lmLm0gLWgKPiA+IGF3ayAtZiAvc3JjL3N5cy90b29scy9tYWtlb2Jqb3BzLmF3 ayAvc3JjL3N5cy9wY2kvYWdwX2lmLm0gLWgKPiA+IGF3ayAtZiAvc3JjL3N5cy90b29scy9tYWtl b2Jqb3BzLmF3ayAvc3JjL3N5cy9wYzk4L3BjOTgvY2FuYnVzX2lmLm0gLWgKPiA+IHJtIC1mIC5u ZXdkZXAKPiA+IC91c3IvYmluL21ha2UgLVYgQ0ZJTEVTIC1WIFNZU1RFTV9DRklMRVMgLVYgR0VO X0NGSUxFUyB8IKBNS0RFUF9DUFA9ImNjIC1FIiBDQz0iY2MiIHhhcmdzIG1rZGVwIC1hIC1mIC5u ZXdkZXAgLU8yIC1waXBlIC1mbm8tc3RyaWN0LWFsaWFzaW5nIKAtc3RkPWM5OSCgLVdhbGwgLVdy ZWR1bmRhbnQtZGVjbHMgLVduZXN0ZWQtZXh0ZXJucyAtV3N0cmljdC1wcm90b3R5cGVzIKAtV21p c3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVdpbmxpbmUgLVdjYXN0LXF1YWwgoC1X dW5kZWYgLVduby1wb2ludGVyLXNpZ24gLWZmb3JtYXQtZXh0ZW5zaW9ucyAtbm9zdGRpbmMgoC1J LiAtSS9zcmMvc3lzIC1JL3NyYy9zeXMvY29udHJpYi9hbHRxIC1JL3NyYy9zeXMvY29udHJpYi9p cGZpbHRlciAtSS9zcmMvc3lzL2NvbnRyaWIvcGYgLUkvc3JjL3N5cy9kZXYvYXRoIC1JL3NyYy9z eXMvZGV2L2F0aC9hdGhfaGFsIC1JL3NyYy9zeXMvY29udHJpYi9uZ2F0bSAtSS9zcmMvc3lzL2Rl di90d2EgLUkvc3JjL3N5cy9nbnUvZnMveGZzL0ZyZWVCU0QgLUkvc3JjL3N5cy9nbnUvZnMveGZz L0ZyZWVCU0Qvc3VwcG9ydCAtSS9zcmMvc3lzL2dudS9mcy94ZnMgLUkvc3JjL3N5cy9jb250cmli L29wZW5zb2xhcmlzL2NvbXBhdCAtSS9zcmMvc3lzL2Rldi9jeGdiIC1EX0tFUk5FTCAtREhBVkVf S0VSTkVMX09QVElPTl9IRUFERVJTIC1pbmNsdWRlIG9wdF9nbG9iYWwuaCAtZm5vLWNvbW1vbiAt ZmlubGluZS1saW1pdD04MDAwIC0tcGFyYW0gaW5saW5lLXVuaXQtZ3Jvd3RoPTEwMCAtLXBhcmFt IGxhcmdlLWZ1bmN0aW9uLWdyb3d0aD0xMDAwIC1ER1BST0YgLWZhbGlnbi1mdW5jdGlvbnM9MTYg LURHUFJPRjQgLURHVVBST0YgLWZuby1idWlsdGluIC1tbm8tYWxpZ24tbG9uZy1zdHJpbmdzIC1t cHJlZmVycmVkLXN0YWNrLWJvdW5kYXJ5PTIgoC1tbm8tbW14IC1tbm8tM2Rub3cgLW1uby1zc2Ug LW1uby1zc2UyIC1tbm8tc3NlMyAtZmZyZWVzdGFuZAo+ID4goGluZwo+ID4gL3NyYy9zeXMvaTM4 Ni9pMzg2L21wX21hY2hkZXAuYzo3NjoyNTogZXJyb3I6IG1hY2hpbmUvbWNhLmg6IE5vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnkKPiA+IC9zcmMvc3lzL2kzODYvaTM4Ni90cmFwLmM6OTM6MjU6IGVy cm9yOiBtYWNoaW5lL21jYS5oOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Cj4gPiBta2RlcDog Y29tcGlsZSBmYWlsZWQKPiAKPiBNRkMgcjE5MjEwNiA/CgpEb2gsIHllcy4gIFdpbGwgZml4IGl0 IGluIGEgYml0LgoKLS0gCkpvaG4gQmFsZHdpbgo= From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 20:09:02 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43CBF1065697; Fri, 30 Oct 2009 20:09:02 +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 B10AE8FC16; Fri, 30 Oct 2009 20:09:01 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPfk6kqDaFvK/2dsb2JhbADge4Q9BIFi X-IronPort-AV: E=Sophos;i="4.44,655,1249272000"; d="scan'208";a="51868984" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 30 Oct 2009 16:09:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id C9F1A109C2CF; Fri, 30 Oct 2009 16:09:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXlBgRckm0Tn; Fri, 30 Oct 2009 16:09:00 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 25BB2109C257; Fri, 30 Oct 2009 16:09:00 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n9UKGCP29254; Fri, 30 Oct 2009 16:16:13 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 30 Oct 2009 16:16:12 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Olaf Seibert In-Reply-To: <20091029135239.GX841@twoquid.cs.ru.nl> Message-ID: References: <20091027164159.GU841@twoquid.cs.ru.nl> <20091029135239.GX841@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dfr@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.0-RC1 NFS client timeout issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 20:09:02 -0000 On Thu, 29 Oct 2009, Olaf Seibert wrote: > > After writing, I realised that it is indeed perfectly allowed for the > client to send data. But since the server already sent its FIN, it can't > send anything more, not even an error message. So with that in mind, the > client shouldn't send anything any more either. > Here is what I am seeing without and with the patch. The client is a pretty recent FreeBSD-CURRENT (nfsv4-test) and the server Solaris10 (nfsv4-solaris). I don't get the 5 minute reconnect delay without the patch. I think the reason is that the resets (Rst's) "inspire" the FreeBSD-CURRENT TCP to do the new connection. (I don't remember seeing any RSTs in your tcpdump?) I deleted a few irrelevant lines (packets not between nfsv4-test and nfsv4-solaris), which is why the packet #s aren't contiguous. (and appologies for the long lines) Hopefully someone with TCP expertise will know if the RSTs are done correctly and whether or not your server should be generating them. After the patch things look fine to me. Hopefully your (and others) testing will go ok. Snoop trace without the patch (what FreeBSD-CURRENT will do now): 2 209.18617 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=699 S=2049 Fin Ack=1066292217 Seq=1580479914 Len=0 Win=49232 Options= 3 209.18645 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=699 Ack=1580479915 Seq=1066292217 Len=0 Win=16588 Options= 4 209.18656 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=699 Rst Ack=1580479915 Seq=1066292217 Len=0 Win=0 5 209.18662 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=699 Rst Ack=1580479915 Seq=1066292217 Len=0 Win=0 7 528.97250 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 8 528.97261 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=699 S=2049 Rst Seq=1580479915 Len=0 Win=0 9 528.97311 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=818 Syn Seq=3293207355 Len=0 Win=65535 Options= 10 528.97329 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=818 S=2049 Syn Ack=3293207356 Seq=1757551152 Len=0 Win=49232 Options= 11 528.97354 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=818 Ack=1757551153 Seq=3293207356 Len=0 Win=8326 Options= 12 528.97375 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 13 528.97382 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=818 Rst Ack=1757551153 Seq=3293207356 Len=0 Win=0 14 528.97439 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=818 S=2049 Ack=3293207488 Seq=1757551153 Len=0 Win=49100 Options= 15 528.97524 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca NFS R FSSTAT3 OK 16 529.07565 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=818 Ack=1757551325 Seq=3293207488 Len=0 Win=16588 Options= and what happens after the patch is applied: 6 1.35481 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 7 1.35516 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca NFS R FSSTAT3 OK 8 1.45564 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=651 Ack=2612339569 Seq=837212133 Len=0 Win=16588 Options= 9 361.34400 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=651 S=2049 Fin Ack=837212133 Seq=2612339569 Len=0 Win=49232 Options= 10 361.34434 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=651 Ack=2612339570 Seq=837212133 Len=0 Win=16588 Options= 11 361.34441 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=651 Rst Ack=2612339570 Seq=837212133 Len=0 Win=0 12 361.34447 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=651 Rst Ack=2612339570 Seq=837212133 Len=0 Win=0 14 501.80966 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=881 Syn Seq=1926848102 Len=0 Win=65535 Options= 15 501.80979 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=881 S=2049 Syn Ack=1926848103 Seq=2754679721 Len=0 Win=49232 Options= 16 501.81006 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=881 Ack=2754679722 Seq=1926848103 Len=0 Win=8326 Options= 17 501.81024 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 18 501.81089 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=881 S=2049 Ack=1926848235 Seq=2754679722 Len=0 Win=49100 Options= 19 501.81169 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca NFS R FSSTAT3 OK 20 501.91218 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=881 Ack=2754679894 Seq=1926848235 Len=0 Win=16588 Options= Anyone with TCP expertise have opinions on these? rick From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 20:35:54 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92E78106566B for ; Fri, 30 Oct 2009 20:35:54 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com [209.85.211.178]) by mx1.freebsd.org (Postfix) with ESMTP id 4368F8FC0C for ; Fri, 30 Oct 2009 20:35:54 +0000 (UTC) Received: by ywh8 with SMTP id 8so3146866ywh.3 for ; Fri, 30 Oct 2009 13:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=NM/VrEcrqeoaiEwCoK//b4g66Qe9JwFodc6daUV3HXE=; b=ekdFn3yTGDvMPqT/RjouF1Tv7qXegolzXaYyHNAJtkv9FmFcKJIgg/7pkzwFORaK0m nAsWw72iYkCll627mwdt8PfeKwI5mdpw5YL9EeOONb/YK3URDHvNayfdRXT6yW/Kq5t4 S3YT3kG8dmoHMdE/PywvTAMBGzbbIWLB40AdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=F141JvNAtYa+icQ98IMakhRbEXsG8plABMwq0/VcQXj74opOMe3woWhkBlV7oPmSNS V/3rQ3DlnM0rOyJgxyfXeVawoEEWg56qvtMXQFpNH2AF9Ty1vGnF3BDiwslq5d4NIUAc VnxPzTDckAxzW9pPp7JceA/ahkNRMBACKGwFc= Received: by 10.150.172.38 with SMTP id u38mr3769297ybe.328.1256934953735; Fri, 30 Oct 2009 13:35:53 -0700 (PDT) Received: from ppp-23.242.dialinfree.com (ppp-23.242.dialinfree.com [209.172.23.242]) by mx.google.com with ESMTPS id 4sm1204394ywi.27.2009.10.30.13.35.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Oct 2009 13:35:50 -0700 (PDT) Sender: "J. Hellenthal" Date: Fri, 30 Oct 2009 16:35:35 -0400 From: jhell To: Tiago Araujo In-Reply-To: <4aeb2bec.e701be0a.771c.ffffa8bd@mx.google.com> Message-ID: References: <4aeb2bec.e701be0a.771c.ffffa8bd@mx.google.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Adding Me for Maillist (Freebsd) Please X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 20:35:54 -0000 On Fri, 30 Oct 2009 14:09, tiago.s.araujo@ wrote: > Dear, > > > > Please.... Add for me in mail list! > > > > Att, > > Tiago Araujo > > Manage Administrator > > > > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > All the info you need is right here: http://lists.freebsd.org/ -- Fri Oct 30 16:35:10 2009 -0500 jhell From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 21:40:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF806106568D for ; Fri, 30 Oct 2009 21:40:55 +0000 (UTC) (envelope-from meme.myydmm3fg42ggnbqgaztqzbrha2tkmlfhazgcojvha2tmojwmu3q-freebsd-stable=freebsd.org@returns.bulk.yahoo.com) Received: from n2.bullet.mail.ac4.yahoo.com (n2.bullet.mail.ac4.yahoo.com [76.13.13.30]) by mx1.freebsd.org (Postfix) with SMTP id 838688FC16 for ; Fri, 30 Oct 2009 21:40:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1256938090; bh=v8chudIfQ/TAkWgoOt4TEmlJqbBa31rwG1rfa7lzWOE=; h=Received:Received:Date:Received:From:To:Subject:X-Yahoo-Newman-Property:Content-Type; b=iebi0rTOjB6srb3AllPdmAD2VBOo05TdfsLhVZYJ4P0OMi49RzPg+vB0bfQXbAp/GXUe6/6ayKH+jS/aQoAo+ePYyLoprgJekAMH1J6rJFqmYxRsrSCskN8wqb8sSkvUjgbxAoRtGYBQL+YwFvfQ6ww87zokbbyY/altzyXJylg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; b=c5itglZpPdmyuxcsGHBAvoM7lwBzul6dMmAE1v/MbkFRAMY3ID1bhs5gbKiNyQeYkcFItlD/qR5UQgo/XaBoTPYlPTx4YcmWxEq29YCjCIX7fH0wq5Qdnrs36Dkkb8V2tsfafy6pakmlOAThynk7ehCFbmpNLNWg+1YtN56JzSc=; Received: from [76.13.13.25] by n2.bullet.mail.ac4.yahoo.com with NNFMP; 30 Oct 2009 21:28:10 -0000 Received: from [67.195.182.48] by t4.bullet.mail.ac4.yahoo.com with NNFMP; 30 Oct 2009 21:28:10 -0000 Date: 30 Oct 2009 14:28:10 -0700 Received: from [127.0.0.1] by fe3.goodstuff.latam.ac4.yahoo.com with NNFMP; 30 Oct 2009 21:28:10 -0000 From: meme@yahoo-inc.com To: freebsd-stable@freebsd.org X-Yahoo-Newman-Property: meme Content-Type: text/plain; charset=utf-8 Message-Id: <20091030214055.EF806106568D@hub.freebsd.org> Subject: =?utf-8?q?Voc=C3=AA_foi_convidado_para_usar_o_Meme?= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 21:40:56 -0000 Olá, freebsd-stable@freebsd.org! Template Para Todos te convidou para usar o Meme. Ele é o seu espaço para compartilhar com o mundo tudo o que você encontrar de interessante. O Meme ainda está em desenvolvimento e adoraríamos a sua colaboração para construí-lo junto com a gente. Use o endereço abaixo para receber seu convite: http://meme.yahoo.com/invited/ Depois de se inscrever, confira o meme de Template Para Todos: http://meme.yahoo.com/templateparatodos/ Nos vemos lá, Meme, do Yahoo! http://meme.yahoo.com From owner-freebsd-stable@FreeBSD.ORG Sat Oct 31 01:23:52 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9F49106566C for ; Sat, 31 Oct 2009 01:23:52 +0000 (UTC) (envelope-from npapke@acm.org) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 73F0D8FC16 for ; Sat, 31 Oct 2009 01:23:52 +0000 (UTC) Received: from pd2ml2so-ssvc.prod.shaw.ca ([10.0.141.134]) by pd2mo1so-svcs.prod.shaw.ca with ESMTP; 30 Oct 2009 19:23:51 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=68cLX4VTzOUA:10 a=VF9RaR9bft6c8SsOr3WyFg==:17 a=N54-gffFAAAA:8 a=lvbMJxvVAAAA:8 a=luTzMvsUMoM8qbpgfkcA:9 a=bHt9PIIbL7lkM9c0MP4A:7 a=8D6RPzWrqAFcrZqetdMTuii3u5oA:4 a=nAPXUAfsBmEA:10 a=nEbC6mTbn5IriWlR:21 a=_YDlBiBXMnYkrC6v:21 Received: from unknown (HELO proven.lan) ([24.85.241.34]) by pd2ml2so-dmz.prod.shaw.ca with ESMTP; 30 Oct 2009 19:23:51 -0600 Received: from proven.lan (localhost [127.0.0.1]) by proven.lan (8.14.3/8.14.3) with ESMTP id n9V1Npwx024621; Fri, 30 Oct 2009 18:23:51 -0700 (PDT) (envelope-from npapke@acm.org) Received: from localhost (localhost [[UNIX: localhost]]) by proven.lan (8.14.3/8.14.3/Submit) id n9V1NpNs024620; Fri, 30 Oct 2009 18:23:51 -0700 (PDT) (envelope-from npapke@acm.org) X-Authentication-Warning: proven.lan: npapke set sender to npapke@acm.org using -f From: Norbert Papke Organization: Archaeological Filing To: pyunyh@gmail.com, freebsd-stable@freebsd.org Date: Fri, 30 Oct 2009 18:23:51 -0700 User-Agent: KMail/1.9.10 References: <200910292156.19845.npapke@acm.org> <20091030165451.GA17243@michelle.cdnetworks.com> In-Reply-To: <20091030165451.GA17243@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910301823.51274.npapke@acm.org> Cc: Subject: Re: 7.2 Stable Crash - possibly related to if_re X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 01:23:52 -0000 On October 30, 2009, Pyun YongHyeon wrote: > On Thu, Oct 29, 2009 at 09:56:19PM -0700, Norbert Papke wrote: > > This occurred shortly after "scp"ing from a VirtualBox VM to the host. > > The file transfer got stuck. The "re" interface stopped working. > > Shortly afterwards, the host crashed. The "re" interface was used by the > > host, the guest was using a different NIC in bridged mode. > > > > > > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct 29 > > 18:36:57 PDT 2009 > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x18 > > It looks like a NULL pointer dereference, possibly mbuf related > one. > > > fault code = supervisor write data, page not present > > instruction pointer = 0x8:0xffffffff80d476ee > > stack pointer = 0x10:0xffffff8000078ae0 > > frame pointer = 0x10:0xffffff8000078b40 > > 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 = 18 (swi5: +) > > Physical memory: 8177 MB > > > > > > #9 0xffffffff807e710e in calltrap () > > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:218 > > #10 0xffffffff80d476ee in re_rxeof () from /boot/kernel/if_re.ko > > Hmm, I think there is a missing information here. Not sure where it > dereferenced a NULL pointer in re_rxeof(). >> #11 0xffffffff80d4a481 in re_int_task (arg=Variable "arg" is not available. >> ) >> at /usr/public/freebsd/sources/stable/sys/modules/re/../../dev/re/if_re.c:2191 I am not sure how much I trust frame 10. The instruction at "0xffffffff80d476ee" is the one after the "retq" from re_rxeof(). Frame 11 seems OK to me. The "struct rl_softc*", in particular, looks plausible but I don't know enough to say for sure. > Because that this is the > first report for NULL pointer dereference in Rx handler I need more > information how to reproduce it with minimal configuration. Can you > also reproduce the issues without virtual box? I am trying but no luck so far. > By chance, did you stop the re0 interface with ifconfig when you > noticed the file transfer got stuck? It is possible. I had it happen twice. The first time I definitely tried to "down" re. I cannot recall what I did the second time. The crash dump is from the second time. Thanks very much for the response. I'll try to come up with a better test case. If I succeed, I will report back. Cheers, -- Norbert Papke. npapke@acm.org http://saveournet.ca Protecting your Internet's level playing field From owner-freebsd-stable@FreeBSD.ORG Sat Oct 31 09:16:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97D30106566C; Sat, 31 Oct 2009 09:16:35 +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 4964A8FC0C; Sat, 31 Oct 2009 09:16:35 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1N4A4U-000Ay9-Kc; Sat, 31 Oct 2009 11:16:30 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Rick Macklem In-reply-to: References: <20091027164159.GU841@twoquid.cs.ru.nl> Comments: In-reply-to Rick Macklem message dated "Wed, 28 Oct 2009 16:38:27 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 31 Oct 2009 11:16:30 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org, dfr@freebsd.org, freebsd-current@freebsd.org, Olaf Seibert Subject: Re: 8.0-RC1 NFS client timeout issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 09:16:35 -0000 > > First off, I know that cross posting is evil, but I wanted to try > and make sure developers saw it. > > On Tue, 27 Oct 2009, Olaf Seibert wrote: > > > I see an annoying behaviour with NFS over TCP. It happens both with nfs > > and newnfs. This is with FreeBSD/amd64 8.0-RC1 as client. The server is > > some Linux or perhaps Solaris, I'm not entirely sure. > > > > After trying to find something in packet traces, I think I have found > > something. > > > > The scenario seems to be as follows. Sorry for the width of the lines. > > > > > > No. Time Source Destination Protocol Info > > 2296 2992.216855 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2297), DH:0x3819da36/w > > 2297 2992.217107 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2296) Error:NFS3ERR_NOENT > > 2298 2992.217141 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2299), DH:0x170cb16a/bin > > 2299 2992.217334 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2298), FH:0x61b8eb12 > > 2300 2992.217361 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call (Reply In 2301), FH:0x61b8eb12 > > 2301 2992.217582 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 ACCESS Reply (Call In 2300) > > 2302 2992.217605 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2303), DH:0x61b8eb12/w > > 2303 2992.217860 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2302) Error:NFS3ERR_NOENT > > 2304 2992.318770 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238293 Ack=230289 Win=8192 Len=0 TSV=86492342 TSER=12393434 > > 2306 3011.537520 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 GETATTR Reply (Call In 2305) Directory mode:2755 uid:4100 gid:4100 > > 2307 3011.637744 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230405 Win=8192 Len=0 TSV=86511662 TSER=12395366 > > 2308 3371.534980 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [FIN, ACK] Seq=230405 Ack=238429 Win=49232 Len=0 TSV=12431366 TSER=86511662 > > > > The server decides, for whatever reason, to terminate the > > connection and sends a FIN. > > > > 2309 3371.535018 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230406 Win=8192 Len=0 TSV=86871578 TSER=12431366 > > > > Client acknowledges this, > > > > 2310 3375.379693 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call, FH:0x008002a2 > > > > but tries to sneak in another call anyway. [A] > > > Probably not the best behaviour, but I think it is technically allowed by > TCP. (My TCP is very rusty, but I think the socket should be in > TCPS_CLOSE_WAIT at this point and the BSD code will have called > socantrcvmore(), but not socantsndmore().) > > > 2311 3375.474788 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [ACK] Seq=230406 Ack=238569 Win=49232 Len=0 TSV=12431760 TSER=86875423 > > > > Server ACKs but doesn't send anything else... [B] > > > > Time passes... > > > This is where it seems interesting. It looks to me like the socket upcall > for receiving the FIN would have happened before this point, setting the > ct_error.re_status to RPC_CANTRECV, but the code in clnt_vc_call() doesn't > check for this. (It does check for it happening during and after the > sosend(), but not before it, from what I can see.) > > > > > [B] would be a bug of the server in my opinion. If it ACKs a call, it > > should send a reply. And if it can't, it shouldn't. > > > I'll leave this one for the TCP wizzards. I'm not sure what the > correct behaviour is when data is received on a connection. (I think > it is waiting for a FIN from the client side at this point.) > > If you could try the following patch and see if it helps, that would be > appreciated, rick > ps: I'll try to reproduce the situation here, but I'm not sure if I can. > --- rpc/clnt_vc.c.sav 2009-10-28 15:44:20.000000000 -0400 > +++ rpc/clnt_vc.c 2009-10-28 15:49:57.000000000 -0400 > @@ -413,6 +413,19 @@ > > cr->cr_xid = xid; > mtx_lock(&ct->ct_lock); > + /* > + * Check to see if the other end has already started to close down > + * the connection. If it happens after this point, it will be > + * detected below, when cr->cr_error is checked. > + */ > + if (ct->ct_error.re_status == RPC_CANTRECV) { > + if (errp != &ct->ct_error) { > + errp->re_errno = ct->ct_error.re_errno; > + errp->re_status = RPC_CANTRECV; > + } > + stat = RPC_CANTRECV; > + goto out; > + } > TAILQ_INSERT_TAIL(&ct->ct_pending, cr, cr_link); > mtx_unlock(&ct->ct_lock); Did a make buildworld -j8, using as server netapp, freebsd, and all seems ok. danny From owner-freebsd-stable@FreeBSD.ORG Sat Oct 31 13:14:37 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DE0E1065670 for ; Sat, 31 Oct 2009 13:14:37 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from springbank.echomania.com (andric.com [IPv6:2001:888:2003:1001:230:48ff:fe51:76b6]) by mx1.freebsd.org (Postfix) with ESMTP id 1972E8FC08 for ; Sat, 31 Oct 2009 13:14:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by springbank.echomania.com (Postfix) with ESMTP id 61269A70D4 for ; Sat, 31 Oct 2009 14:14:35 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from springbank.echomania.com ([127.0.0.1]) by localhost (springbank.echomania.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cjRkG0oIya+c for ; Sat, 31 Oct 2009 14:14:09 +0100 (CET) Received: from [192.168.0.6] (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id 46076A7085 for ; Sat, 31 Oct 2009 14:14:09 +0100 (CET) Message-ID: <4AEC3823.9000204@andric.com> Date: Sat, 31 Oct 2009 14:14:11 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.5pre) Gecko/20091027 Shredder/3.0pre MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Console has no name? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 13:14:37 -0000 Hi, Somewhere between r198312 and r198702 I started getting this message during boot, on a machine using serial console: WARNING: console at 0xc093cea0 has no name This is just before the copyright banner of the kernel. Does anybody have an idea what might cause this, before I start digging? :) The machine has /boot.config with just "-P", and no console-related entries in /boot/loader.conf. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 31 14:54:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46E2A106566B; Sat, 31 Oct 2009 14:54:10 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from springbank.echomania.com (andric.com [IPv6:2001:888:2003:1001:230:48ff:fe51:76b6]) by mx1.freebsd.org (Postfix) with ESMTP id D56068FC18; Sat, 31 Oct 2009 14:54:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by springbank.echomania.com (Postfix) with ESMTP id 5F0D5A70D5; Sat, 31 Oct 2009 15:54:08 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from springbank.echomania.com ([127.0.0.1]) by localhost (springbank.echomania.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BH2zo4TAp9Ti; Sat, 31 Oct 2009 15:53:50 +0100 (CET) Received: from [192.168.0.6] (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id C9C3BA7085; Sat, 31 Oct 2009 15:53:50 +0100 (CET) Message-ID: <4AEC4F81.7010404@andric.com> Date: Sat, 31 Oct 2009 15:53:53 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.5pre) Gecko/20091027 Shredder/3.0pre MIME-Version: 1.0 To: freebsd-stable@freebsd.org, Andrew Thompson , Hans Petter Selasky References: <4AEC3823.9000204@andric.com> In-Reply-To: <4AEC3823.9000204@andric.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Console has no name? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 14:54:10 -0000 On 2009-10-31 14:14, Dimitry Andric wrote: > Somewhere between r198312 and r198702 I started getting this message > during boot, on a machine using serial console: > > WARNING: console at 0xc093cea0 has no name Okay, this seems to be caused by r198655, which is an MFC of r197570, where experimental support for USB serial console was added. However, the consdev::cn_name field is never initialized in usb_serial.c, whereas this does happen in other console drivers. There doesn't seem to be a consensus whether this field needs to be initialized in the _cnprobe() or _cninit() functions: I count 9 instances of initialization in the former, and 3 in the latter. Is there a preferred way? Since _cnprobe seems more popular, I propose the following fix: Index: sys/dev/usb/serial/usb_serial.c =================================================================== --- sys/dev/usb/serial/usb_serial.c (revision 198702) +++ sys/dev/usb/serial/usb_serial.c (working copy) @@ -1301,6 +1301,7 @@ static void ucom_cnprobe(struct consdev *cp) { cp->cn_pri = CN_NORMAL; + strlcpy(cp->cn_name, "ucom", sizeof cp->cn_name); } static void From owner-freebsd-stable@FreeBSD.ORG Sat Oct 31 15:30:22 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F03381065695 for ; Sat, 31 Oct 2009 15:30:22 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by mx1.freebsd.org (Postfix) with ESMTP id 8C00C8FC13 for ; Sat, 31 Oct 2009 15:30:21 +0000 (UTC) Received: by ewy5 with SMTP id 5so355714ewy.36 for ; Sat, 31 Oct 2009 08:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=TWJFHivQ9YDpsd9/5HeR4JA9XUImlPPcp8cwdCu4IWQ=; b=iwG13T004isvpcJvXepZe8ZU/syvCDg9nIqaUslSTmhyQ3b7tBDGDyYttUNHzoQ3PD EW9hMdQ8vAb2AEy5f9PKJJcf/BS79t5PomvGCRURP8LJb7E/axTigEBHFDrjImh7W3p/ MnCgsPvXAjtvPbRI3FfTrk4JLFdsN2VC1U/b4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=GzlGdgF6TvfFY+Q5LDeH3MyZgzv89uiiehTekR+Y3y5MGvEMqvfRHByouOZlGSYwrp 4Jg6YSoGSqmlv6ZFPoq3WzRxNJfeIrgqALRBiUmMh+tZFxs3/1jV0ACuh038ojqoNxeK gNstBu1bgRr5hVUOYQbwM21Kh5DLqcLeamhrI= MIME-Version: 1.0 Received: by 10.216.90.135 with SMTP id e7mr1824276wef.34.1257003021147; Sat, 31 Oct 2009 08:30:21 -0700 (PDT) From: Ivan Voras Date: Sat, 31 Oct 2009 16:30:01 +0100 Message-ID: <9bbcef730910310830s43237918g1489beb1fe9fae9a@mail.gmail.com> To: stable@freebsd.org, hardware@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: hostapd "deauthenticated due to local deauth request" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 15:30:23 -0000 I'm trying to setup an AP with a run0 interface on latest 8-STABLE but apparently 802.11 association fails: Oct 31 16:21:30 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE 802.11: associated Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE 802.11: deauthenticated due to local deauth request Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE 802.11: deassociated Oct 31 16:21:35 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE 802.11: associated Oct 31 16:21:38 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE 802.11: deauthenticated due to local deauth request Oct 31 16:21:38 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE 802.11: deassociated etc. Apparently the client never comes to the phase to receive DHCP address. The client in this case is WinXP and the setup did work with 7-STABLE, though with a bug in the rum driver which caused regular kernel panics on the AP. The devices are configured like this: rum0: flags=8843 metric 0 mtu 2290 ether 00:1c:f0:9d:08:b3 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running wlan0: flags=8943 metric 0 mtu 1500 ether 00:1c:f0:9d:08:b3 inet6 fe80::21c:f0ff:fe9d:8b3%wlan0 prefixlen 64 scopeid 0x6 inet 10.0.0.3 netmask 0xffffff00 broadcast 10.0.0.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid Cosmos channel 1 (2412 Mhz 11g) bssid 00:1c:f0:9d:08:b3 country US authmode WPA privacy MIXED deftxkey 3 TKIP 2:128-bit TKIP 3:128-bit txpower 0 scanvalid 60 protmode CTS dtimperiod 1 -dfs hostapd.conf contains: interface=wlan0 debug=3 ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel ssid=Cosmos wpa=1 wpa_passphrase=something wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP Any ideas? From owner-freebsd-stable@FreeBSD.ORG Sat Oct 31 16:02:21 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 197951065676; Sat, 31 Oct 2009 16:02:21 +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 7073E8FC22; Sat, 31 Oct 2009 16:02:20 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=2PldK9wmHJJ6mci3NXsA:9 a=J__8NAfkS_pgn4Ze1EQA:7 a=LLhcVaZ8q_urkxE-X7pGQn-BXr4A: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.16) with ESMTPA id 268962717; Sat, 31 Oct 2009 17:02:18 +0100 From: Hans Petter Selasky To: Dimitry Andric , freebsd-stable@freebsd.org Date: Sat, 31 Oct 2009 17:03:30 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4AEC3823.9000204@andric.com> <200910311656.29159.hselasky@c2i.net> <4AEC5F14.2030905@andric.com> In-Reply-To: <4AEC5F14.2030905@andric.com> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910311703.31362.hselasky@c2i.net> Cc: Andrew Thompson Subject: Re: Console has no name? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 16:02:21 -0000 Hi, Your patch has been committed to USB P4: http://p4web.freebsd.org/chv.cgi?CH=170003 Thanks for reporting! --HPS From owner-freebsd-stable@FreeBSD.ORG Sat Oct 31 16:42:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D140106568F for ; Sat, 31 Oct 2009 16:42:25 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 300928FC0C for ; Sat, 31 Oct 2009 16:42:24 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=RI7NlYPrrqxai-UJNEMA:9 a=Q0WJdE86aX7CkBoouuwA:7 a=VSWCtUXUGdEcwsccAE3wcmrcC1kA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1317032551; Sat, 31 Oct 2009 16:42:22 +0100 From: Hans Petter Selasky To: Dimitry Andric Date: Sat, 31 Oct 2009 16:43:35 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4AEC3823.9000204@andric.com> <4AEC4F81.7010404@andric.com> In-Reply-To: <4AEC4F81.7010404@andric.com> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910311643.36862.hselasky@c2i.net> Cc: freebsd-stable@freebsd.org, Andrew Thompson Subject: Re: Console has no name? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 16:42:25 -0000 On Saturday 31 October 2009 15:53:53 Dimitry Andric wrote: > On 2009-10-31 14:14, Dimitry Andric wrote: > > Somewhere between r198312 and r198702 I started getting this message > > during boot, on a machine using serial console: > > > > WARNING: console at 0xc093cea0 has no name > > Okay, this seems to be caused by r198655, which is an MFC of r197570, > where experimental support for USB serial console was added. > > However, the consdev::cn_name field is never initialized in > usb_serial.c, whereas this does happen in other console drivers. > > There doesn't seem to be a consensus whether this field needs to be > initialized in the _cnprobe() or _cninit() functions: I count 9 instances > of initialization in the former, and 3 in the latter. Is there a > preferred way? > > Since _cnprobe seems more popular, I propose the following fix: > > Index: sys/dev/usb/serial/usb_serial.c > =================================================================== > --- sys/dev/usb/serial/usb_serial.c (revision 198702) > +++ sys/dev/usb/serial/usb_serial.c (working copy) > @@ -1301,6 +1301,7 @@ static void > ucom_cnprobe(struct consdev *cp) > { > cp->cn_pri = CN_NORMAL; > + strlcpy(cp->cn_name, "ucom", sizeof cp->cn_name); > } > > static void Patch looks fine by me. --HPS From owner-freebsd-stable@FreeBSD.ORG Sat Oct 31 16:46:47 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C9211065670; Sat, 31 Oct 2009 16:46:47 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 6B22B8FC0A; Sat, 31 Oct 2009 16:46:46 +0000 (UTC) Received: by bwz5 with SMTP id 5so4762639bwz.3 for ; Sat, 31 Oct 2009 09:46:45 -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; bh=5TrI9ExvasXNhckC/rMrPeRWGd7dwSviLFEphesdNsI=; b=hHIb65kzGQVM8NsbZEZdu3PDEFldKZDSlVS7J5+DOL2tglnHqYSDN3t42KMYj9VVg/ YXsWgrKh19dfUU+bff5ks4qLrxbgxk++lfzWLXd4jPX69v6DI1cw4uNAF9RNdety2/X5 Pg4GHNS/NaohIiO2VQ1TQtKygR+so5VPAE0Pc= 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; b=YJP4TssJUW94kYqMyYlDZzNRhBjoKj/FnVp92xKN4W2ujaOyNNDoq3atwyFQDL1141 A0RF4BINREb5/IfSIOdiKI61NZf5wOeiMZc8xTelK4J6QND7crqBvt3aCCwkJZpieXK/ jOpie3a27YDpTKcII3W6fu+9Qe9xG/xEJUzcs= MIME-Version: 1.0 Received: by 10.103.81.21 with SMTP id i21mr1212519mul.57.1257005816637; Sat, 31 Oct 2009 09:16:56 -0700 (PDT) In-Reply-To: <9bbcef730910310830s43237918g1489beb1fe9fae9a@mail.gmail.com> References: <9bbcef730910310830s43237918g1489beb1fe9fae9a@mail.gmail.com> Date: Sat, 31 Oct 2009 17:16:56 +0100 Message-ID: <3a142e750910310916labe85e5ke804386a834c49c8@mail.gmail.com> From: Paul B Mahol To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, hardware@freebsd.org Subject: Re: hostapd "deauthenticated due to local deauth request" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 16:46:47 -0000 On 10/31/09, Ivan Voras wrote: > I'm trying to setup an AP with a run0 interface on latest 8-STABLE but > apparently 802.11 association fails: > > Oct 31 16:21:30 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE > 802.11: associated > Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE > 802.11: deauthenticated due to local deauth request > Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE > 802.11: deassociated > Oct 31 16:21:35 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE > 802.11: associated > Oct 31 16:21:38 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE > 802.11: deauthenticated due to local deauth request > Oct 31 16:21:38 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE > 802.11: deassociated > > etc. Apparently the client never comes to the phase to receive DHCP address. > > The client in this case is WinXP and the setup did work with 7-STABLE, > though with a bug in the rum driver which caused regular kernel panics > on the AP. > I tried same one with rum(4) as AP and ndis(4) as client on same machine(some version of 8.0 - CURRENT). ndis client (configured via wpa_supplicant) would keep auth and deauth all the time. I came to conclusion that rum is broken. But I think I remmember that bwi(4) (as a client) did not have such problem ... (I will test again to see) From owner-freebsd-stable@FreeBSD.ORG Sat Oct 31 18:54:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8585C106566C for ; Sat, 31 Oct 2009 18:54:23 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8118FC19 for ; Sat, 31 Oct 2009 18:54:22 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so251075fgg.13 for ; Sat, 31 Oct 2009 11:54:21 -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=bkr3PdSllCy7Q8LZqtSyMYqxg6ykMECCdm2Vur+6GQw=; b=OUYHxpq1G1yppQd9xWqSMbZ8WVONlc9flOqG38Srr4gAxXCQ5X26NHMYxLmGxD76cJ vYxoNDTpygIwubpM15uzx0M5c29CbfPQkWhlUodb+qsF9LjTaBFEXhdIqLs08PEeOtb2 ILvgW8DBqKON6DRDG2ZlX4RZqvuQngyuyeJZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZBJcaS/AgQ2GsRWlXKZ/ffYD1j67xl1SDVZc4hTqNmlCn/boKkNw5ZALV0xhODg5k5 v4xrZPFms9LXSAwi3IW1Wx+JBaQnhebJGpU5kF/oKfdILVCbOf4aPdjyTT+qtDmDuFHz 3yWz4Gpfn708BgJ8jq9APjo8CpPUB0yt5M/6s= MIME-Version: 1.0 Received: by 10.204.154.142 with SMTP id o14mr2376074bkw.125.1257015261627; Sat, 31 Oct 2009 11:54:21 -0700 (PDT) Date: Sat, 31 Oct 2009 19:54:21 +0100 Message-ID: <6101e8c40910311154j16125ffawd4d4f34e5ba50706@mail.gmail.com> From: Oliver Pinter To: freebsd-stable@freebsd.org, security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: CVE-2009-0689 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 18:54:23 -0000 Hello list! I have a small question from CVE-2009-0689[1]: The commit r197059 fixed this bug or not? On security lists its marked as high priority and find it at juni. some info: [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0689 [2] http://securityreason.com/achievement_securityalert/63 [3] http://seclists.org/fulldisclosure/2009/Oct/357 From owner-freebsd-stable@FreeBSD.ORG Sat Oct 31 21:21:05 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87C48106566C for ; Sat, 31 Oct 2009 21:21:05 +0000 (UTC) (envelope-from pyunyh@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 0238E8FC19 for ; Sat, 31 Oct 2009 21:21:04 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 9so867199qwb.7 for ; Sat, 31 Oct 2009 14:21:04 -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=ropD8+6aqx6jAkl7b9qhkLJv0vJ7X3KzU6wOmElI91s=; b=iYo3Gk0M4H3jkjoQAklbfSSY3xkiFL6cwpEeUdFJyM49vV3/Q2q68iGaKLfZGdkE6s 7VDxy5rd6KGRPeUu0FFBIooMpLQohvo6b1DBcthfH1UOfI54Lzre2Sah3oTppiAvevyI 1VRWSFhyiGbXN68wi9J6KrPrjDkp0VKJ6R5uI= 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=faQeeuuc3HBhY1owBnjenugAe2XZTqGRHmIMKHIKZYy/wcv5FlnJwVnFpF03p+uL4U Mq7jNVIwn9cuoN4X0I13Q1cfscVWk29nfNu5Xrjc76vlUB246IdSXW+jHkwbTqsAukEr Xfv1pFo+zx6dPchyNqhA+DYQtmyU602wYOvEg= Received: by 10.224.81.195 with SMTP id y3mr1878096qak.82.1257024064135; Sat, 31 Oct 2009 14:21:04 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 22sm3229402qyk.2.2009.10.31.14.21.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 31 Oct 2009 14:21:02 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sat, 31 Oct 2009 14:21:07 -0700 From: Pyun YongHyeon Date: Sat, 31 Oct 2009 14:21:07 -0700 To: Norbert Papke Message-ID: <20091031212107.GC17243@michelle.cdnetworks.com> References: <200910292156.19845.npapke@acm.org> <20091030165451.GA17243@michelle.cdnetworks.com> <200910301823.51274.npapke@acm.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <200910301823.51274.npapke@acm.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: 7.2 Stable Crash - possibly related to if_re X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 21:21:05 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Oct 30, 2009 at 06:23:51PM -0700, Norbert Papke wrote: > On October 30, 2009, Pyun YongHyeon wrote: > > On Thu, Oct 29, 2009 at 09:56:19PM -0700, Norbert Papke wrote: > > > This occurred shortly after "scp"ing from a VirtualBox VM to the host. > > > The file transfer got stuck. The "re" interface stopped working. > > > Shortly afterwards, the host crashed. The "re" interface was used by the > > > host, the guest was using a different NIC in bridged mode. > > > > > > > > > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct 29 > > > 18:36:57 PDT 2009 > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 0; apic id = 00 > > > fault virtual address = 0x18 > > > > It looks like a NULL pointer dereference, possibly mbuf related > > one. > > > > > fault code = supervisor write data, page not present > > > instruction pointer = 0x8:0xffffffff80d476ee > > > stack pointer = 0x10:0xffffff8000078ae0 > > > frame pointer = 0x10:0xffffff8000078b40 > > > 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 = 18 (swi5: +) > > > Physical memory: 8177 MB > > > > > > > > > > #9 0xffffffff807e710e in calltrap () > > > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:218 > > > #10 0xffffffff80d476ee in re_rxeof () from /boot/kernel/if_re.ko > > > > Hmm, I think there is a missing information here. Not sure where it > > dereferenced a NULL pointer in re_rxeof(). > > >> #11 0xffffffff80d4a481 in re_int_task (arg=Variable "arg" is not available. > >> ) > >> > at /usr/public/freebsd/sources/stable/sys/modules/re/../../dev/re/if_re.c:2191 > > I am not sure how much I trust frame 10. The instruction > at "0xffffffff80d476ee" is the one after the "retq" from re_rxeof(). Frame > 11 seems OK to me. The "struct rl_softc*", in particular, looks plausible > but I don't know enough to say for sure. > > > Because that this is the > > first report for NULL pointer dereference in Rx handler I need more > > information how to reproduce it with minimal configuration. Can you > > also reproduce the issues without virtual box? > > I am trying but no luck so far. > > > By chance, did you stop the re0 interface with ifconfig when you > > noticed the file transfer got stuck? > > It is possible. I had it happen twice. The first time I definitely tried > to "down" re. I cannot recall what I did the second time. The crash dump is > from the second time. > Ok, then would you try attached patch? --2oS5YaxWCcQjTEyO Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.rxeof.patch" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 198686) +++ sys/dev/re/if_re.c (working copy) @@ -1817,6 +1817,8 @@ for (i = sc->rl_ldata.rl_rx_prodidx; maxpkt > 0; i = RL_RX_DESC_NXT(sc, i)) { + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) + break; cur_rx = &sc->rl_ldata.rl_rx_list[i]; rxstat = le32toh(cur_rx->rl_cmdstat); if ((rxstat & RL_RDESC_STAT_OWN) != 0) --2oS5YaxWCcQjTEyO--