From owner-freebsd-stable@FreeBSD.ORG Sun Oct 31 05:59:51 2010 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 C5B0A106564A; Sun, 31 Oct 2010 05:59:51 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D5E918FC08; Sun, 31 Oct 2010 05:59:50 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id HAA29149; Sun, 31 Oct 2010 07:59:45 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PCQxE-000OpJ-RK; Sun, 31 Oct 2010 07:59:44 +0200 Message-ID: <4CCD05CF.8080301@icyb.net.ua> Date: Sun, 31 Oct 2010 07:59:43 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Kostik Belousov References: <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua> <20101030112520.GD79691@two.kliksys.ru> <4CCC2F2A.7020809@icyb.net.ua> <20101030233739.GE2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101030233739.GE2392@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Artemiev Igor Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 31 Oct 2010 05:59:51 -0000 on 31/10/2010 02:37 Kostik Belousov said the following: > On Sat, Oct 30, 2010 at 05:43:54PM +0300, Andriy Gapon wrote: >> on 30/10/2010 14:25 Artemiev Igor said the following: >>> On Sat, Oct 30, 2010 at 01:33:00PM +0300, Andriy Gapon wrote: >>>> on 30/10/2010 13:12 Artemiev Igor said the following: >>>>> On Sat, Oct 30, 2010 at 12:52:54PM +0300, Andriy Gapon wrote: >>>>> >>>>>> Heh, next try. >>>>> >>>>> Got a panic, "vm_page_unwire: invalid wire count: 0" >>>> >>>> Oh, thank you for testing - forgot another piece (VM_ALLOC_WIRE for vm_page_alloc): >>> >>> Yep, it work. But VM_ALLOC_WIRE not exists in RELENG_8, therefore i slightly modified your patch: >> >> I apologize for my haste, it should have been VM_ALLOC_WIRED. >> Here is a corrected patch: >> Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c >> =================================================================== >> --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 214318) >> +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working copy) >> @@ -67,6 +67,7 @@ >> #include >> #include >> #include >> +#include >> >> /* >> * Programming rules. >> @@ -464,7 +465,7 @@ >> uiomove_fromphys(&m, off, bytes, uio); >> VM_OBJECT_LOCK(obj); >> vm_page_wakeup(m); >> - } else if (m != NULL && uio->uio_segflg == UIO_NOCOPY) { >> + } else if (uio->uio_segflg == UIO_NOCOPY) { >> /* >> * The code below is here to make sendfile(2) work >> * correctly with ZFS. As pointed out by ups@ >> @@ -474,9 +475,23 @@ >> */ >> KASSERT(off == 0, >> ("unexpected offset in mappedread for sendfile")); >> - if (vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) >> + if (m != NULL && vm_page_sleep_if_busy(m, FALSE, "zfsmrb")) >> goto again; >> - vm_page_busy(m); >> + if (m == NULL) { >> + m = vm_page_alloc(obj, OFF_TO_IDX(start), >> + VM_ALLOC_NOBUSY | VM_ALLOC_WIRED | VM_ALLOC_NORMAL); >> + if (m == NULL) { >> + VM_OBJECT_UNLOCK(obj); >> + VM_WAIT; >> + VM_OBJECT_LOCK(obj); >> + goto again; >> + } >> + } else { >> + vm_page_lock_queues(); >> + vm_page_wire(m); >> + vm_page_unlock_queues(); >> + } >> + vm_page_io_start(m); > Why wiring the page if it is busied ? Eh? Because it is not? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sun Oct 31 06:09:14 2010 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 E5A9F1065673; Sun, 31 Oct 2010 06:09:14 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 049378FC12; Sun, 31 Oct 2010 06:09:13 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA29229; Sun, 31 Oct 2010 08:09:09 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PCR6K-000Opx-Rt; Sun, 31 Oct 2010 08:09:08 +0200 Message-ID: <4CCD0804.8010703@icyb.net.ua> Date: Sun, 31 Oct 2010 08:09:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Artemiev Igor References: <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua> <20101030112520.GD79691@two.kliksys.ru> <4CCC2F2A.7020809@icyb.net.ua> <20101030190120.GA80301@two.kliksys.ru> In-Reply-To: <20101030190120.GA80301@two.kliksys.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 31 Oct 2010 06:09:15 -0000 on 30/10/2010 22:01 Artemiev Igor said the following: > On Sat, Oct 30, 2010 at 05:43:54PM +0300, Andriy Gapon wrote: > >> I apologize for my haste, it should have been VM_ALLOC_WIRED. > > Ok, applied and tested under some load(~1200 active connections, outgoing > ~80MB/s). Patch work as expected and i has noted no side effects. Just one > question - should grow Active memory counter, if some pages is "hot"(during > multiple sendfile on one file)? Pages used by sendfile are marked as Inactive for faster reclamation on demand. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sun Oct 31 09:02:49 2010 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 DAAA4106566C; Sun, 31 Oct 2010 09:02:49 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8BB238FC19; Sun, 31 Oct 2010 09:02:47 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PCToL-0000tt-3X; Sun, 31 Oct 2010 12:02:45 +0300 From: "Alexander Zagrebin" To: "'Andriy Gapon'" References: <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua><4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org><4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua> <20101030112520.GD79691@two.kliksys.ru> <4CCC2F2A.7020809@icyb.net.ua><20101030190120.GA80301@two.kliksys.ru> <4CCD0804.8010703@icyb.net.ua> Date: Sun, 31 Oct 2010 12:02:44 +0300 Keywords: freebsd-fs Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <4CCD0804.8010703@icyb.net.ua> Thread-Index: Act4wku/wmVwJWj2TD2hR3M6uk44wAAEHgaA Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: RE: 8.1-STABLE: zfs and sendfile: problem still exists 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, 31 Oct 2010 09:02:49 -0000 > >> I apologize for my haste, it should have been VM_ALLOC_WIRED. > > > > Ok, applied and tested under some load(~1200 active > connections, outgoing > > ~80MB/s). Patch work as expected and i has noted no side > effects. Just one > > question - should grow Active memory counter, if some pages > is "hot"(during > > multiple sendfile on one file)? > > Pages used by sendfile are marked as Inactive for faster > reclamation on demand. I have a question. When we transfer a file via sendfile, then current code allocates a memory, marked inactive. For example, if the file has size 100 MB, then 100 MB of memory will be allocated. If we have to transfer this file again later, then this memory will used as cache, and no disk io will be required. The memory will be freed if file will be deleted or operating system will need an additional memory. I have correctly understood? If it so, the i continue... Such behaviour is good if we have files with relatively small size. Suppose we have to transfer file with large size (for example, greater than amount of physical memory). While transfering, the inactive memory will grow, pressing the ARC. When size of the ARC will fall to its minimum (vfs.zfs.arc_min), then inactive memory will be reused. So, when transfer is complete, we have: 1. No free memory 2. Size of the ARC has minimal size (it is bad) 3. Inactive memory contains the _tail_ of the file only (it is bad too) Now if we have to transfer this file again, then 1. there is no (or few) file's data in ARC (ARC too small) 2. The inactive memory doesn't contain a head part of the file So the file's data will read from a disk again and again... Also i've noticed that inactive memory frees relatively slowly, so if there is a frequent access to large files, then system will run at very unoptimal conditions. It's imho... Can you comment this? -- Alexander Zagrebin From owner-freebsd-stable@FreeBSD.ORG Sun Oct 31 09:47:23 2010 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 7B3FB1065670; Sun, 31 Oct 2010 09:47:23 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out2.tiscali.nl (smtp-out2.tiscali.nl [195.241.79.177]) by mx1.freebsd.org (Postfix) with ESMTP id 085F78FC0A; Sun, 31 Oct 2010 09:47:22 +0000 (UTC) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out2.tiscali.nl with esmtp (Exim) (envelope-from ) id 1PCUVV-0005qu-PV; Sun, 31 Oct 2010 10:47:21 +0100 Received: from 212-123-145-58.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 2FDE3E08D; Sun, 31 Oct 2010 10:47:14 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "'Andriy Gapon'" , "Alexander Zagrebin" References: <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua> <4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org> <4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua> <20101030112520.GD79691@two.kliksys.ru> <4CCC2F2A.7020809@icyb.net.ua> <20101030190120.GA80301@two.kliksys.ru> <4CCD0804.8010703@icyb.net.ua> Date: Sun, 31 Oct 2010 10:47:13 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/10.62 (FreeBSD) Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 31 Oct 2010 09:47:23 -0000 On Sun, 31 Oct 2010 10:02:44 +0100, Alexander Zagrebin =20 wrote: >> >> I apologize for my haste, it should have been VM_ALLOC_WIRED. >> > >> > Ok, applied and tested under some load(~1200 active >> connections, outgoing >> > ~80MB/s). Patch work as expected and i has noted no side >> effects. Just one >> > question - should grow Active memory counter, if some pages >> is "hot"(during >> > multiple sendfile on one file)? >> >> Pages used by sendfile are marked as Inactive for faster >> reclamation on demand. > > I have a question. > When we transfer a file via sendfile, then current code allocates > a memory, marked inactive. For example, if the file has size 100 MB, > then 100 MB of memory will be allocated. > If we have to transfer this file again later, then this memory will use= d > as cache, and no disk io will be required. > The memory will be freed if file will be deleted or operating system > will need an additional memory. > I have correctly understood? > If it so, the i continue... > Such behaviour is good if we have files with relatively small size. > Suppose we have to transfer file with large size (for example, greater > than amount of physical memory). > While transfering, the inactive memory will grow, pressing the ARC. > When size of the ARC will fall to its minimum (vfs.zfs.arc_min), then > inactive memory will be reused. > So, when transfer is complete, we have: > 1. No free memory > 2. Size of the ARC has minimal size (it is bad) > 3. Inactive memory contains the _tail_ of the file only (it is bad too) > Now if we have to transfer this file again, then > 1. there is no (or few) file's data in ARC (ARC too small) > 2. The inactive memory doesn't contain a head part of the file > So the file's data will read from a disk again and again... > Also i've noticed that inactive memory frees relatively slowly, > so if there is a frequent access to large files, then system will run > at very unoptimal conditions. > It's imho... > Can you comment this? > Add more RAM? From owner-freebsd-stable@FreeBSD.ORG Sun Oct 31 14:29:50 2010 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 4D9F7106564A for ; Sun, 31 Oct 2010 14:29:50 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 0ACFF8FC08 for ; Sun, 31 Oct 2010 14:29:49 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o9VDpKj7030820 for ; Sun, 31 Oct 2010 06:51:20 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o9VDpKeN030819 for stable@freebsd.org; Sun, 31 Oct 2010 06:51:20 -0700 (PDT) (envelope-from david) Date: Sun, 31 Oct 2010 06:51:20 -0700 From: David Wolfskill To: stable@freebsd.org Message-ID: <20101031135120.GC26123@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , stable@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TiqCXmo5T1hvSQQg" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: option DDB broken between r214547 - r214596 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, 31 Oct 2010 14:29:50 -0000 --TiqCXmo5T1hvSQQg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On one of my machines, I've been having some issues such that I adjusted the kernel config to include some debugging options: options KDB options KDB_TRACE options KDB_UNATTENDED options DDB options DDB_NUMSYM options GDB options DEBUG_REDZONE Now, I actually build for the system in question on my build machine (which builds a GENERIC kernel for itself, as well as kernels for the above-mentioned machine and another). This morning, it was running FreeBSD 8.1-STABLE r214547, building 8.1-STABLE r214596. The GENERIC build succeeded, and went on to the kernel "ALBERT". That failed, thus: =2E.. >>> stage 3.2: building everything =2E.. cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wst= rict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual = -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sy= s -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inclu= de opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growt= h=3D100 --param large-function-growth=3D1000 -mno-align-long-strings -mpre= ferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3= -ffreestanding -fstack-protector -Werror /usr/src/sys/net/if_debug.c /usr/src/sys/net/if_debug.c: In function 'if_show_ifnet': /usr/src/sys/net/if_debug.c:65: error: 'struct ifnet' has no member named '= if_index_reserved' *** Error code 1 Stop in /common/S1/obj/usr/src/sys/ALBERT. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Commenting out the "DDB" option in the config avoided the failure. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --TiqCXmo5T1hvSQQg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzNdFcACgkQmprOCmdXAD2j9ACdFS0V/yQNyyoalxbXrwfpvKQO qXUAn3cMvQXkXou3QVYtxkhHvE7rW1bv =NDxE -----END PGP SIGNATURE----- --TiqCXmo5T1hvSQQg-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 31 16:15:08 2010 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 AA08F106564A for ; Sun, 31 Oct 2010 16:15:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 368D38FC28 for ; Sun, 31 Oct 2010 16:15:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 73F8941C752; Sun, 31 Oct 2010 17:15:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id OatVJfvIEeWw; Sun, 31 Oct 2010 17:15:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 9A07741C75A; Sun, 31 Oct 2010 17:15:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 59B094448F3; Sun, 31 Oct 2010 16:11:20 +0000 (UTC) Date: Sun, 31 Oct 2010 16:11:20 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: David Wolfskill In-Reply-To: <20101031135120.GC26123@albert.catwhisker.org> Message-ID: <20101031161031.C66242@maildrop.int.zabbadoz.net> References: <20101031135120.GC26123@albert.catwhisker.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@freebsd.org Subject: Re: option DDB broken between r214547 - r214596 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, 31 Oct 2010 16:15:08 -0000 On Sun, 31 Oct 2010, David Wolfskill wrote: Hi, > On one of my machines, I've been having some issues such that I adjusted > the kernel config to include some debugging options: > > options KDB > options KDB_TRACE > options KDB_UNATTENDED > options DDB > options DDB_NUMSYM > options GDB > options DEBUG_REDZONE > > Now, I actually build for the system in question on my build machine > (which builds a GENERIC kernel for itself, as well as kernels for the > above-mentioned machine and another). > > This morning, it was running FreeBSD 8.1-STABLE r214547, building > 8.1-STABLE r214596. The GENERIC build succeeded, and went on to the > kernel "ALBERT". > > That failed, thus: > > ... >>>> stage 3.2: building everything > ... > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/net/if_debug.c > /usr/src/sys/net/if_debug.c: In function 'if_show_ifnet': > /usr/src/sys/net/if_debug.c:65: error: 'struct ifnet' has no member named 'if_index_reserved' > *** Error code 1 That would be mine though a universe had successfully completed with the merge. I'll go and look. /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-stable@FreeBSD.ORG Sun Oct 31 17:00:07 2010 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 61773106564A for ; Sun, 31 Oct 2010 17:00:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 0BE878FC17 for ; Sun, 31 Oct 2010 17:00:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 574BF41C758; Sun, 31 Oct 2010 18:00:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id YGRz3wHXQirz; Sun, 31 Oct 2010 18:00:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id EB63A41C75E; Sun, 31 Oct 2010 18:00:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 606E04448F3; Sun, 31 Oct 2010 16:57:42 +0000 (UTC) Date: Sun, 31 Oct 2010 16:57:42 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: David Wolfskill In-Reply-To: <20101031161031.C66242@maildrop.int.zabbadoz.net> Message-ID: <20101031165516.A66242@maildrop.int.zabbadoz.net> References: <20101031135120.GC26123@albert.catwhisker.org> <20101031161031.C66242@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@freebsd.org Subject: Re: option DDB broken between r214547 - r214596 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, 31 Oct 2010 17:00:07 -0000 On Sun, 31 Oct 2010, Bjoern A. Zeeb wrote: Hi David, >> Now, I actually build for the system in question on my build machine >> (which builds a GENERIC kernel for itself, as well as kernels for the >> above-mentioned machine and another). >> >> This morning, it was running FreeBSD 8.1-STABLE r214547, building >> 8.1-STABLE r214596. The GENERIC build succeeded, and went on to the >> kernel "ALBERT". >> >> That failed, thus: ... >> /usr/src/sys/net/if_debug.c >> /usr/src/sys/net/if_debug.c: In function 'if_show_ifnet': >> /usr/src/sys/net/if_debug.c:65: error: 'struct ifnet' has no member named >> 'if_index_reserved' >> *** Error code 1 > > That would be mine though a universe had successfully completed with > the merge. > > I'll go and look. I still had the stable/8 LINT + 4 more different LINT configs all including DDB build logs form yesterday on ref8; none had an error though it was obviously there. I have no clue but that a KERNFAST build might not have cought it if this wasn't my first change to build test. It should be fixed with r214602. Thanks a lot for the report. /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-stable@FreeBSD.ORG Sun Oct 31 17:33:45 2010 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 E225A106566C for ; Sun, 31 Oct 2010 17:33:45 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 9D6D48FC0A for ; Sun, 31 Oct 2010 17:33:45 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o9VHXjFH002037; Sun, 31 Oct 2010 10:33:45 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o9VHXjaN002036; Sun, 31 Oct 2010 10:33:45 -0700 (PDT) (envelope-from david) Date: Sun, 31 Oct 2010 10:33:45 -0700 From: David Wolfskill To: "Bjoern A. Zeeb" Message-ID: <20101031173345.GD1506@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , "Bjoern A. Zeeb" , stable@FreeBSD.org References: <20101031135120.GC26123@albert.catwhisker.org> <20101031161031.C66242@maildrop.int.zabbadoz.net> <20101031165516.A66242@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3Pql8miugIZX0722" Content-Disposition: inline In-Reply-To: <20101031165516.A66242@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.4.2.3i Cc: stable@FreeBSD.org Subject: Re: option DDB broken between r214547 - r214596 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, 31 Oct 2010 17:33:46 -0000 --3Pql8miugIZX0722 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 31, 2010 at 04:57:42PM +0000, Bjoern A. Zeeb wrote: >... > ... > >>/usr/src/sys/net/if_debug.c > >>/usr/src/sys/net/if_debug.c: In function 'if_show_ifnet': > >>/usr/src/sys/net/if_debug.c:65: error: 'struct ifnet' has no member nam= ed=20 > >>'if_index_reserved' > >>*** Error code 1 > > > >That would be mine though a universe had successfully completed with > >the merge. > > > >I'll go and look. >=20 > I still had the stable/8 LINT + 4 more different LINT configs all > including DDB build logs form yesterday on ref8; none had an error > though it was obviously there. I have no clue but that a KERNFAST > build might not have cought it if this wasn't my first change to build > test. >=20 > It should be fixed with r214602. Thanks a lot for the report. Thanks -- sorry for the hassle. And that I was so preessed for time that I wasn't able to research it a bit first. In any case, I've reverted the change to the kernel config in question, applied the change from r214602, and rebuilt the kernels -- GENERIC, ALBERT, and JANUS -- that tyhe build machine normally builds, and all were successful. Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --3Pql8miugIZX0722 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzNqHgACgkQmprOCmdXAD1hGQCfT7YYp0NNh7b0OWpL74j1SOvN Oa0An2VZ77ALVHjfdFaTU5i2uwJWllvd =unXj -----END PGP SIGNATURE----- --3Pql8miugIZX0722-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 31 19:53:21 2010 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 A323210656A3 for ; Sun, 31 Oct 2010 19:53:21 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 414EE8FC1C for ; Sun, 31 Oct 2010 19:53:20 +0000 (UTC) Received: by vws12 with SMTP id 12so2849757vws.13 for ; Sun, 31 Oct 2010 12:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=P7VURlKWVumE7gLvyNXBmEGQtbSSJNN6SYh4w7Tpv7o=; b=njXe1lKxDOUCjEb3JnOsR9Mz0CbmTskQznzi9zoZz/HIFpmQknsdAjf1IRruPzP1Dv ADmJzQLn7YkVkh1AZMNSnqzOaS87mT/v9Qr3A+CLvQhy8Rb8YezEfJEy6IkpJ3zqG5K0 dfZtntHo/0dexWN5FXPG+bVj0zUEPTAkkNaQg= 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=VAoOe540oCXDE9mJKo9170olct9JOUo5tqtEucxLR9sdjgly/z3X7wGx7jLshc0m+n QWQptq2vtUcpMBCkDKg3VSMeIcHFyCOee5MkyuQq1dwGhCLR5jSJVquZ+nD3fR7YhuUT GB1tLBF380niXpMz0AZbvFEGA5A5q1fs4m490= MIME-Version: 1.0 Received: by 10.224.11.141 with SMTP id t13mr7158509qat.394.1288554800185; Sun, 31 Oct 2010 12:53:20 -0700 (PDT) Received: by 10.229.110.12 with HTTP; Sun, 31 Oct 2010 12:53:20 -0700 (PDT) In-Reply-To: References: Date: Sun, 31 Oct 2010 12:53:20 -0700 Message-ID: From: Rumen Telbizov To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Degraded zpool cannot detach old/bad drive 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, 31 Oct 2010 19:53:24 -0000 Hi Artem, everyone, Here's the latest update on my case. I did upgrade the system to the latest stable: 8.1-STABLE FreeBSD 8.1-STABLE #0: Sun Oct 31 11:44:06 PDT 2010 After that I did zpool upgrade and zfs upgrade -r all the filesystems. Currently I am running zpool 15 and zfs 4. Everything went fine with the upgrade but unfortunately my problem still persists. There's no difference in this aspect. I still have mfid devices. I also tried chmod-ing as you suggested /dev/mfid devices but zfs/zpool didn't seem to care and imported the array regardless. So at this point since no one else seems to have any ideas and we seem to be stuck I am almost ready to declare defeat on this one. Although the pool is usable I couldn't bring it back to exactly the same state as it was before the disk replacements took place. Disappointing indeed, although not a complete show stopper. I still think that if there's a way to edit the cache file and change the devices that might do the trick. Thanks for all the help, Rumen Telbizov On Fri, Oct 29, 2010 at 5:01 PM, Artem Belevich wrote: > On Fri, Oct 29, 2010 at 4:42 PM, Rumen Telbizov > wrote: > > FreeBSD 8.1-STABLE #0: Sun Sep 5 00:22:45 PDT 2010 > > That's when I csuped and rebuilt world/kernel. > > There were a lot of ZFS-related MFCs since then. I'd suggest updating > to the most recent -stable and try again. > > I've got another idea that may or may not work. Assuming that GPT > labels disappear because zpool opens one of the /dev/mfid* devices, > you can try to do "chmod a-rw /dev/mfid*" on them and then try > importing the pool again. > > --Artem > -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 03:34:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id BED761065670 for ; Mon, 1 Nov 2010 03:34:25 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 0D73914E062 for ; Mon, 1 Nov 2010 03:34:24 +0000 (UTC) Received: (qmail 6374 invoked from network); 1 Nov 2010 03:34:24 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 1 Nov 2010 03:34:24 -0000 Message-ID: <4CCE3540.5020903@freebsd.org> Date: Sun, 31 Oct 2010 20:34:24 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100803 Thunderbird/3.0.6 MIME-Version: 1.0 To: FreeBSD Stable , freebsd security X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: security-officer@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 03:34:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, On November 30th, FreeBSD 6.4 and FreeBSD 8.0 will have reached their End of Life and will no longer be supported by the FreeBSD Security Team. Since FreeBSD 6.4 is the last remaining supported release from the FreeBSD 6.x stable branch, support for the FreeBSD 6.x stable branch will also cease at the same point. Users of either of these FreeBSD releases are strongly encouraged to upgrade to either FreeBSD 7.3 or FreeBSD 8.1 before that date. The FreeBSD Ports Management Team wishes to remind users that November 30 is also the end of support for the Ports Collection for both FreeBSD 6.4 RELEASE and the FreeBSD 6.x STABLE branch. Neither the infrastructure nor individual ports are guaranteed to work on these FreeBSD versions after that date. A CVS tag will be created for users who cannot upgrade for some reason, at which time these users are advised to stop tracking the latest ports CVS repository and use the RELEASE_6_EOL tag instead. The current supported branches and expected EoL dates are: +---------------------------------------------------------------------+ | Branch | Release | Type | Release date | Estimated EoL | |-----------+------------+--------+-----------------+-----------------| |RELENG_6 |n/a |n/a |n/a |November 30, 2010| |---------------------------------------------------------------------| |RELENG_6_4 |6.4-RELEASE |Extended|November 18, 2008|November 30, 2010| |---------------------------------------------------------------------| |RELENG_7 |n/a |n/a |n/a |last release + 2y| |-----------+------------+--------+-----------------+-----------------| |RELENG_7_1 |7.1-RELEASE |Extended|January 4, 2009 |January 31, 2011 | |-----------+------------+--------+-----------------+-----------------| |RELENG_7_3 |7.3-RELEASE |Extended|March 23, 2010 |March 31, 2012 | |-----------+------------+--------+-----------------+-----------------| |RELENG_8 |n/a |n/a |n/a |last release + 2y| |-----------+------------+--------+-----------------+-----------------| |RELENG_8_0 |8.0-RELEASE |Normal |November 25, 2009|November 30, 2010| |-----------+------------+--------+-----------------+-----------------| |RELENG_8_1 |8.1-RELEASE |Extended|July 23, 2010 |July 31, 2012 | +---------------------------------------------------------------------+ - -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkzONUAACgkQOM7KaQxqam6AGgCcCsVMApQTN0x0fS4yZDfvzKNS 1T4AoJp/mS24RZF6DHrLWssplNNveGcb =L3fZ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 07:31:01 2010 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 45C1C1065670; Mon, 1 Nov 2010 07:31:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 39B6E8FC13; Mon, 1 Nov 2010 07:30:59 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA14454; Mon, 01 Nov 2010 09:30:55 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PCor1-0002e8-9c; Mon, 01 Nov 2010 09:30:55 +0200 Message-ID: <4CCE6CAD.30304@icyb.net.ua> Date: Mon, 01 Nov 2010 09:30:53 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alexander Zagrebin References: <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua><4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org><4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua> <20101030112520.GD79691@two.kliksys.ru> <4CCC2F2A.7020809@icyb.net.ua><20101030190120.GA80301@two.kliksys.ru> <4CCD0804.8010703@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 01 Nov 2010 07:31:01 -0000 on 31/10/2010 11:02 Alexander Zagrebin said the following: > I have a question. > When we transfer a file via sendfile, then current code allocates > a memory, marked inactive. For example, if the file has size 100 MB, > then 100 MB of memory will be allocated. > If we have to transfer this file again later, then this memory will used > as cache, and no disk io will be required. > The memory will be freed if file will be deleted or operating system > will need an additional memory. > I have correctly understood? > If it so, the i continue... > Such behaviour is good if we have files with relatively small size. > Suppose we have to transfer file with large size (for example, greater > than amount of physical memory). > While transfering, the inactive memory will grow, pressing the ARC. > When size of the ARC will fall to its minimum (vfs.zfs.arc_min), then > inactive memory will be reused. > So, when transfer is complete, we have: > 1. No free memory > 2. Size of the ARC has minimal size (it is bad) > 3. Inactive memory contains the _tail_ of the file only (it is bad too) > Now if we have to transfer this file again, then > 1. there is no (or few) file's data in ARC (ARC too small) > 2. The inactive memory doesn't contain a head part of the file > So the file's data will read from a disk again and again... > Also i've noticed that inactive memory frees relatively slowly, > so if there is a frequent access to large files, then system will run > at very unoptimal conditions. > It's imho... > Can you comment this? > First and foremost, the double-caching issue for ZFS+sendfile on FreeBSD is still there and no resolution for this issue is on horizon. So, you have to account for the fact that twice as much memory is needed for this use-case. Whether you plan your system, or configure it, or tune it. Second, with recent head and stable/8 ARC should not be the primary victim of memory pressure; ARC reclaim thread and the page daemon should cooperate in freeing/recycling memory. Nothing much to add. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 09:15:58 2010 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 39E72106566C for ; Mon, 1 Nov 2010 09:15:58 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0FB8FC0A for ; Mon, 1 Nov 2010 09:15:57 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA16449 for ; Mon, 01 Nov 2010 11:15:56 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PCqUd-0002lK-Nz for freebsd-stable@FreeBSD.org; Mon, 01 Nov 2010 11:15:55 +0200 Message-ID: <4CCE854A.9020608@freebsd.org> Date: Mon, 01 Nov 2010 11:15:54 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Fwd: amd64: VM_KMEM_SIZE_SCALE changed to 1 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, 01 Nov 2010 09:15:58 -0000 FYI, this has been MFC-ed as r214620. -------- Original Message -------- Message-ID: <4C9323F0.90500@freebsd.org> Date: Fri, 17 Sep 2010 11:16:48 +0300 From: Andriy Gapon To: freebsd-arch@FreeBSD.org CC: freebsd-current@FreeBSD.ORG Subject: amd64: VM_KMEM_SIZE_SCALE changed to 1 on 09/09/2010 11:01 Andriy Gapon said the following: > on 26/07/2010 19:07 Andriy Gapon said the following: >> >> Anyone knows any reason why VM_KMEM_SIZE_SCALE on amd64 should not be set to 1? >> I mean things potentially breaking, or some unpleasant surprise for an >> administrator/user... > > So, after having the discussion, what is our collective conclusion? > a) Go for it! > or > b) Don't do it, fool! > or > c) Let's wait another year... Nobody said (b), so: http://svn.freebsd.org/viewvc/base?view=revision&revision=212784 This thread in Gmane for your convenience: http://thread.gmane.org/gmane.os.freebsd.architechture/13419/focus=13551 -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 09:18:25 2010 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 445C4106566B for ; Mon, 1 Nov 2010 09:18:25 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7366C8FC17 for ; Mon, 1 Nov 2010 09:18:24 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA16480 for ; Mon, 01 Nov 2010 11:18:23 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PCqX0-0002lV-SU for freebsd-stable@FreeBSD.org; Mon, 01 Nov 2010 11:18:23 +0200 Message-ID: <4CCE85DE.6010608@freebsd.org> Date: Mon, 01 Nov 2010 11:18:22 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Subject: Intel CPU topology code MFC-ed to stable/8 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, 01 Nov 2010 09:18:25 -0000 Please be advised that Intel CPU topology code from head has been MFC-ed to stable/8 as r214621. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 10:39:48 2010 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 299AD106564A; Mon, 1 Nov 2010 10:39:48 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id AE9848FC08; Mon, 1 Nov 2010 10:39:47 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id B9613153434; Mon, 1 Nov 2010 11:39:45 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sr-RcVERgydU; Mon, 1 Nov 2010 11:39:43 +0100 (CET) Received: from [127.0.0.1] (opteron [192.168.10.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 91FBC153433; Mon, 1 Nov 2010 11:39:43 +0100 (CET) Message-ID: <4CCE98ED.6010002@digiware.nl> Date: Mon, 01 Nov 2010 11:39:41 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Andriy Gapon References: <4CCAF0EB.4080001@icyb.net.ua> <20101029175105.GB18613@two.kliksys.ru> <4CCBD443.7010305@icyb.net.ua><4CCBD46E.9030200@icyb.net.ua> <4CCBD661.3000204@freebsd.org><4CCBEAF6.2030408@freebsd.org> <20101030101254.GB79691@two.kliksys.ru> <4CCBF45C.4080208@icyb.net.ua> <20101030112520.GD79691@two.kliksys.ru> <4CCC2F2A.7020809@icyb.net.ua><20101030190120.GA80301@two.kliksys.ru> <4CCD0804.8010703@icyb.net.ua> <4CCE6CAD.30304@icyb.net.ua> In-Reply-To: <4CCE6CAD.30304@icyb.net.ua> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Alexander Zagrebin Subject: Re: 8.1-STABLE: zfs and sendfile: problem still exists 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, 01 Nov 2010 10:39:48 -0000 On 2010-11-01 8:30, Andriy Gapon wrote: > First and foremost, the double-caching issue for ZFS+sendfile on FreeBSD is > still there and no resolution for this issue is on horizon. So, you have to > account for the fact that twice as much memory is needed for this use-case. > Whether you plan your system, or configure it, or tune it. > > Second, with recent head and stable/8 ARC should not be the primary victim of > memory pressure; ARC reclaim thread and the page daemon should cooperate in > freeing/recycling memory. > > Nothing much to add. Although this discussion started due to issues with serving files thru web-typish services, there are more apps that use sendfile. For one, I noticed that I had once enabled sendfile in my Samba config. As per this discussion I saw little advantage in keeping it that way...... But I'm open for other suggestions. --WjW From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 11:01:47 2010 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 B5152106566C for ; Mon, 1 Nov 2010 11:01:47 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 54C988FC17 for ; Mon, 1 Nov 2010 11:01:47 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4CAC945C89; Mon, 1 Nov 2010 12:01:46 +0100 (CET) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id A940945CA0; Mon, 1 Nov 2010 12:01:40 +0100 (CET) Date: Mon, 1 Nov 2010 12:01:00 +0100 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20101101110100.GI2160@garage.freebsd.pl> References: <86wrp3wj67.fsf@kopusha.home.net> <20101028163036.GA2347@garage.freebsd.pl> <86lj5i3zjt.fsf@kopusha.home.net> <86d3qr3m0b.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pe+tqlI1iYzVj1X/" Content-Disposition: inline In-Reply-To: <86d3qr3m0b.fsf@kopusha.home.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-stable@freebsd.org, Pete French Subject: Re: hast vs ggate+gmirror sychrnoisation speed 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, 01 Nov 2010 11:01:47 -0000 --pe+tqlI1iYzVj1X/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 30, 2010 at 03:25:56PM +0300, Mikolaj Golub wrote: >=20 > On Thu, 28 Oct 2010 22:08:54 +0300 Mikolaj Golub wrote to Pawel Jakub Daw= idek: >=20 > PJD>> I looked at the code and the keepalive packets arbe sent from anot= her > PJD>> thread. Could you try turning them off in primary.c and see if that > PJD>> helps? >=20 > MG> At first I set RETRY_SLEEP to 1 sec to have more keepalive packets. = The errors > MG> started to observe frequently: >=20 > MG> Oct 28 21:35:53 bolek hastd[1709]: [storage] (secondary) Unable to r= eceive request header: RPC version wrong. > MG> Oct 28 21:35:54 bolek hastd[1632]: [storage] (secondary) Worker proc= ess exited ungracefully (pid=3D1709, exitcode=3D75). > MG> Oct 28 21:36:12 bolek hastd[1722]: [storage] (secondary) Unable to r= eceive request header: RPC version wrong. > MG> Oct 28 21:36:12 bolek hastd[1632]: [storage] (secondary) Worker proc= ess exited ungracefully (pid=3D1722, exitcode=3D75). > MG> ... >=20 > MG> Now I have been running synchronization for more then a half an hour= with > MG> keepalive_send disabled and have not seen any error. >=20 > So :-) What do you think about sending keepalive in remote_send_thread() = to > avoid this problem and sending them only when a connection is idle (it lo= oks > like there is no much use to send them all the time)? Something like in t= he > patch below (it works for me). I like your patch and I agree of course it is better to send keepalive packets only when connection is idle. The only thing I'd change is to modify QUEUE_TAKE1() macro to take additional argument 'timeout' - if we don't want it to time out, we pass 0. Could you modify your patch? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --pe+tqlI1iYzVj1X/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzOnewACgkQForvXbEpPzRzugCeIi7y7O5jKsqxZyhs2rXskvPP E/wAnitchRQB9Gu217OGm+m3bqSO5bmn =RXcK -----END PGP SIGNATURE----- --pe+tqlI1iYzVj1X/-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 12:38:18 2010 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 AC7C51065670 for ; Mon, 1 Nov 2010 12:38:18 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by mx1.freebsd.org (Postfix) with ESMTP id 62AB98FC1D for ; Mon, 1 Nov 2010 12:38:18 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=H8EcBC3vxl5BMdo9WHtbBMkMcbzIZ/ZO807H3QfOZVLhN7PK66/nqP2nA3l4mwFt; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1PCteT-0005iY-C7; Mon, 01 Nov 2010 07:38:17 -0500 Message-ID: <4CCEB4B7.6030006@earthlink.net> Date: Mon, 01 Nov 2010 08:38:15 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7 MIME-Version: 1.0 To: John Baldwin References: <4CCAE59E.5020006@earthlink.net> <4CCB25CC.9050405@earthlink.net> <4CCB2C88.9050208@earthlink.net> <201010291720.11771.jhb@freebsd.org> In-Reply-To: <201010291720.11771.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79e4cec1117bde4493f6e1c12937b30417350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: safe mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 12:38:18 -0000 On 10/29/2010 05:20 PM, John Baldwin wrote: > On Friday, October 29, 2010 4:20:24 pm Stephen Clark wrote: > >>> rr232x: RocketRAID 232x controller driver v1.02 (Jan 16 2008 04:16:21) >>> hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 04:16:19) >>> >>> >> big snip >> >>> lo0: bpf attached >>> rr232x: no controller detected. >>> hptrr: no controller detected. >>> m >>> >>> >> Why does FreeBSD think I have a rocket raid controller? This the generic >> kernel. >> Is there some way disable this from loading? >> > The hptrr driver is in GENERIC in 6.x and it always prints out the first > message. You can ignore it. > > Hi John, Here is the verbose boot from the 7.2 release iso SMAP type=01 base=0000000000000000 len=000000000009fc00 SMAP type=02 base=000000000009fc00 len=0000000000000400 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=000000003f9a0000 SMAP type=03 base=000000003faa0000 len=000000000000e000 SMAP type=04 base=000000003faae000 len=0000000000032000 SMAP type=02 base=000000003fae0000 len=0000000000010000 SMAP type=02 base=000000003faf0000 len=0000000000010000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ffb00000 len=0000000000500000 Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009 root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc129f000. Preloaded mfs_root "/boot/mfsroot" at 0xc129f1ac. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc129f1f0. Calibrating clock(s) ... i8254 clock: 1189628 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1673321840 Hz CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1673.32-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106ca Stepping = 10 Features=0xbfebfbff Features2=0x40e31d> AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 Logical CPUs per core: 2 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 512 kbytes, 8-way associative, 64 bytes/line real memory = 1068105728 (1018 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001425000 - 0x000000003e86cfff, 1027899392 bytes (250952 pages) avail memory = 1027330048 (979 MB) Table 'FACP' at 0x3faa0290 Table 'APIC' at 0x3faa0390 MADT: Found table at 0x3faa0390 MP Configuration Table version 1.4 found at 0xc00fdc90 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 1 ACPI ID 3: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 3 ACPI ID 4: enabled SMP: Added CPU 3 (AP) ACPI APIC Table: <080610 APIC1657> INTR: Adding local APIC 2 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP/HT): APIC ID: 3 bios32: Found BIOS32 Service Directory header at 0xc00f0000 bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x31 pnpbios: Found PnP BIOS data at 0xc00f6100 pnpbios: Entry = f0000:78ba Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 3 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu 1 ULE: adding cpu 1 to group 0: cpus 2 mask 0x3 ULE: setup cpu group 1 ULE: setup cpu 2 ULE: adding cpu 2 to group 1: cpus 1 mask 0x4 ULE: setup cpu 3 ULE: adding cpu 3 to group 1: cpus 2 mask 0xC ACPI: RSDP @ 0x0xf9d50/0x0024 (v 2 ACPIAM) ACPI: XSDT @ 0x0x3faa0100/0x004C (v 1 080610 XSDT1657 0x20100806 MSFT 0x000000) ACPI: FACP @ 0x0x3faa0290/0x00F4 (v 4 080610 FACP1657 0x20100806 MSFT 0x000000) ACPI: DSDT @ 0x0x3faa0440/0x6C25 (v 2 1AEMZ 1AEMZ005 0x00000005 INTL 0x200511) ACPI: FACS @ 0x0x3faae000/0x0040 ACPI: APIC @ 0x0x3faa0390/0x006C (v 2 080610 APIC1657 0x20100806 MSFT 0x000000) ACPI: MCFG @ 0x0x3faa0400/0x003C (v 1 080610 OEMMCFG 0x20100806 MSFT 0x000000) ACPI: OEMB @ 0x0x3faae040/0x0072 (v 1 080610 OEMB1657 0x20100806 MSFT 0x000000) ACPI: GSCI @ 0x0x3faae0c0/0x2024 (v 1 080610 GMCHSCI 0x20100806 MSFT 0x000000) MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 4 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 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010000 wlan_amrr: wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (May 1 2009 08:47:24) npx0: INT 16 interface acpi0: <080610 XSDT1657> on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc427e000 pa 0x1000 pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=a0008086) pcibios: BIOS version 3.00 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.FHR0 -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0 acpi0: reservation of ffc00000, 300000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3fa00000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 6 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0xa000, revid=0x02 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0xa001, revid=0x02 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0xfe980000, size 19, enabled map[14]: type I/O Port, range 32, base 0xcc00, size 3, enabled map[18]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, d map[1c]: type Memory, range 32, base 0xfe800000, size 20, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0xa002, revid=0x02 domain=0, bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfe780000, size 19, enabled found-> vendor=0x8086, dev=0x2834, revid=0x03 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type I/O Port, range 32, base 0xc880, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2835, revid=0x03 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0xc800, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x283a, revid=0x03 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, 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 0xfe977c00, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x283f, revid=0x03 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 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 22 found-> vendor=0x8086, dev=0x2845, revid=0x03 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 21 found-> vendor=0x8086, dev=0x2830, revid=0x03 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 map[20]: type I/O Port, range 32, base 0xc480, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2831, revid=0x03 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0xc400, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2832, revid=0x03 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, 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 0xc080, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2836, revid=0x03 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfe977800, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xf3 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=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2815, revid=0x03 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=0x2850, revid=0x03 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0xffa0, size 4, enabled found-> vendor=0x8086, dev=0x2828, revid=0x03 domain=0, bus=0, slot=31, func=2 class=01-01-8f, 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=15 powerspec 3 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xc000, size 3, enabled map[14]: type I/O Port, range 32, base 0xbc00, size 2, enabled map[18]: type I/O Port, range 32, base 0xb880, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb800, size 2, enabled map[20]: type I/O Port, range 32, base 0xb480, size 4, enabled map[24]: type I/O Port, range 32, base 0xb400, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 18 found-> vendor=0x8086, dev=0x283e, revid=0x03 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0103, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type Memory, range 32, base 0xfe977400, 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 17 vgapci0: port 0xcc00-0xcc07 mem 0xfe980000-0xfe9fffff,0 vgapci1: mem 0xfe780000-0xfe7fffff at device 2.1 on pc0 uhci0: port 0xc880-0xc89f irq 16 at 0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc880 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc800-0xc81f irq 21 at 0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc800 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 50 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xfe977c00-0xfe977ff0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfe977c00 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered pcib1: irq 22 at device 28.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: irq 21 at device 28.3 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfea00000-0xfeafffff pcib2: prefetched decode 0xfdf00000-0xfdffffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x10ec, dev=0x8168, revid=0x03 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 4 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xd800, size 8, enabled pcib2: requested I/O range 0xd800-0xd8ff: in range map[18]: type Prefetchable Memory, range 64, base 0xfdfff000, size 12, d pcib2: requested memory range 0xfdfff000-0xfdffffff: good map[20]: type Prefetchable Memory, range 64, base 0xfdff8000, size 14, d pcib2: requested memory range 0xfdff8000-0xfdffbfff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 19 re0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-o re0: bpf attached re0: Ethernet address: 00:30:18:ae:ae:51 re0: [MPSAFE] re0: [FILTER] uhci2: port 0xc480-0xc49f irq 23 at 0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc480 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 53 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0xc400-0xc41f irq 19 at 0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc400 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 54 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xc080-0xc09f irq 18 at 0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc080 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xfe977800-0xfe977bf0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfe977800 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered umass0: at device 30.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xe000-0xefff pcib3: memory decode 0xfeb00000-0xfebfffff pcib3: no prefetched decode pcib3: Subtractively decoded bridge. pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x10ec, dev=0x8139, revid=0x10 domain=0, bus=3, slot=4, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=15 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xe800, size 8, enabled pcib3: requested I/O range 0xe800-0xe8ff: in range map[14]: type Memory, range 32, base 0xfebffc00, size 8, enabled pcib3: requested memory range 0xfebffc00-0xfebffcff: good pcib3: matched entry for 3.4.INTA pcib3: slot 4 INTA hardwired to IRQ 18 found-> vendor=0x10ec, dev=0x8139, revid=0x10 domain=0, bus=3, slot=6, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xe400, size 8, enabled pcib3: requested I/O range 0xe400-0xe4ff: in range map[14]: type Memory, range 32, base 0xfebff800, size 8, enabled pcib3: requested memory range 0xfebff800-0xfebff8ff: good pcib3: matched entry for 3.6.INTA pcib3: slot 6 INTA hardwired to IRQ 19 found-> vendor=0x10ec, dev=0x8139, revid=0x10 domain=0, bus=3, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xe000, size 8, enabled pcib3: requested I/O range 0xe000-0xe0ff: in range map[14]: type Memory, range 32, base 0xfebff400, size 8, enabled pcib3: requested memory range 0xfebff400-0xfebff4ff: good pcib3: matched entry for 3.7.INTA pcib3: slot 7 INTA hardwired to IRQ 16 rl0: port 0xe800-0xe8ff mem 0xfebffc00-0xfebffcff i3 rl0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe800 miibus1: on rl0 rlphy0: PHY 0 on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: bpf attached rl0: Ethernet address: 00:30:18:a1:7f:e9 rl0: [MPSAFE] rl0: [ITHREAD] rl1: port 0xe400-0xe4ff mem 0xfebff800-0xfebff8ff i3 rl1: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe400 miibus2: on rl1 rlphy1: PHY 0 on miibus2 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: bpf attached rl1: Ethernet address: 00:30:18:a1:7f:ea rl1: [MPSAFE] rl1: [ITHREAD] rl2: port 0xe000-0xe0ff mem 0xfebff400-0xfebff4ff i3 rl2: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe000 miibus3: on rl2 rlphy2: PHY 0 on miibus3 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl2: bpf attached rl2: Ethernet address: 00:30:18:a1:7f:eb rl2: [MPSAFE] rl2: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=40 ostat1=40 ata0: stat0=0x0c err=0x0c lsb=0x0c msb=0x0c ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: reset tp2 stat0=87 stat1=87 devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55 ata0: [MPSAFE] ata0: [ITHREAD] atapci1: port 0xc000-0xc007,0xbc00-0xbc03,0xb80 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xb480 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: Reserved 0x10 bytes for rid 0x24 type 4 at 0xb400 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xc000 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbc00 ata2: reset tp1 mask=03 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xb880 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb800 ata3: reset tp1 mask=03 ostat0=7f ostat1=7f ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat1=0x7f err=0xff lsb=0xff msb=0xff ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: [MPSAFE] ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console ioapic0: Changing trigger for pin 4 to level ioapic0: Changing polarity for pin 4 to low ioapic0: routing intpin 4 (ISA IRQ 4) to vector 56 sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x83ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ cpu0: on acpi0 cpu0: switching to generic Cx mode p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 cpu2: on acpi0 p4tcc2: on cpu2 cpu3: on acpi0 p4tcc3: on cpu3 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed ex_isa_identify() ata: ata0 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) ata1 failed to probe at port 0x170 irq 15 on isa0 bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 83666108 hz Timecounter "TSC" frequency 1673321840 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. md0: Preloaded image 4423680 bytes at 0xc0dfab28 ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire GEOM_LABEL: Label for provider md0 is ufsid/49fabd23737484d9. ad4: 152627MB at ata2-master SATA300 ad4: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ad4: Intel check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed GEOM_LABEL: Label for provider ad4s1 is ext2fs//boot. GEOM_LABEL: Label for provider ad4s3 is ext2fs//. (probe0:umass-sim0:0:0:0): error 22 (probe0:umass-sim0:0:0:0): Unretryable Error (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? GEcd0 at umass-sim0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 40.000MB/s transfers cd0: cd present [1166896 x 2048 byte records] OM: new disk cd0 pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 40.000MB/s transfers ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 2 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 2 ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: Assigning PCI IRQ 18 to local APIC 2 ioapic0: Assigning PCI IRQ 19 to local APIC 0 ioapic0: Assigning PCI IRQ 21 to local APIC 2 ioapic0: Assigning PCI IRQ 23 to local APIC 0 msi: Assigning MSI IRQ 256 to local APIC 2 scsi_cd.c::ioctl cmd=4400648b error=25 GEOM_LABEL: Label for provider cd0 is iso9660/FreeBSD_Install. Trying to mount root from ufs:/dev/md0 start_init: trying /sbin/init start_init: trying /sbin/oinit start_init: trying /sbin/init.bak start_init: trying /rescue/init start_init: trying /stand/sysinstall GEOM_LABEL: Label ufsid/49fabd23737484d9 removed. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 15:06:55 2010 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 2DC3C1065673; Mon, 1 Nov 2010 15:06:55 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4B27D8FC1B; Mon, 1 Nov 2010 15:06:54 +0000 (UTC) Received: by fxm17 with SMTP id 17so5153438fxm.13 for ; Mon, 01 Nov 2010 08:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :organization:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=mZ90ZlNQymIxGM88pApU54TTif4ZT7qaRNkQZEKQBTw=; b=pZ/IR13KdGboa/eGo2j92zdtQVxPgCdgA0+Qei6OSG2G2ZFg7QqfhTuPsP9nL7FJFy ZuIUz/tK0VmwxYPSo6ohzNqXr2yjSTe9oemSigwMvcdtRFFHomSsXbhUTskW2/GlQce1 s7EgGVqnTvHNIurOCUC/BqDj5k0R+fe3v6TDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=lgNd2aMSNVUM87JFNGfkXBvokfh1Pyjw8Tt1bH3O3xwdNyUCKY1k00mAAIaDk5L6ll CwOkzLvY1nxjHYz3O4lTyE6wWFL9qXP1L63Rye+m0jUZCMRqDoQKBV6d+Ik2LUdjXvdT i+H/nwtoq0a5+PhAHCattnIFlSExw1cNbPJgE= Received: by 10.223.125.207 with SMTP id z15mr9296083far.42.1288624013431; Mon, 01 Nov 2010 08:06:53 -0700 (PDT) Received: from localhost (ua1.etadirect.net [91.198.140.16]) by mx.google.com with ESMTPS id u8sm2477115fah.12.2010.11.01.08.06.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Nov 2010 08:06:51 -0700 (PDT) From: Mikolaj Golub To: Pawel Jakub Dawidek Organization: TOA Ukraine References: <86wrp3wj67.fsf@kopusha.home.net> <20101028163036.GA2347@garage.freebsd.pl> <86lj5i3zjt.fsf@kopusha.home.net> <86d3qr3m0b.fsf@kopusha.home.net> <20101101110100.GI2160@garage.freebsd.pl> Date: Mon, 01 Nov 2010 17:06:49 +0200 In-Reply-To: <20101101110100.GI2160@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Mon, 1 Nov 2010 12:01:00 +0100") Message-ID: <86d3qpqe0m.fsf@zhuzha.ua1> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: freebsd-stable@freebsd.org, Pete French Subject: Re: hast vs ggate+gmirror sychrnoisation speed 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, 01 Nov 2010 15:06:55 -0000 --=-=-= On Mon, 1 Nov 2010 12:01:00 +0100 Pawel Jakub Dawidek wrote: PJD> I like your patch and I agree of course it is better to send keepalive PJD> packets only when connection is idle. The only thing I'd change is to PJD> modify QUEUE_TAKE1() macro to take additional argument 'timeout' - if we PJD> don't want it to time out, we pass 0. Could you modify your patch? Sure :-). Could you look at the updated version? Note. So far I have only tested that hastd with this updated patch is compilable and runnable. I will do normal testing today later when I have access to my test instances and will report about the results. -- Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=hastd.keepalive.2.patch Index: sbin/hastd/primary.c =================================================================== --- sbin/hastd/primary.c (revision 214624) +++ sbin/hastd/primary.c (working copy) @@ -180,14 +180,20 @@ static pthread_mutex_t metadata_lock; if (_wakeup) \ cv_signal(&hio_##name##_list_cond); \ } while (0) -#define QUEUE_TAKE1(hio, name, ncomp) do { \ +#define QUEUE_TAKE1(hio, name, ncomp, timeout) do { \ + bool _last; \ + \ mtx_lock(&hio_##name##_list_lock[(ncomp)]); \ - while (((hio) = TAILQ_FIRST(&hio_##name##_list[(ncomp)])) == NULL) { \ - cv_wait(&hio_##name##_list_cond[(ncomp)], \ - &hio_##name##_list_lock[(ncomp)]); \ + _last = false; \ + while (((hio) = TAILQ_FIRST(&hio_##name##_list[(ncomp)])) == NULL && !_last) { \ + cv_timedwait(&hio_##name##_list_cond[(ncomp)], \ + &hio_##name##_list_lock[(ncomp)], (timeout)); \ + if ((timeout) != 0) \ + _last = true; \ } \ - TAILQ_REMOVE(&hio_##name##_list[(ncomp)], (hio), \ - hio_next[(ncomp)]); \ + if (hio != NULL) \ + TAILQ_REMOVE(&hio_##name##_list[(ncomp)], (hio), \ + hio_next[(ncomp)]); \ mtx_unlock(&hio_##name##_list_lock[(ncomp)]); \ } while (0) #define QUEUE_TAKE2(hio, name) do { \ @@ -1112,7 +1118,7 @@ local_send_thread(void *arg) for (;;) { pjdlog_debug(2, "local_send: Taking request."); - QUEUE_TAKE1(hio, send, ncomp); + QUEUE_TAKE1(hio, send, ncomp, 0); pjdlog_debug(2, "local_send: (%p) Got request.", hio); ggio = &hio->hio_ggio; switch (ggio->gctl_cmd) { @@ -1176,6 +1182,38 @@ local_send_thread(void *arg) return (NULL); } +static void +keepalive_send(struct hast_resource *res, unsigned int ncomp) +{ + struct nv *nv; + + if (!ISCONNECTED(res, ncomp)) + return; + + assert(res->hr_remotein != NULL); + assert(res->hr_remoteout != NULL); + + nv = nv_alloc(); + nv_add_uint8(nv, HIO_KEEPALIVE, "cmd"); + if (nv_error(nv) != 0) { + nv_free(nv); + pjdlog_debug(1, + "keepalive_send: Unable to prepare header to send."); + return; + } + if (hast_proto_send(res, res->hr_remoteout, nv, NULL, 0) < 0) { + pjdlog_common(LOG_DEBUG, 1, errno, + "keepalive_send: Unable to send request"); + nv_free(nv); + rw_unlock(&hio_remote_lock[ncomp]); + remote_close(res, ncomp); + rw_rlock(&hio_remote_lock[ncomp]); + return; + } + nv_free(nv); + pjdlog_debug(2, "keepalive_send: Request sent."); +} + /* * Thread sends request to secondary node. */ @@ -1184,6 +1222,7 @@ remote_send_thread(void *arg) { struct hast_resource *res = arg; struct g_gate_ctl_io *ggio; + time_t lastcheck, now; struct hio *hio; struct nv *nv; unsigned int ncomp; @@ -1194,10 +1233,19 @@ remote_send_thread(void *arg) /* Remote component is 1 for now. */ ncomp = 1; + lastcheck = time(NULL); for (;;) { pjdlog_debug(2, "remote_send: Taking request."); - QUEUE_TAKE1(hio, send, ncomp); + QUEUE_TAKE1(hio, send, ncomp, RETRY_SLEEP); + if (hio == NULL) { + now = time(NULL); + if (lastcheck + RETRY_SLEEP <= now) { + keepalive_send(res, ncomp); + lastcheck = now; + } + continue; + } pjdlog_debug(2, "remote_send: (%p) Got request.", hio); ggio = &hio->hio_ggio; switch (ggio->gctl_cmd) { @@ -1883,32 +1931,6 @@ failed: } static void -keepalive_send(struct hast_resource *res, unsigned int ncomp) -{ - struct nv *nv; - - nv = nv_alloc(); - nv_add_uint8(nv, HIO_KEEPALIVE, "cmd"); - if (nv_error(nv) != 0) { - nv_free(nv); - pjdlog_debug(1, - "keepalive_send: Unable to prepare header to send."); - return; - } - if (hast_proto_send(res, res->hr_remoteout, nv, NULL, 0) < 0) { - pjdlog_common(LOG_DEBUG, 1, errno, - "keepalive_send: Unable to send request"); - nv_free(nv); - rw_unlock(&hio_remote_lock[ncomp]); - remote_close(res, ncomp); - rw_rlock(&hio_remote_lock[ncomp]); - return; - } - nv_free(nv); - pjdlog_debug(2, "keepalive_send: Request sent."); -} - -static void guard_one(struct hast_resource *res, unsigned int ncomp) { struct proto_conn *in, *out; @@ -1926,12 +1948,6 @@ guard_one(struct hast_resource *res, unsigned int if (ISCONNECTED(res, ncomp)) { assert(res->hr_remotein != NULL); assert(res->hr_remoteout != NULL); - keepalive_send(res, ncomp); - } - - if (ISCONNECTED(res, ncomp)) { - assert(res->hr_remotein != NULL); - assert(res->hr_remoteout != NULL); rw_unlock(&hio_remote_lock[ncomp]); pjdlog_debug(2, "remote_guard: Connection to %s is ok.", res->hr_remoteaddr); --=-=-=-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 15:20:13 2010 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 1892D10656B3 for ; Mon, 1 Nov 2010 15:20:12 +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 B47BA8FC12 for ; Mon, 1 Nov 2010 15:20:05 +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 34B8246B81; Mon, 1 Nov 2010 11:20:05 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CBB618A027; Mon, 1 Nov 2010 11:20:03 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org, sclark46@earthlink.net Date: Mon, 1 Nov 2010 09:54:42 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CCAE59E.5020006@earthlink.net> <201010291720.11771.jhb@freebsd.org> <4CCEB4B7.6030006@earthlink.net> In-Reply-To: <4CCEB4B7.6030006@earthlink.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011010954.42574.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 01 Nov 2010 11:20:03 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Jeremy Chadwick Subject: Re: safe mode 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, 01 Nov 2010 15:20:13 -0000 On Monday, November 01, 2010 8:38:15 am Stephen Clark wrote: > On 10/29/2010 05:20 PM, John Baldwin wrote: > > On Friday, October 29, 2010 4:20:24 pm Stephen Clark wrote: > > > >>> rr232x: RocketRAID 232x controller driver v1.02 (Jan 16 2008 04:16:21) > >>> hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 04:16:19) > >>> > >>> > >> big snip > >> > >>> lo0: bpf attached > >>> rr232x: no controller detected. > >>> hptrr: no controller detected. > >>> m > >>> > >>> > >> Why does FreeBSD think I have a rocket raid controller? This the generic > >> kernel. > >> Is there some way disable this from loading? > >> > > The hptrr driver is in GENERIC in 6.x and it always prints out the first > > message. You can ignore it. > > > > > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 > ata0: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=03 ostat0=40 ostat1=40 > ata0: stat0=0x0c err=0x0c lsb=0x0c msb=0x0c > ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f > ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: reset tp2 stat0=87 stat1=87 devices=0x0 > ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55 > ata0: [MPSAFE] > ata0: [ITHREAD] > atapci1: port > 0xc000-0xc007,0xbc00-0xbc03,0xb80 > atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xb480 > atapci1: [MPSAFE] > atapci1: [ITHREAD] > atapci1: Reserved 0x10 bytes for rid 0x24 type 4 at 0xb400 > ata2: on atapci1 > atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xc000 > atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbc00 > ata2: reset tp1 mask=03 ostat0=50 ostat1=00 > ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 > ata2: reset tp2 stat0=50 stat1=00 devices=0x1 > ata2: [MPSAFE] > ata2: [ITHREAD] > ata3: on atapci1 > atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xb880 > atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb800 > ata3: reset tp1 mask=03 ostat0=7f ostat1=7f > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata3: stat1=0x7f err=0xff lsb=0xff msb=0xff > ata3: reset tp2 stat0=ff stat1=ff devices=0x0 > ata3: [MPSAFE] > ata3: [ITHREAD] > .... > ioapic0: Assigning ISA IRQ 1 to local APIC 0 > ioapic0: Assigning ISA IRQ 4 to local APIC 2 > ioapic0: Assigning ISA IRQ 9 to local APIC 0 > ioapic0: Assigning ISA IRQ 14 to local APIC 2 > ioapic0: Assigning PCI IRQ 16 to local APIC 0 > ioapic0: Assigning PCI IRQ 18 to local APIC 2 > ioapic0: Assigning PCI IRQ 19 to local APIC 0 > ioapic0: Assigning PCI IRQ 21 to local APIC 2 > ioapic0: Assigning PCI IRQ 23 to local APIC 0 > msi: Assigning MSI IRQ 256 to local APIC 2 Hmm, 7.2 does not register a handler for IRQ 15 at all, and it doesn't find a second channel (ata1) on atapci0 either. I think that is probably the difference. Try this patch: Index: ata-chipset.c =================================================================== --- ata-chipset.c (revision 214624) +++ ata-chipset.c (working copy) @@ -1762,58 +1762,58 @@ { struct ata_pci_controller *ctlr = device_get_softc(dev); static struct ata_chip_id ids[] = - {{ ATA_I82371FB, 0, 0, 0x00, ATA_WDMA2, "PIIX" }, - { ATA_I82371SB, 0, 0, 0x00, ATA_WDMA2, "PIIX3" }, - { ATA_I82371AB, 0, 0, 0x00, ATA_UDMA2, "PIIX4" }, - { ATA_I82443MX, 0, 0, 0x00, ATA_UDMA2, "PIIX4" }, - { ATA_I82451NX, 0, 0, 0x00, ATA_UDMA2, "PIIX4" }, - { ATA_I82801AB, 0, 0, 0x00, ATA_UDMA2, "ICH0" }, - { ATA_I82801AA, 0, 0, 0x00, ATA_UDMA4, "ICH" }, - { ATA_I82372FB, 0, 0, 0x00, ATA_UDMA4, "ICH" }, - { ATA_I82801BA, 0, 0, 0x00, ATA_UDMA5, "ICH2" }, - { ATA_I82801BA_1, 0, 0, 0x00, ATA_UDMA5, "ICH2" }, - { ATA_I82801CA, 0, 0, 0x00, ATA_UDMA5, "ICH3" }, - { ATA_I82801CA_1, 0, 0, 0x00, ATA_UDMA5, "ICH3" }, - { ATA_I82801DB, 0, 0, 0x00, ATA_UDMA5, "ICH4" }, - { ATA_I82801DB_1, 0, 0, 0x00, ATA_UDMA5, "ICH4" }, - { ATA_I82801EB, 0, 0, 0x00, ATA_UDMA5, "ICH5" }, - { ATA_I82801EB_S1, 0, 0, 0x00, ATA_SA150, "ICH5" }, - { ATA_I82801EB_R1, 0, 0, 0x00, ATA_SA150, "ICH5" }, - { ATA_I6300ESB, 0, 0, 0x00, ATA_UDMA5, "6300ESB" }, - { ATA_I6300ESB_S1, 0, 0, 0x00, ATA_SA150, "6300ESB" }, - { ATA_I6300ESB_R1, 0, 0, 0x00, ATA_SA150, "6300ESB" }, - { ATA_I82801FB, 0, 0, 0x00, ATA_UDMA5, "ICH6" }, - { ATA_I82801FB_S1, 0, AHCI, 0x00, ATA_SA150, "ICH6" }, - { ATA_I82801FB_R1, 0, AHCI, 0x00, ATA_SA150, "ICH6" }, - { ATA_I82801FBM, 0, AHCI, 0x00, ATA_SA150, "ICH6M" }, - { ATA_I82801GB, 0, 0, 0x00, ATA_UDMA5, "ICH7" }, - { ATA_I82801GB_S1, 0, AHCI, 0x00, ATA_SA300, "ICH7" }, - { ATA_I82801GB_R1, 0, AHCI, 0x00, ATA_SA300, "ICH7" }, - { ATA_I82801GB_AH, 0, AHCI, 0x00, ATA_SA300, "ICH7" }, - { ATA_I82801GBM_S1, 0, AHCI, 0x00, ATA_SA300, "ICH7M" }, - { ATA_I82801GBM_R1, 0, AHCI, 0x00, ATA_SA300, "ICH7M" }, - { ATA_I82801GBM_AH, 0, AHCI, 0x00, ATA_SA300, "ICH7M" }, - { ATA_I63XXESB2, 0, 0, 0x00, ATA_UDMA5, "63XXESB2" }, - { ATA_I63XXESB2_S1, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, - { ATA_I63XXESB2_S2, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, - { ATA_I63XXESB2_R1, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, - { ATA_I63XXESB2_R2, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, - { ATA_I82801HB_S1, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, - { ATA_I82801HB_S2, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, - { ATA_I82801HB_R1, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, - { ATA_I82801HB_AH4, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, - { ATA_I82801HB_AH6, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, - { ATA_I82801HBM, 0, 0, 0x00, ATA_UDMA5, "ICH8M" }, - { ATA_I82801HBM_S1, 0, 0, 0x00, ATA_SA150, "ICH8M" }, - { ATA_I82801HBM_S2, 0, AHCI, 0x00, ATA_SA300, "ICH8M" }, - { ATA_I82801HBM_S3, 0, AHCI, 0x00, ATA_SA300, "ICH8M" }, - { ATA_I82801IB_S1, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, - { ATA_I82801IB_S2, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, - { ATA_I82801IB_AH2, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, - { ATA_I82801IB_AH4, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, - { ATA_I82801IB_AH6, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, - { ATA_I82801IB_R1, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, - { ATA_I31244, 0, 0, 0x00, ATA_SA150, "31244" }, + {{ ATA_I82371FB, 0, 0, 2, ATA_WDMA2, "PIIX" }, + { ATA_I82371SB, 0, 0, 2, ATA_WDMA2, "PIIX3" }, + { ATA_I82371AB, 0, 0, 2, ATA_UDMA2, "PIIX4" }, + { ATA_I82443MX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, + { ATA_I82451NX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, + { ATA_I82801AB, 0, 0, 2, ATA_UDMA2, "ICH0" }, + { ATA_I82801AA, 0, 0, 2, ATA_UDMA4, "ICH" }, + { ATA_I82372FB, 0, 0, 2, ATA_UDMA4, "ICH" }, + { ATA_I82801BA, 0, 0, 2, ATA_UDMA5, "ICH2" }, + { ATA_I82801BA_1, 0, 0, 2, ATA_UDMA5, "ICH2" }, + { ATA_I82801CA, 0, 0, 2, ATA_UDMA5, "ICH3" }, + { ATA_I82801CA_1, 0, 0, 2, ATA_UDMA5, "ICH3" }, + { ATA_I82801DB, 0, 0, 2, ATA_UDMA5, "ICH4" }, + { ATA_I82801DB_1, 0, 0, 2, ATA_UDMA5, "ICH4" }, + { ATA_I82801EB, 0, 0, 2, ATA_UDMA5, "ICH5" }, + { ATA_I82801EB_S1, 0, 0, 2, ATA_SA150, "ICH5" }, + { ATA_I82801EB_R1, 0, 0, 2, ATA_SA150, "ICH5" }, + { ATA_I6300ESB, 0, 0, 2, ATA_UDMA5, "6300ESB" }, + { ATA_I6300ESB_S1, 0, 0, 2, ATA_SA150, "6300ESB" }, + { ATA_I6300ESB_R1, 0, 0, 2, ATA_SA150, "6300ESB" }, + { ATA_I82801FB, 0, 0, 2, ATA_UDMA5, "ICH6" }, + { ATA_I82801FB_S1, 0, AHCI, 0, ATA_SA150, "ICH6" }, + { ATA_I82801FB_R1, 0, AHCI, 0, ATA_SA150, "ICH6" }, + { ATA_I82801FBM, 0, AHCI, 0, ATA_SA150, "ICH6M" }, + { ATA_I82801GB, 0, 0, 1, ATA_UDMA5, "ICH7" }, + { ATA_I82801GB_S1, 0, AHCI, 0, ATA_SA300, "ICH7" }, + { ATA_I82801GB_R1, 0, AHCI, 0, ATA_SA300, "ICH7" }, + { ATA_I82801GB_AH, 0, AHCI, 0, ATA_SA300, "ICH7" }, + { ATA_I82801GBM_S1, 0, AHCI, 0, ATA_SA300, "ICH7M" }, + { ATA_I82801GBM_R1, 0, AHCI, 0, ATA_SA300, "ICH7M" }, + { ATA_I82801GBM_AH, 0, AHCI, 0, ATA_SA300, "ICH7M" }, + { ATA_I63XXESB2, 0, 0, 1, ATA_UDMA5, "63XXESB2" }, + { ATA_I63XXESB2_S1, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, + { ATA_I63XXESB2_S2, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, + { ATA_I63XXESB2_R1, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, + { ATA_I63XXESB2_R2, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, + { ATA_I82801HB_S1, 0, AHCI, 0, ATA_SA300, "ICH8" }, + { ATA_I82801HB_S2, 0, AHCI, 0, ATA_SA300, "ICH8" }, + { ATA_I82801HB_R1, 0, AHCI, 0, ATA_SA300, "ICH8" }, + { ATA_I82801HB_AH4, 0, AHCI, 0, ATA_SA300, "ICH8" }, + { ATA_I82801HB_AH6, 0, AHCI, 0, ATA_SA300, "ICH8" }, + { ATA_I82801HBM, 0, 0, 1, ATA_UDMA5, "ICH8M" }, + { ATA_I82801HBM_S1, 0, 0, 0, ATA_SA150, "ICH8M" }, + { ATA_I82801HBM_S2, 0, AHCI, 0, ATA_SA300, "ICH8M" }, + { ATA_I82801HBM_S3, 0, AHCI, 0, ATA_SA300, "ICH8M" }, + { ATA_I82801IB_S1, 0, AHCI, 0, ATA_SA300, "ICH9" }, + { ATA_I82801IB_S2, 0, AHCI, 0, ATA_SA300, "ICH9" }, + { ATA_I82801IB_AH2, 0, AHCI, 0, ATA_SA300, "ICH9" }, + { ATA_I82801IB_AH4, 0, AHCI, 0, ATA_SA300, "ICH9" }, + { ATA_I82801IB_AH6, 0, AHCI, 0, ATA_SA300, "ICH9" }, + { ATA_I82801IB_R1, 0, AHCI, 0, ATA_SA300, "ICH9" }, + { ATA_I31244, 0, 0, 2, ATA_SA150, "31244" }, { 0, 0, 0, 0, 0, 0}}; if (!(ctlr->chip = ata_match_chip(dev, ids))) @@ -1855,6 +1855,7 @@ /* non SATA intel chips goes here */ else if (ctlr->chip->max_dma < ATA_SA150) { + ctlr->channels = ctlr->chip->cfg2; ctlr->allocate = ata_intel_allocate; ctlr->setmode = ata_intel_new_setmode; } -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 17:30:38 2010 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 71170106566B; Mon, 1 Nov 2010 17:30:38 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by mx1.freebsd.org (Postfix) with ESMTP id 333618FC12; Mon, 1 Nov 2010 17:30:37 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UIwxwXvUYssOxfwg5EkHikzffh5rXYIO+yEEpiqJZg4boOpYdsvSPFa250cAsM4j; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1PCyDN-0002Hh-AB; Mon, 01 Nov 2010 13:30:37 -0400 Message-ID: <4CCEF93B.9030404@earthlink.net> Date: Mon, 01 Nov 2010 13:30:35 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7 MIME-Version: 1.0 To: John Baldwin References: <4CCAE59E.5020006@earthlink.net> <201010291720.11771.jhb@freebsd.org> <4CCEB4B7.6030006@earthlink.net> <201011010954.42574.jhb@freebsd.org> In-Reply-To: <201011010954.42574.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec790eca03d3c8958761ceaccf17c36f730c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: safe mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 17:30:38 -0000 On 11/01/2010 09:54 AM, John Baldwin wrote: > On Monday, November 01, 2010 8:38:15 am Stephen Clark wrote: > >> On 10/29/2010 05:20 PM, John Baldwin wrote: >> >>> On Friday, October 29, 2010 4:20:24 pm Stephen Clark wrote: >>> >>> >>>>> rr232x: RocketRAID 232x controller driver v1.02 (Jan 16 2008 04:16:21) >>>>> hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 04:16:19) >>>>> >>>>> >>>>> >>>> big snip >>>> >>>> >>>>> lo0: bpf attached >>>>> rr232x: no controller detected. >>>>> hptrr: no controller detected. >>>>> m >>>>> >>>>> >>>>> >>>> Why does FreeBSD think I have a rocket raid controller? This the generic >>>> kernel. >>>> Is there some way disable this from loading? >>>> >>>> >>> The hptrr driver is in GENERIC in 6.x and it always prints out the first >>> message. You can ignore it. >>> >>> >>> >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x0 >> atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 >> ata0: on atapci0 >> atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 >> atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 >> ata0: reset tp1 mask=03 ostat0=40 ostat1=40 >> ata0: stat0=0x0c err=0x0c lsb=0x0c msb=0x0c >> ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f >> ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f >> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 >> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 >> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 >> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 >> ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f >> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 >> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 >> ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f >> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 >> ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 >> ata0: reset tp2 stat0=87 stat1=87 devices=0x0 >> ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55 >> ata0: [MPSAFE] >> ata0: [ITHREAD] >> atapci1: port >> 0xc000-0xc007,0xbc00-0xbc03,0xb80 >> atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xb480 >> atapci1: [MPSAFE] >> atapci1: [ITHREAD] >> atapci1: Reserved 0x10 bytes for rid 0x24 type 4 at 0xb400 >> ata2: on atapci1 >> atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xc000 >> atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbc00 >> ata2: reset tp1 mask=03 ostat0=50 ostat1=00 >> ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 >> ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 >> ata2: reset tp2 stat0=50 stat1=00 devices=0x1 >> ata2: [MPSAFE] >> ata2: [ITHREAD] >> ata3: on atapci1 >> atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xb880 >> atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb800 >> ata3: reset tp1 mask=03 ostat0=7f ostat1=7f >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >> ata3: stat1=0x7f err=0xff lsb=0xff msb=0xff >> ata3: reset tp2 stat0=ff stat1=ff devices=0x0 >> ata3: [MPSAFE] >> ata3: [ITHREAD] >> .... >> ioapic0: Assigning ISA IRQ 1 to local APIC 0 >> ioapic0: Assigning ISA IRQ 4 to local APIC 2 >> ioapic0: Assigning ISA IRQ 9 to local APIC 0 >> ioapic0: Assigning ISA IRQ 14 to local APIC 2 >> ioapic0: Assigning PCI IRQ 16 to local APIC 0 >> ioapic0: Assigning PCI IRQ 18 to local APIC 2 >> ioapic0: Assigning PCI IRQ 19 to local APIC 0 >> ioapic0: Assigning PCI IRQ 21 to local APIC 2 >> ioapic0: Assigning PCI IRQ 23 to local APIC 0 >> msi: Assigning MSI IRQ 256 to local APIC 2 >> > Hmm, 7.2 does not register a handler for IRQ 15 at all, and it doesn't find a > second channel (ata1) on atapci0 either. I think that is probably the > difference. > > Try this patch: > > Index: ata-chipset.c > =================================================================== > --- ata-chipset.c (revision 214624) > +++ ata-chipset.c (working copy) > @@ -1762,58 +1762,58 @@ > { > struct ata_pci_controller *ctlr = device_get_softc(dev); > static struct ata_chip_id ids[] = > - {{ ATA_I82371FB, 0, 0, 0x00, ATA_WDMA2, "PIIX" }, > - { ATA_I82371SB, 0, 0, 0x00, ATA_WDMA2, "PIIX3" }, > - { ATA_I82371AB, 0, 0, 0x00, ATA_UDMA2, "PIIX4" }, > - { ATA_I82443MX, 0, 0, 0x00, ATA_UDMA2, "PIIX4" }, > - { ATA_I82451NX, 0, 0, 0x00, ATA_UDMA2, "PIIX4" }, > - { ATA_I82801AB, 0, 0, 0x00, ATA_UDMA2, "ICH0" }, > - { ATA_I82801AA, 0, 0, 0x00, ATA_UDMA4, "ICH" }, > - { ATA_I82372FB, 0, 0, 0x00, ATA_UDMA4, "ICH" }, > - { ATA_I82801BA, 0, 0, 0x00, ATA_UDMA5, "ICH2" }, > - { ATA_I82801BA_1, 0, 0, 0x00, ATA_UDMA5, "ICH2" }, > - { ATA_I82801CA, 0, 0, 0x00, ATA_UDMA5, "ICH3" }, > - { ATA_I82801CA_1, 0, 0, 0x00, ATA_UDMA5, "ICH3" }, > - { ATA_I82801DB, 0, 0, 0x00, ATA_UDMA5, "ICH4" }, > - { ATA_I82801DB_1, 0, 0, 0x00, ATA_UDMA5, "ICH4" }, > - { ATA_I82801EB, 0, 0, 0x00, ATA_UDMA5, "ICH5" }, > - { ATA_I82801EB_S1, 0, 0, 0x00, ATA_SA150, "ICH5" }, > - { ATA_I82801EB_R1, 0, 0, 0x00, ATA_SA150, "ICH5" }, > - { ATA_I6300ESB, 0, 0, 0x00, ATA_UDMA5, "6300ESB" }, > - { ATA_I6300ESB_S1, 0, 0, 0x00, ATA_SA150, "6300ESB" }, > - { ATA_I6300ESB_R1, 0, 0, 0x00, ATA_SA150, "6300ESB" }, > - { ATA_I82801FB, 0, 0, 0x00, ATA_UDMA5, "ICH6" }, > - { ATA_I82801FB_S1, 0, AHCI, 0x00, ATA_SA150, "ICH6" }, > - { ATA_I82801FB_R1, 0, AHCI, 0x00, ATA_SA150, "ICH6" }, > - { ATA_I82801FBM, 0, AHCI, 0x00, ATA_SA150, "ICH6M" }, > - { ATA_I82801GB, 0, 0, 0x00, ATA_UDMA5, "ICH7" }, > - { ATA_I82801GB_S1, 0, AHCI, 0x00, ATA_SA300, "ICH7" }, > - { ATA_I82801GB_R1, 0, AHCI, 0x00, ATA_SA300, "ICH7" }, > - { ATA_I82801GB_AH, 0, AHCI, 0x00, ATA_SA300, "ICH7" }, > - { ATA_I82801GBM_S1, 0, AHCI, 0x00, ATA_SA300, "ICH7M" }, > - { ATA_I82801GBM_R1, 0, AHCI, 0x00, ATA_SA300, "ICH7M" }, > - { ATA_I82801GBM_AH, 0, AHCI, 0x00, ATA_SA300, "ICH7M" }, > - { ATA_I63XXESB2, 0, 0, 0x00, ATA_UDMA5, "63XXESB2" }, > - { ATA_I63XXESB2_S1, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, > - { ATA_I63XXESB2_S2, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, > - { ATA_I63XXESB2_R1, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, > - { ATA_I63XXESB2_R2, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, > - { ATA_I82801HB_S1, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, > - { ATA_I82801HB_S2, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, > - { ATA_I82801HB_R1, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, > - { ATA_I82801HB_AH4, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, > - { ATA_I82801HB_AH6, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, > - { ATA_I82801HBM, 0, 0, 0x00, ATA_UDMA5, "ICH8M" }, > - { ATA_I82801HBM_S1, 0, 0, 0x00, ATA_SA150, "ICH8M" }, > - { ATA_I82801HBM_S2, 0, AHCI, 0x00, ATA_SA300, "ICH8M" }, > - { ATA_I82801HBM_S3, 0, AHCI, 0x00, ATA_SA300, "ICH8M" }, > - { ATA_I82801IB_S1, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, > - { ATA_I82801IB_S2, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, > - { ATA_I82801IB_AH2, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, > - { ATA_I82801IB_AH4, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, > - { ATA_I82801IB_AH6, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, > - { ATA_I82801IB_R1, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, > - { ATA_I31244, 0, 0, 0x00, ATA_SA150, "31244" }, > + {{ ATA_I82371FB, 0, 0, 2, ATA_WDMA2, "PIIX" }, > + { ATA_I82371SB, 0, 0, 2, ATA_WDMA2, "PIIX3" }, > + { ATA_I82371AB, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > + { ATA_I82443MX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > + { ATA_I82451NX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > + { ATA_I82801AB, 0, 0, 2, ATA_UDMA2, "ICH0" }, > + { ATA_I82801AA, 0, 0, 2, ATA_UDMA4, "ICH" }, > + { ATA_I82372FB, 0, 0, 2, ATA_UDMA4, "ICH" }, > + { ATA_I82801BA, 0, 0, 2, ATA_UDMA5, "ICH2" }, > + { ATA_I82801BA_1, 0, 0, 2, ATA_UDMA5, "ICH2" }, > + { ATA_I82801CA, 0, 0, 2, ATA_UDMA5, "ICH3" }, > + { ATA_I82801CA_1, 0, 0, 2, ATA_UDMA5, "ICH3" }, > + { ATA_I82801DB, 0, 0, 2, ATA_UDMA5, "ICH4" }, > + { ATA_I82801DB_1, 0, 0, 2, ATA_UDMA5, "ICH4" }, > + { ATA_I82801EB, 0, 0, 2, ATA_UDMA5, "ICH5" }, > + { ATA_I82801EB_S1, 0, 0, 2, ATA_SA150, "ICH5" }, > + { ATA_I82801EB_R1, 0, 0, 2, ATA_SA150, "ICH5" }, > + { ATA_I6300ESB, 0, 0, 2, ATA_UDMA5, "6300ESB" }, > + { ATA_I6300ESB_S1, 0, 0, 2, ATA_SA150, "6300ESB" }, > + { ATA_I6300ESB_R1, 0, 0, 2, ATA_SA150, "6300ESB" }, > + { ATA_I82801FB, 0, 0, 2, ATA_UDMA5, "ICH6" }, > + { ATA_I82801FB_S1, 0, AHCI, 0, ATA_SA150, "ICH6" }, > + { ATA_I82801FB_R1, 0, AHCI, 0, ATA_SA150, "ICH6" }, > + { ATA_I82801FBM, 0, AHCI, 0, ATA_SA150, "ICH6M" }, > + { ATA_I82801GB, 0, 0, 1, ATA_UDMA5, "ICH7" }, > + { ATA_I82801GB_S1, 0, AHCI, 0, ATA_SA300, "ICH7" }, > + { ATA_I82801GB_R1, 0, AHCI, 0, ATA_SA300, "ICH7" }, > + { ATA_I82801GB_AH, 0, AHCI, 0, ATA_SA300, "ICH7" }, > + { ATA_I82801GBM_S1, 0, AHCI, 0, ATA_SA300, "ICH7M" }, > + { ATA_I82801GBM_R1, 0, AHCI, 0, ATA_SA300, "ICH7M" }, > + { ATA_I82801GBM_AH, 0, AHCI, 0, ATA_SA300, "ICH7M" }, > + { ATA_I63XXESB2, 0, 0, 1, ATA_UDMA5, "63XXESB2" }, > + { ATA_I63XXESB2_S1, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, > + { ATA_I63XXESB2_S2, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, > + { ATA_I63XXESB2_R1, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, > + { ATA_I63XXESB2_R2, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, > + { ATA_I82801HB_S1, 0, AHCI, 0, ATA_SA300, "ICH8" }, > + { ATA_I82801HB_S2, 0, AHCI, 0, ATA_SA300, "ICH8" }, > + { ATA_I82801HB_R1, 0, AHCI, 0, ATA_SA300, "ICH8" }, > + { ATA_I82801HB_AH4, 0, AHCI, 0, ATA_SA300, "ICH8" }, > + { ATA_I82801HB_AH6, 0, AHCI, 0, ATA_SA300, "ICH8" }, > + { ATA_I82801HBM, 0, 0, 1, ATA_UDMA5, "ICH8M" }, > + { ATA_I82801HBM_S1, 0, 0, 0, ATA_SA150, "ICH8M" }, > + { ATA_I82801HBM_S2, 0, AHCI, 0, ATA_SA300, "ICH8M" }, > + { ATA_I82801HBM_S3, 0, AHCI, 0, ATA_SA300, "ICH8M" }, > + { ATA_I82801IB_S1, 0, AHCI, 0, ATA_SA300, "ICH9" }, > + { ATA_I82801IB_S2, 0, AHCI, 0, ATA_SA300, "ICH9" }, > + { ATA_I82801IB_AH2, 0, AHCI, 0, ATA_SA300, "ICH9" }, > + { ATA_I82801IB_AH4, 0, AHCI, 0, ATA_SA300, "ICH9" }, > + { ATA_I82801IB_AH6, 0, AHCI, 0, ATA_SA300, "ICH9" }, > + { ATA_I82801IB_R1, 0, AHCI, 0, ATA_SA300, "ICH9" }, > + { ATA_I31244, 0, 0, 2, ATA_SA150, "31244" }, > { 0, 0, 0, 0, 0, 0}}; > > if (!(ctlr->chip = ata_match_chip(dev, ids))) > @@ -1855,6 +1855,7 @@ > > /* non SATA intel chips goes here */ > else if (ctlr->chip->max_dma< ATA_SA150) { > + ctlr->channels = ctlr->chip->cfg2; > ctlr->allocate = ata_intel_allocate; > ctlr->setmode = ata_intel_new_setmode; > } > > > Hi John, I tried the patch - same results - Also the patch did not apply cleanly, there were 3 chipset ids that were not in the 6.3 code, I fixed the patch by hand. One thing that sort of confuses me is the last bit of the patch /* non SATA intel chips goes here */ else if (ctlr->chip->max_dma< ATA_SA150) { + ctlr->channels = ctlr->chip->cfg2; ctlr->allocate = ata_intel_allocate; ctlr->setmode = ata_intel_new_setmode; } since the drive is identified as SATA300: ad4: 152627MB at ata2-master SATA300 ad4: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 17:42:55 2010 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 B48C21065670 for ; Mon, 1 Nov 2010 17:42:55 +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 5F8948FC1B for ; Mon, 1 Nov 2010 17:42:55 +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 DF1AC46B09; Mon, 1 Nov 2010 13:42:54 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5A1598A009; Mon, 1 Nov 2010 13:42:53 -0400 (EDT) From: John Baldwin To: sclark46@earthlink.net Date: Mon, 1 Nov 2010 13:42:48 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CCAE59E.5020006@earthlink.net> <201011010954.42574.jhb@freebsd.org> <4CCEF93B.9030404@earthlink.net> In-Reply-To: <4CCEF93B.9030404@earthlink.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011011342.48384.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 01 Nov 2010 13:42:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: safe mode 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, 01 Nov 2010 17:42:55 -0000 On Monday, November 01, 2010 1:30:35 pm Stephen Clark wrote: > On 11/01/2010 09:54 AM, John Baldwin wrote: > > On Monday, November 01, 2010 8:38:15 am Stephen Clark wrote: > > > >> On 10/29/2010 05:20 PM, John Baldwin wrote: > >> > >>> On Friday, October 29, 2010 4:20:24 pm Stephen Clark wrote: > >>> > >>> > >>>>> rr232x: RocketRAID 232x controller driver v1.02 (Jan 16 2008 04:16:21) > >>>>> hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 04:16:19) > >>>>> > >>>>> > >>>>> > >>>> big snip > >>>> > >>>> > >>>>> lo0: bpf attached > >>>>> rr232x: no controller detected. > >>>>> hptrr: no controller detected. > >>>>> m > >>>>> > >>>>> > >>>>> > >>>> Why does FreeBSD think I have a rocket raid controller? This the generic > >>>> kernel. > >>>> Is there some way disable this from loading? > >>>> > >>>> > >>> The hptrr driver is in GENERIC in 6.x and it always prints out the first > >>> message. You can ignore it. > >>> > >>> > >>> > >> atapci0: port > >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x0 > >> atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 > >> ata0: on atapci0 > >> atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > >> atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > >> ata0: reset tp1 mask=03 ostat0=40 ostat1=40 > >> ata0: stat0=0x0c err=0x0c lsb=0x0c msb=0x0c > >> ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f > >> ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f > >> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > >> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > >> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > >> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > >> ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f > >> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > >> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > >> ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f > >> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > >> ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 > >> ata0: reset tp2 stat0=87 stat1=87 devices=0x0 > >> ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55 > >> ata0: [MPSAFE] > >> ata0: [ITHREAD] > >> atapci1: port > >> 0xc000-0xc007,0xbc00-0xbc03,0xb80 > >> atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xb480 > >> atapci1: [MPSAFE] > >> atapci1: [ITHREAD] > >> atapci1: Reserved 0x10 bytes for rid 0x24 type 4 at 0xb400 > >> ata2: on atapci1 > >> atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xc000 > >> atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbc00 > >> ata2: reset tp1 mask=03 ostat0=50 ostat1=00 > >> ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > >> ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 > >> ata2: reset tp2 stat0=50 stat1=00 devices=0x1 > >> ata2: [MPSAFE] > >> ata2: [ITHREAD] > >> ata3: on atapci1 > >> atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xb880 > >> atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb800 > >> ata3: reset tp1 mask=03 ostat0=7f ostat1=7f > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: stat1=0x7f err=0xff lsb=0xff msb=0xff > >> ata3: reset tp2 stat0=ff stat1=ff devices=0x0 > >> ata3: [MPSAFE] > >> ata3: [ITHREAD] > >> .... > >> ioapic0: Assigning ISA IRQ 1 to local APIC 0 > >> ioapic0: Assigning ISA IRQ 4 to local APIC 2 > >> ioapic0: Assigning ISA IRQ 9 to local APIC 0 > >> ioapic0: Assigning ISA IRQ 14 to local APIC 2 > >> ioapic0: Assigning PCI IRQ 16 to local APIC 0 > >> ioapic0: Assigning PCI IRQ 18 to local APIC 2 > >> ioapic0: Assigning PCI IRQ 19 to local APIC 0 > >> ioapic0: Assigning PCI IRQ 21 to local APIC 2 > >> ioapic0: Assigning PCI IRQ 23 to local APIC 0 > >> msi: Assigning MSI IRQ 256 to local APIC 2 > >> > > Hmm, 7.2 does not register a handler for IRQ 15 at all, and it doesn't find a > > second channel (ata1) on atapci0 either. I think that is probably the > > difference. > > > > Try this patch: > > > > Index: ata-chipset.c > > =================================================================== > > --- ata-chipset.c (revision 214624) > > +++ ata-chipset.c (working copy) > > @@ -1762,58 +1762,58 @@ > > { > > struct ata_pci_controller *ctlr = device_get_softc(dev); > > static struct ata_chip_id ids[] = > > - {{ ATA_I82371FB, 0, 0, 0x00, ATA_WDMA2, "PIIX" }, > > - { ATA_I82371SB, 0, 0, 0x00, ATA_WDMA2, "PIIX3" }, > > - { ATA_I82371AB, 0, 0, 0x00, ATA_UDMA2, "PIIX4" }, > > - { ATA_I82443MX, 0, 0, 0x00, ATA_UDMA2, "PIIX4" }, > > - { ATA_I82451NX, 0, 0, 0x00, ATA_UDMA2, "PIIX4" }, > > - { ATA_I82801AB, 0, 0, 0x00, ATA_UDMA2, "ICH0" }, > > - { ATA_I82801AA, 0, 0, 0x00, ATA_UDMA4, "ICH" }, > > - { ATA_I82372FB, 0, 0, 0x00, ATA_UDMA4, "ICH" }, > > - { ATA_I82801BA, 0, 0, 0x00, ATA_UDMA5, "ICH2" }, > > - { ATA_I82801BA_1, 0, 0, 0x00, ATA_UDMA5, "ICH2" }, > > - { ATA_I82801CA, 0, 0, 0x00, ATA_UDMA5, "ICH3" }, > > - { ATA_I82801CA_1, 0, 0, 0x00, ATA_UDMA5, "ICH3" }, > > - { ATA_I82801DB, 0, 0, 0x00, ATA_UDMA5, "ICH4" }, > > - { ATA_I82801DB_1, 0, 0, 0x00, ATA_UDMA5, "ICH4" }, > > - { ATA_I82801EB, 0, 0, 0x00, ATA_UDMA5, "ICH5" }, > > - { ATA_I82801EB_S1, 0, 0, 0x00, ATA_SA150, "ICH5" }, > > - { ATA_I82801EB_R1, 0, 0, 0x00, ATA_SA150, "ICH5" }, > > - { ATA_I6300ESB, 0, 0, 0x00, ATA_UDMA5, "6300ESB" }, > > - { ATA_I6300ESB_S1, 0, 0, 0x00, ATA_SA150, "6300ESB" }, > > - { ATA_I6300ESB_R1, 0, 0, 0x00, ATA_SA150, "6300ESB" }, > > - { ATA_I82801FB, 0, 0, 0x00, ATA_UDMA5, "ICH6" }, > > - { ATA_I82801FB_S1, 0, AHCI, 0x00, ATA_SA150, "ICH6" }, > > - { ATA_I82801FB_R1, 0, AHCI, 0x00, ATA_SA150, "ICH6" }, > > - { ATA_I82801FBM, 0, AHCI, 0x00, ATA_SA150, "ICH6M" }, > > - { ATA_I82801GB, 0, 0, 0x00, ATA_UDMA5, "ICH7" }, > > - { ATA_I82801GB_S1, 0, AHCI, 0x00, ATA_SA300, "ICH7" }, > > - { ATA_I82801GB_R1, 0, AHCI, 0x00, ATA_SA300, "ICH7" }, > > - { ATA_I82801GB_AH, 0, AHCI, 0x00, ATA_SA300, "ICH7" }, > > - { ATA_I82801GBM_S1, 0, AHCI, 0x00, ATA_SA300, "ICH7M" }, > > - { ATA_I82801GBM_R1, 0, AHCI, 0x00, ATA_SA300, "ICH7M" }, > > - { ATA_I82801GBM_AH, 0, AHCI, 0x00, ATA_SA300, "ICH7M" }, > > - { ATA_I63XXESB2, 0, 0, 0x00, ATA_UDMA5, "63XXESB2" }, > > - { ATA_I63XXESB2_S1, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, > > - { ATA_I63XXESB2_S2, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, > > - { ATA_I63XXESB2_R1, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, > > - { ATA_I63XXESB2_R2, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, > > - { ATA_I82801HB_S1, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, > > - { ATA_I82801HB_S2, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, > > - { ATA_I82801HB_R1, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, > > - { ATA_I82801HB_AH4, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, > > - { ATA_I82801HB_AH6, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, > > - { ATA_I82801HBM, 0, 0, 0x00, ATA_UDMA5, "ICH8M" }, > > - { ATA_I82801HBM_S1, 0, 0, 0x00, ATA_SA150, "ICH8M" }, > > - { ATA_I82801HBM_S2, 0, AHCI, 0x00, ATA_SA300, "ICH8M" }, > > - { ATA_I82801HBM_S3, 0, AHCI, 0x00, ATA_SA300, "ICH8M" }, > > - { ATA_I82801IB_S1, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, > > - { ATA_I82801IB_S2, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, > > - { ATA_I82801IB_AH2, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, > > - { ATA_I82801IB_AH4, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, > > - { ATA_I82801IB_AH6, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, > > - { ATA_I82801IB_R1, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, > > - { ATA_I31244, 0, 0, 0x00, ATA_SA150, "31244" }, > > + {{ ATA_I82371FB, 0, 0, 2, ATA_WDMA2, "PIIX" }, > > + { ATA_I82371SB, 0, 0, 2, ATA_WDMA2, "PIIX3" }, > > + { ATA_I82371AB, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > > + { ATA_I82443MX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > > + { ATA_I82451NX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > > + { ATA_I82801AB, 0, 0, 2, ATA_UDMA2, "ICH0" }, > > + { ATA_I82801AA, 0, 0, 2, ATA_UDMA4, "ICH" }, > > + { ATA_I82372FB, 0, 0, 2, ATA_UDMA4, "ICH" }, > > + { ATA_I82801BA, 0, 0, 2, ATA_UDMA5, "ICH2" }, > > + { ATA_I82801BA_1, 0, 0, 2, ATA_UDMA5, "ICH2" }, > > + { ATA_I82801CA, 0, 0, 2, ATA_UDMA5, "ICH3" }, > > + { ATA_I82801CA_1, 0, 0, 2, ATA_UDMA5, "ICH3" }, > > + { ATA_I82801DB, 0, 0, 2, ATA_UDMA5, "ICH4" }, > > + { ATA_I82801DB_1, 0, 0, 2, ATA_UDMA5, "ICH4" }, > > + { ATA_I82801EB, 0, 0, 2, ATA_UDMA5, "ICH5" }, > > + { ATA_I82801EB_S1, 0, 0, 2, ATA_SA150, "ICH5" }, > > + { ATA_I82801EB_R1, 0, 0, 2, ATA_SA150, "ICH5" }, > > + { ATA_I6300ESB, 0, 0, 2, ATA_UDMA5, "6300ESB" }, > > + { ATA_I6300ESB_S1, 0, 0, 2, ATA_SA150, "6300ESB" }, > > + { ATA_I6300ESB_R1, 0, 0, 2, ATA_SA150, "6300ESB" }, > > + { ATA_I82801FB, 0, 0, 2, ATA_UDMA5, "ICH6" }, > > + { ATA_I82801FB_S1, 0, AHCI, 0, ATA_SA150, "ICH6" }, > > + { ATA_I82801FB_R1, 0, AHCI, 0, ATA_SA150, "ICH6" }, > > + { ATA_I82801FBM, 0, AHCI, 0, ATA_SA150, "ICH6M" }, > > + { ATA_I82801GB, 0, 0, 1, ATA_UDMA5, "ICH7" }, > > + { ATA_I82801GB_S1, 0, AHCI, 0, ATA_SA300, "ICH7" }, > > + { ATA_I82801GB_R1, 0, AHCI, 0, ATA_SA300, "ICH7" }, > > + { ATA_I82801GB_AH, 0, AHCI, 0, ATA_SA300, "ICH7" }, > > + { ATA_I82801GBM_S1, 0, AHCI, 0, ATA_SA300, "ICH7M" }, > > + { ATA_I82801GBM_R1, 0, AHCI, 0, ATA_SA300, "ICH7M" }, > > + { ATA_I82801GBM_AH, 0, AHCI, 0, ATA_SA300, "ICH7M" }, > > + { ATA_I63XXESB2, 0, 0, 1, ATA_UDMA5, "63XXESB2" }, > > + { ATA_I63XXESB2_S1, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, > > + { ATA_I63XXESB2_S2, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, > > + { ATA_I63XXESB2_R1, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, > > + { ATA_I63XXESB2_R2, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, > > + { ATA_I82801HB_S1, 0, AHCI, 0, ATA_SA300, "ICH8" }, > > + { ATA_I82801HB_S2, 0, AHCI, 0, ATA_SA300, "ICH8" }, > > + { ATA_I82801HB_R1, 0, AHCI, 0, ATA_SA300, "ICH8" }, > > + { ATA_I82801HB_AH4, 0, AHCI, 0, ATA_SA300, "ICH8" }, > > + { ATA_I82801HB_AH6, 0, AHCI, 0, ATA_SA300, "ICH8" }, > > + { ATA_I82801HBM, 0, 0, 1, ATA_UDMA5, "ICH8M" }, > > + { ATA_I82801HBM_S1, 0, 0, 0, ATA_SA150, "ICH8M" }, > > + { ATA_I82801HBM_S2, 0, AHCI, 0, ATA_SA300, "ICH8M" }, > > + { ATA_I82801HBM_S3, 0, AHCI, 0, ATA_SA300, "ICH8M" }, > > + { ATA_I82801IB_S1, 0, AHCI, 0, ATA_SA300, "ICH9" }, > > + { ATA_I82801IB_S2, 0, AHCI, 0, ATA_SA300, "ICH9" }, > > + { ATA_I82801IB_AH2, 0, AHCI, 0, ATA_SA300, "ICH9" }, > > + { ATA_I82801IB_AH4, 0, AHCI, 0, ATA_SA300, "ICH9" }, > > + { ATA_I82801IB_AH6, 0, AHCI, 0, ATA_SA300, "ICH9" }, > > + { ATA_I82801IB_R1, 0, AHCI, 0, ATA_SA300, "ICH9" }, > > + { ATA_I31244, 0, 0, 2, ATA_SA150, "31244" }, > > { 0, 0, 0, 0, 0, 0}}; > > > > if (!(ctlr->chip = ata_match_chip(dev, ids))) > > @@ -1855,6 +1855,7 @@ > > > > /* non SATA intel chips goes here */ > > else if (ctlr->chip->max_dma< ATA_SA150) { > > + ctlr->channels = ctlr->chip->cfg2; > > ctlr->allocate = ata_intel_allocate; > > ctlr->setmode = ata_intel_new_setmode; > > } > > > > > > > Hi John, > > I tried the patch - same results - Also the patch did not apply cleanly, > there were 3 chipset ids that were not in > the 6.3 code, I fixed the patch by hand. One thing that sort of confuses > me is the last bit of the patch > > /* non SATA intel chips goes here */ > else if (ctlr->chip->max_dma< ATA_SA150) { > + ctlr->channels = ctlr->chip->cfg2; > ctlr->allocate = ata_intel_allocate; > ctlr->setmode = ata_intel_new_setmode; > } > > since the drive is identified as SATA300: > > ad4: 152627MB at ata2-master SATA300 > ad4: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue > GEOM: new disk ad4 The point is to limit atapci0 to only having an ata0 and no ata1, then it will not register an interrupt handler for IRQ15 and get a constant storm of interrupts. Can you get a verbose dmesg from the patched kernel if possible and the pciconf -l lines for atapci0 and atapci1 (the pciconf can be from any working kernel). -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 18:05:52 2010 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 DA685106566B; Mon, 1 Nov 2010 18:05:52 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by mx1.freebsd.org (Postfix) with ESMTP id 812D58FC16; Mon, 1 Nov 2010 18:05:52 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=U37/aqKK6O2vhh80WC/EP0+UF080If/zkBkwQBSjVgcGgDYdfUis/NWXCf/0r7su; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1PCylT-0002Hl-Fx; Mon, 01 Nov 2010 14:05:51 -0400 Message-ID: <4CCF017D.6080402@earthlink.net> Date: Mon, 01 Nov 2010 14:05:49 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7 MIME-Version: 1.0 To: John Baldwin References: <4CCAE59E.5020006@earthlink.net> <201011010954.42574.jhb@freebsd.org> <4CCEF93B.9030404@earthlink.net> <201011011342.48384.jhb@freebsd.org> In-Reply-To: <201011011342.48384.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79149cc829069ff689c07bddd6634c3d24350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: safe mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 18:05:52 -0000 On 11/01/2010 01:42 PM, John Baldwin wrote: > On Monday, November 01, 2010 1:30:35 pm Stephen Clark wrote: > >> On 11/01/2010 09:54 AM, John Baldwin wrote: >> >>> On Monday, November 01, 2010 8:38:15 am Stephen Clark wrote: >>> >>> >>>> On 10/29/2010 05:20 PM, John Baldwin wrote: >>>> >>>> >>>>> On Friday, October 29, 2010 4:20:24 pm Stephen Clark wrote: >>>>> >>>>> >>>>> >>>>>>> rr232x: RocketRAID 232x controller driver v1.02 (Jan 16 2008 04:16:21) >>>>>>> hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 04:16:19) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> big snip >>>>>> >>>>>> >>>>>> >>>>>>> lo0: bpf attached >>>>>>> rr232x: no controller detected. >>>>>>> hptrr: no controller detected. >>>>>>> m >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Why does FreeBSD think I have a rocket raid controller? This the >>>>>> > generic > >>>>>> kernel. >>>>>> Is there some way disable this from loading? >>>>>> >>>>>> >>>>>> >>>>> The hptrr driver is in GENERIC in 6.x and it always prints out the first >>>>> message. You can ignore it. >>>>> >>>>> >>>>> >>>>> >>>> atapci0: port >>>> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x0 > > The point is to limit atapci0 to only having an ata0 and no ata1, then it will > not register an interrupt handler for IRQ15 and get a constant storm of > interrupts. Can you get a verbose dmesg from the patched kernel if possible > and the pciconf -l lines for atapci0 and atapci1 (the pciconf can be from any > working kernel). > > John, Is the pciconf -lv I posted in my initial message sufficient? verbose patched kernel: generic with patch ��SMAP type=01 base=0000000000000000 len=000000000009fc00 SMAP type=02 base=000000000009fc00 len=0000000000000400 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=000000003f9a0000 SMAP type=03 base=000000003faa0000 len=000000000000e000 SMAP type=04 base=000000003faae000 len=0000000000032000 SMAP type=02 base=000000003fae0000 len=0000000000010000 SMAP type=02 base=000000003faf0000 len=0000000000010000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ffb00000 len=0000000000500000 Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-RELEASE-p15 #9: Mon Nov 1 12:38:10 EDT 2010 root@sclark.netwolvesrd.com:/usr/src/sys/i386/compile/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0bff000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0bff1ac. MP Configuration Table version 1.4 found at 0xc00fdc90 Table 'FACP' at 0x3faa0290 Table 'APIC' at 0x3faa0390 MADT: Found table at 0x3faa0390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled MADT: Found CPU APIC ID 2 ACPI ID 2: enabled MADT: Found CPU APIC ID 1 ACPI ID 3: enabled MADT: Found CPU APIC ID 3 ACPI ID 4: enabled ACPI APIC Table: <080610 APIC1657> Calibrating clock(s) ... i8254 clock: 1188442 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1673322970 Hz CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1673.32-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106ca Stepping = 10 Features=0xbfebfbff Features2=0x40e31d> AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 Logical CPUs per core: 2 real memory = 1068105728 (1018 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000003e86ffff, 1036300288 bytes (253003 pages) avail memory = 1036201984 (988 MB) bios32: Found BIOS32 Service Directory header at 0xc00f0000 bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x31 pnpbios: Found PnP BIOS data at 0xc00f6100 pnpbios: Entry = f0000:78ba Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 MADT: Found IO APIC ID 4, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 4 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 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Nov 1 2010 12:37:49) hptrr: HPT RocketRAID controller driver v1.1 (Nov 1 2010 12:37:46) npx0: INT 16 interface acpi0: <080610 XSDT1657> on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=a0008086) pcibios: BIOS version 3.00 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0 acpi0: Power Button (fixed) acpi0: wakeup code va 0xd8a56000 pa 0x9e000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.FHR0 -> bus 0 dev 31 func 0 acpi0: reservation of ffc00000, 300000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 6 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 cpu0: on acpi0 cpu0: switching to generic Cx mode pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0xa000, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0xa001, revid=0x02 bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type 1, range 32, base fe980000, size 19, enabled map[14]: type 4, range 32, base 0000cc00, size 3, enabled map[18]: type 3, range 32, base d0000000, size 28, enabled map[1c]: type 1, range 32, base fe800000, size 20, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0xa002, revid=0x02 bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base fe780000, size 19, enabled found-> vendor=0x8086, dev=0x2834, revid=0x03 bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type 4, range 32, base 0000c880, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2835, revid=0x03 bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type 4, range 32, base 0000c800, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x283a, revid=0x03 bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, 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 1, range 32, base fe977c00, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x283f, revid=0x03 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 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 22 found-> vendor=0x8086, dev=0x2845, revid=0x03 bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 21 found-> vendor=0x8086, dev=0x2830, revid=0x03 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 map[20]: type 4, range 32, base 0000c480, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2831, revid=0x03 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 0000c400, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2832, revid=0x03 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[20]: type 4, range 32, base 0000c080, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x2836, revid=0x03 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base fe977800, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xf3 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=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2815, revid=0x03 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=0x2850, revid=0x03 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x8086, dev=0x2828, revid=0x03 bus=0, slot=31, func=2 class=01-01-8f, 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=15 powerspec 3 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000c000, size 3, enabled map[14]: type 4, range 32, base 0000bc00, size 2, enabled map[18]: type 4, range 32, base 0000b880, size 3, enabled map[1c]: type 4, range 32, base 0000b800, size 2, enabled map[20]: type 4, range 32, base 0000b480, size 4, enabled map[24]: type 4, range 32, base 0000b400, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 18 found-> vendor=0x8086, dev=0x283e, revid=0x03 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0103, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type 1, range 32, base fe977400, size 8, enabled map[20]: type 4, range 32, base 00000400, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 17 pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) uhci0: port 0xc880-0xc89f irq 16 at device 26.00 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc880 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc800-0xc81f irq 21 at device 26.10 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc800 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 50 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xfe977c00-0xfe977fff irq 18 at 0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfe977c00 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered pcib1: irq 22 at device 28.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: memory decode 0x0-0x0 pcib1: prefetched decode 0x0-0x0 pci1: on pcib1 pci1: physical bus=1 pcib2: irq 21 at device 28.3 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfea00000-0xfeafffff pcib2: prefetched decode 0xfdf00000-0xfdffffff pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x10ec, dev=0x8168, revid=0x03 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 4 messages in map 0x20 map[10]: type 4, range 32, base 0000d800, size 8, enabled pcib2: requested I/O range 0xd800-0xd8ff: in range map[18]: type 3, range 64, base fdfff000, size 12, enabled pcib2: requested memory range 0xfdfff000-0xfdffffff: good map[20]: type 3, range 64, base fdff8000, size 14, enabled pcib2: requested memory range 0xfdff8000-0xfdffbfff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 19 re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xd800 pcib2: re0 requested I/O range 0xd800-0xd8ff: in range pcib2: re0 requested I/O range 0xd800-0xd8ff: in range pcib2: re0 requested I/O range 0xd800-0xd8ff: in range pcib2: re0 requested I/O range 0xd800-0xd8ff: in range pcib2: re0 requested I/O range 0xd800-0xd8ff: in range pci2: at device 0.0 (no driver attached) uhci2: port 0xc480-0xc49f irq 23 at device 29.00 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc480 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 52 uhci2: [GIANT-LOCKED] usb3: on uhci2 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered uhci3: port 0xc400-0xc41f irq 19 at device 29.10 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc400 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 53 uhci3: [GIANT-LOCKED] usb4: on uhci3 usb4: USB revision 1.0 uhub4: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xc080-0xc09f irq 18 at device 29.20 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc080 uhci4: [GIANT-LOCKED] usb5: on uhci4 usb5: USB revision 1.0 uhub5: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xfe977800-0xfe977bff irq 23 at 0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfe977800 ehci1: [GIANT-LOCKED] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub6: 6 ports with 6 removable, self powered umass0: HP v100w, rev 2.00/20.48, addr 2 umass0:0:0:-1: Attached to scbus0 pcib3: at device 30.0 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xe000-0xefff pcib3: memory decode 0xfeb00000-0xfebfffff pcib3: prefetched decode 0xfff00000-0xfffff pcib3: Subtractively decoded bridge. pci3: on pcib3 pci3: physical bus=3 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=3, slot=4, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=15 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e800, size 8, enabled pcib3: requested I/O range 0xe800-0xe8ff: in range map[14]: type 1, range 32, base febffc00, size 8, enabled pcib3: requested memory range 0xfebffc00-0xfebffcff: good pcib3: matched entry for 3.4.INTA pcib3: slot 4 INTA hardwired to IRQ 18 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=3, slot=6, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e400, size 8, enabled pcib3: requested I/O range 0xe400-0xe4ff: in range map[14]: type 1, range 32, base febff800, size 8, enabled pcib3: requested memory range 0xfebff800-0xfebff8ff: good pcib3: matched entry for 3.6.INTA pcib3: slot 6 INTA hardwired to IRQ 19 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=3, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e000, size 8, enabled pcib3: requested I/O range 0xe000-0xe0ff: in range map[14]: type 1, range 32, base febff400, size 8, enabled pcib3: requested memory range 0xfebff400-0xfebff4ff: good pcib3: matched entry for 3.7.INTA pcib3: slot 7 INTA hardwired to IRQ 16 re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe800 pcib3: rl0 requested I/O range 0xe800-0xe8ff: in range pcib3: rl0 requested I/O range 0xe800-0xe8ff: in range rl0: port 0xe800-0xe8ff mem 0xfebffc00-0xfebffcff i3 pcib3: rl0 requested I/O range 0xe800-0xe8ff: in range miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: bpf attached rl0: Ethernet address: 00:30:18:a1:7f:e9 rl0: [MPSAFE] re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe400 pcib3: rl1 requested I/O range 0xe400-0xe4ff: in range pcib3: rl1 requested I/O range 0xe400-0xe4ff: in range rl1: port 0xe400-0xe4ff mem 0xfebff800-0xfebff8ff i3 pcib3: rl1 requested I/O range 0xe400-0xe4ff: in range miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: bpf attached rl1: Ethernet address: 00:30:18:a1:7f:ea rl1: [MPSAFE] re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe000 pcib3: rl2 requested I/O range 0xe000-0xe0ff: in range pcib3: rl2 requested I/O range 0xe000-0xe0ff: in range rl2: port 0xe000-0xe0ff mem 0xfebff400-0xfebff4ff i3 pcib3: rl2 requested I/O range 0xe000-0xe0ff: in range miibus2: on rl2 rlphy2: on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl2: bpf attached rl2: Ethernet address: 00:30:18:a1:7f:eb rl2: [MPSAFE] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa00 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=00 ostat1=00 ata0: stat0=0x0c err=0x0c lsb=0x0c msb=0x0c ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x03 err=0x03 lsb=0x03 msb=0x03 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 ata0: reset tp2 stat0=8f stat1=87 devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 55 ata1: [MPSAFE] atapci1: port 0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xb480 atapci1: [MPSAFE] ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xc000 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbc00 ata2: reset tp1 mask=03 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xb880 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb800 ata3: reset tp1 mask=03 ostat0=7f ostat1=7f ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat1=0x7f err=0xff lsb=0xff msb=0xff ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: [MPSAFE] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console ioapic0: Changing trigger for pin 4 to level ioapic0: Changing polarity for pin 4 to low ioapic0: routing intpin 4 (ISA IRQ 4) to vector 56 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x83ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 83666161 hz Timecounter "TSC" frequency 1673322970 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: no controller detected. hptrr: no controller detected. ďż˝ -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 18:26:25 2010 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 DEAA6106564A for ; Mon, 1 Nov 2010 18:26:25 +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 B0A038FC17 for ; Mon, 1 Nov 2010 18:26:25 +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 3883746B65; Mon, 1 Nov 2010 14:26:25 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 237A08A009; Mon, 1 Nov 2010 14:26:24 -0400 (EDT) From: John Baldwin To: sclark46@earthlink.net Date: Mon, 1 Nov 2010 14:24:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CCAE59E.5020006@earthlink.net> <201011011342.48384.jhb@freebsd.org> <4CCF017D.6080402@earthlink.net> In-Reply-To: <4CCF017D.6080402@earthlink.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011011424.00315.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 01 Nov 2010 14:26:24 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: safe mode 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, 01 Nov 2010 18:26:25 -0000 On Monday, November 01, 2010 2:05:49 pm Stephen Clark wrote: > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa00 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 > ata0: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=03 ostat0=00 ostat1=00 > ata0: stat0=0x0c err=0x0c lsb=0x0c msb=0x0c > ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat0=0x03 err=0x03 lsb=0x03 msb=0x03 > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f > ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 > ata0: reset tp2 stat0=8f stat1=87 devices=0x0 > ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 > ata0: [MPSAFE] > ata1: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 > atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 > ata1: reset tp1 mask=00 ostat0=ff ostat1=ff > ioapic0: routing intpin 15 (ISA IRQ 15) to vector 55 > ata1: [MPSAFE] I think the fact that it says 'Intel ATA controller' here means that the ata- chipset.c you are using doesn't have the exact PCI ID for the ICH8M, so probably my change to restrict it to just using ata0 isn't work. Note that you still have an ata1 device here. The patch should cause the driver to skip over ata1. When you hacked the patch to apply to 6.3, did you make sure and add any intel chipsets that weren't already present in the 6.3 ata-chipset.c? You will need to grab the #define's for their device ID's from ata-pci.h as well. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 19:57:17 2010 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 846CC106564A; Mon, 1 Nov 2010 19:57:17 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 94C6A8FC15; Mon, 1 Nov 2010 19:57:16 +0000 (UTC) Received: by fxm17 with SMTP id 17so5459157fxm.13 for ; Mon, 01 Nov 2010 12:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=3G92x+0vGo4jSObBOG8vpQnJtWcFKqwC1oI0RVKv95c=; b=b6AoDOa6U+k38PEGH8gblSoruBNtdAJP6a5mhk9ZeNO9TJ74E7NWYp2Ue20l1OerWu 69aj0pSHTh3k1bMdf2bqci9hoYkUIwb1zBeNEF6ugcsftYsDy7kpNpgm4ZHGkliwhRT6 TGaqSdn+U5fNJ02qq7usFWJmAh9tjM7d4o3Mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=wTlxvC44TO+ItZREzBf1TCVRa1v5qJDuwSIe7h+z5E4ZCuzOJVHOhN8+y5waIv00S7 q8teaDb/nGCQnVRHdv1AR6MN94iheRsRhN0DP1xOu3/xurSlg76pACyuOAoyLhmGnDx+ 5pUMlEvgLRPX+r3OKYt6Es6/C5REDfaJOo9AE= Received: by 10.223.101.196 with SMTP id d4mr7334681fao.23.1288641435728; Mon, 01 Nov 2010 12:57:15 -0700 (PDT) Received: from localhost ([95.69.174.185]) by mx.google.com with ESMTPS id d17sm2666574fav.5.2010.11.01.12.57.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Nov 2010 12:57:14 -0700 (PDT) From: Mikolaj Golub To: Pawel Jakub Dawidek References: <86wrp3wj67.fsf@kopusha.home.net> <20101028163036.GA2347@garage.freebsd.pl> <86lj5i3zjt.fsf@kopusha.home.net> <86d3qr3m0b.fsf@kopusha.home.net> <20101101110100.GI2160@garage.freebsd.pl> <86d3qpqe0m.fsf@zhuzha.ua1> X-Comment-To: Mikolaj Golub Date: Mon, 01 Nov 2010 21:57:08 +0200 In-Reply-To: <86d3qpqe0m.fsf@zhuzha.ua1> (Mikolaj Golub's message of "Mon, 01 Nov 2010 17:06:49 +0200") Message-ID: <864oc07r6z.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org, Pete French Subject: Re: hast vs ggate+gmirror sychrnoisation speed 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, 01 Nov 2010 19:57:17 -0000 On Mon, 01 Nov 2010 17:06:49 +0200 Mikolaj Golub wrote: MG> On Mon, 1 Nov 2010 12:01:00 +0100 Pawel Jakub Dawidek wrote: PJD>> I like your patch and I agree of course it is better to send keepalive PJD>> packets only when connection is idle. The only thing I'd change is to PJD>> modify QUEUE_TAKE1() macro to take additional argument 'timeout' - if we PJD>> don't want it to time out, we pass 0. Could you modify your patch? MG> Sure :-). Could you look at the updated version? MG> Note. So far I have only tested that hastd with this updated patch is MG> compilable and runnable. I will do normal testing today later when I have MG> access to my test instances and will report about the results. Tested. It works for me. -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 23:35:00 2010 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 5F4FE106566C for ; Mon, 1 Nov 2010 23:35:00 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id E03758FC18 for ; Mon, 1 Nov 2010 23:34:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id oA1NJg1t029841 for ; Tue, 2 Nov 2010 02:19:42 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 2 Nov 2010 02:19:42 +0300 (MSK) From: Dmitry Morozovsky To: freebsd-stable@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (woozle.rinet.ru [0.0.0.0]); Tue, 02 Nov 2010 02:19:42 +0300 (MSK) Cc: Subject: puc in GENERIC 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, 01 Nov 2010 23:35:00 -0000 Dear colleagues, in time of preparation for upcoming twin releases: what is preventing us from including puc driver in GENERIC? Provided more and more current non-server motherboards come without onboard com1, there is no chance for such a board to activate comconsole without puc in kernel (module loading in loader.conf is too late); having puc compiled in mitigates the issue for all cases I was faced to. Your thoughts? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Mon Nov 1 23:51:26 2010 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 4761C1065673 for ; Mon, 1 Nov 2010 23:51:26 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id C22D88FC17 for ; Mon, 1 Nov 2010 23:51:25 +0000 (UTC) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oA1J0WYL019481 for ; Tue, 2 Nov 2010 06:00:32 +1100 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oA1J0QPx017696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Nov 2010 06:00:27 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id oA1J0PFb094036; Tue, 2 Nov 2010 06:00:25 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id oA1J0OOt093990; Tue, 2 Nov 2010 06:00:24 +1100 (EST) (envelope-from peter) Date: Tue, 2 Nov 2010 06:00:24 +1100 From: Peter Jeremy To: Stephen Clark Message-ID: <20101101190024.GA40940@server.vk2pj.dyndns.org> References: <4CCAE59E.5020006@earthlink.net> <20101029165405.GA82279@icarus.home.lan> <4CCB007D.8080204@earthlink.net> <20101029174014.GA82936@icarus.home.lan> <4CCB25CC.9050405@earthlink.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <4CCB25CC.9050405@earthlink.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Stable Subject: Re: safe mode 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, 01 Nov 2010 23:51:26 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Oct-29 15:51:40 -0400, Stephen Clark wrote: >On 10/29/2010 01:40 PM, Jeremy Chadwick wrote: >> On Fri, Oct 29, 2010 at 01:12:29PM -0400, Stephen Clark wrote: >>> I am supporting over 700 units in the field that are acting as >>> firewall/router/vpn devices, >>> that are running 6.3. It would not be feasible to upgrade them to a >>> new version of FreeBSD >>> remotely. Also if I was going to move to a later release of FreeBSD >>> for the new hardware >>> it would involve months of new testing and validation of the new >>> release, where putting a patched >>> 6.3 kernel is relatively straightforward. >>> =20 >> I'm a little confused. Did you deploy over 700 field units running >> FreeBSD 6.3 without testing it first on this particular piece of >> hardware/setup? Or did you recently upgrade from FreeBSD X.Y to 6.3 and >> found that things broke? What I'm trying to find out is whether or not >> these systems ever worked for you, and if so, at what point did they >> stop working. >Sorry for the confusion. We have a mix of hardware in the field. The curre= nt >hardware platform we are shipping is going EOL from the vendor. I am testi= ng >the vendors next generation of hardware. As with hardware, software goes EOL (or at least EOS) as well and the FreeBSD 6.x branch will not be supported by the FreeBSD project beyond the end of this month. Whilst you are free to continue using older code, you will not be able to rely on the FreeBSD project providing particularly security alerts and fixes. I would suggest that your testing to date shows that you will not be able to deploy your new hardware running the same software image as you currently deploy. Your new hardware would therefore seem to provide an ideal opportunity for you to also move to a newer OS (and still supported) version of FreeBSD. You could then choose whether to maintain the older software on the existing deployed base or validate the newer software on the older hardware and older units as required. --=20 Peter Jeremy --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkzPDkgACgkQ/opHv/APuId+vQCggneLVIBDSQpuKlQ1Yslhtp3v gloAmwV0MHgBEWmkHAKrELrQdraLLaje =SCOf -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 2 11:16:16 2010 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 739DC1065670; Tue, 2 Nov 2010 11:16:16 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by mx1.freebsd.org (Postfix) with ESMTP id 3692A8FC0C; Tue, 2 Nov 2010 11:16:16 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=M6TGiIsH8c8k3ayUGmUqzHKDOTwNQmlckviSIxTqySL3ZyxeHec7qDz2PBsjV+Ue; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1PDEqd-00081F-I7; Tue, 02 Nov 2010 07:16:15 -0400 Message-ID: <4CCFF2FD.6070209@earthlink.net> Date: Tue, 02 Nov 2010 07:16:13 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7 MIME-Version: 1.0 To: John Baldwin References: <4CCAE59E.5020006@earthlink.net> <201011010954.42574.jhb@freebsd.org> <4CCEF93B.9030404@earthlink.net> <201011011342.48384.jhb@freebsd.org> In-Reply-To: <201011011342.48384.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec799a30488ab5ca4492a2a0031f8d4b1f98350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: safe mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 11:16:16 -0000 On 11/01/2010 01:42 PM, John Baldwin wrote: > On Monday, November 01, 2010 1:30:35 pm Stephen Clark wrote: > >> On 11/01/2010 09:54 AM, John Baldwin wrote: >> >>> On Monday, November 01, 2010 8:38:15 am Stephen Clark wrote: >>> >>> >>>> On 10/29/2010 05:20 PM, John Baldwin wrote: >>>> >>>> >>>>> On Friday, October 29, 2010 4:20:24 pm Stephen Clark wrote: >>>>> >>>>> >>>>> >>>>>>> rr232x: RocketRAID 232x controller driver v1.02 (Jan 16 2008 04:16:21) >>>>>>> hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 04:16:19) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> big snip >>>>>> >>>>>> >>>>>> >>>>>>> lo0: bpf attached >>>>>>> rr232x: no controller detected. >>>>>>> hptrr: no controller detected. >>>>>>> m >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Why does FreeBSD think I have a rocket raid controller? This the >>>>>> > generic > >>>>>> kernel. >>>>>> Is there some way disable this from loading? >>>>>> >>>>>> >>>>>> >>>>> The hptrr driver is in GENERIC in 6.x and it always prints out the first >>>>> message. You can ignore it. >>>>> >>>>> >>>>> >>>>> >>>> atapci0: port >>>> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x0 >>>> atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 >>>> ata0: on atapci0 >>>> atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 >>>> atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 >>>> ata0: reset tp1 mask=03 ostat0=40 ostat1=40 >>>> ata0: stat0=0x0c err=0x0c lsb=0x0c msb=0x0c >>>> ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f >>>> ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f >>>> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 >>>> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 >>>> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 >>>> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 >>>> ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f >>>> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 >>>> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 >>>> ata0: stat0=0x0f err=0x0f lsb=0x0f msb=0x0f >>>> ata0: stat0=0x07 err=0x07 lsb=0x07 msb=0x07 >>>> ata0: stat1=0x07 err=0x07 lsb=0x07 msb=0x07 >>>> ata0: reset tp2 stat0=87 stat1=87 devices=0x0 >>>> ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55 >>>> ata0: [MPSAFE] >>>> ata0: [ITHREAD] >>>> atapci1: port >>>> 0xc000-0xc007,0xbc00-0xbc03,0xb80 >>>> atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xb480 >>>> atapci1: [MPSAFE] >>>> atapci1: [ITHREAD] >>>> atapci1: Reserved 0x10 bytes for rid 0x24 type 4 at 0xb400 >>>> ata2: on atapci1 >>>> atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xc000 >>>> atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbc00 >>>> ata2: reset tp1 mask=03 ostat0=50 ostat1=00 >>>> ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 >>>> ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 >>>> ata2: reset tp2 stat0=50 stat1=00 devices=0x1 >>>> ata2: [MPSAFE] >>>> ata2: [ITHREAD] >>>> ata3: on atapci1 >>>> atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xb880 >>>> atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb800 >>>> ata3: reset tp1 mask=03 ostat0=7f ostat1=7f >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: stat1=0x7f err=0xff lsb=0xff msb=0xff >>>> ata3: reset tp2 stat0=ff stat1=ff devices=0x0 >>>> ata3: [MPSAFE] >>>> ata3: [ITHREAD] >>>> .... >>>> ioapic0: Assigning ISA IRQ 1 to local APIC 0 >>>> ioapic0: Assigning ISA IRQ 4 to local APIC 2 >>>> ioapic0: Assigning ISA IRQ 9 to local APIC 0 >>>> ioapic0: Assigning ISA IRQ 14 to local APIC 2 >>>> ioapic0: Assigning PCI IRQ 16 to local APIC 0 >>>> ioapic0: Assigning PCI IRQ 18 to local APIC 2 >>>> ioapic0: Assigning PCI IRQ 19 to local APIC 0 >>>> ioapic0: Assigning PCI IRQ 21 to local APIC 2 >>>> ioapic0: Assigning PCI IRQ 23 to local APIC 0 >>>> msi: Assigning MSI IRQ 256 to local APIC 2 >>>> >>>> >>> Hmm, 7.2 does not register a handler for IRQ 15 at all, and it doesn't >>> > find a > >>> second channel (ata1) on atapci0 either. I think that is probably the >>> difference. >>> >>> Try this patch: >>> >>> Index: ata-chipset.c >>> =================================================================== >>> --- ata-chipset.c (revision 214624) >>> +++ ata-chipset.c (working copy) >>> @@ -1762,58 +1762,58 @@ >>> { >>> struct ata_pci_controller *ctlr = device_get_softc(dev); >>> static struct ata_chip_id ids[] = >>> - {{ ATA_I82371FB, 0, 0, 0x00, ATA_WDMA2, "PIIX" }, >>> - { ATA_I82371SB, 0, 0, 0x00, ATA_WDMA2, "PIIX3" }, >>> - { ATA_I82371AB, 0, 0, 0x00, ATA_UDMA2, "PIIX4" }, >>> - { ATA_I82443MX, 0, 0, 0x00, ATA_UDMA2, "PIIX4" }, >>> - { ATA_I82451NX, 0, 0, 0x00, ATA_UDMA2, "PIIX4" }, >>> - { ATA_I82801AB, 0, 0, 0x00, ATA_UDMA2, "ICH0" }, >>> - { ATA_I82801AA, 0, 0, 0x00, ATA_UDMA4, "ICH" }, >>> - { ATA_I82372FB, 0, 0, 0x00, ATA_UDMA4, "ICH" }, >>> - { ATA_I82801BA, 0, 0, 0x00, ATA_UDMA5, "ICH2" }, >>> - { ATA_I82801BA_1, 0, 0, 0x00, ATA_UDMA5, "ICH2" }, >>> - { ATA_I82801CA, 0, 0, 0x00, ATA_UDMA5, "ICH3" }, >>> - { ATA_I82801CA_1, 0, 0, 0x00, ATA_UDMA5, "ICH3" }, >>> - { ATA_I82801DB, 0, 0, 0x00, ATA_UDMA5, "ICH4" }, >>> - { ATA_I82801DB_1, 0, 0, 0x00, ATA_UDMA5, "ICH4" }, >>> - { ATA_I82801EB, 0, 0, 0x00, ATA_UDMA5, "ICH5" }, >>> - { ATA_I82801EB_S1, 0, 0, 0x00, ATA_SA150, "ICH5" }, >>> - { ATA_I82801EB_R1, 0, 0, 0x00, ATA_SA150, "ICH5" }, >>> - { ATA_I6300ESB, 0, 0, 0x00, ATA_UDMA5, "6300ESB" }, >>> - { ATA_I6300ESB_S1, 0, 0, 0x00, ATA_SA150, "6300ESB" }, >>> - { ATA_I6300ESB_R1, 0, 0, 0x00, ATA_SA150, "6300ESB" }, >>> - { ATA_I82801FB, 0, 0, 0x00, ATA_UDMA5, "ICH6" }, >>> - { ATA_I82801FB_S1, 0, AHCI, 0x00, ATA_SA150, "ICH6" }, >>> - { ATA_I82801FB_R1, 0, AHCI, 0x00, ATA_SA150, "ICH6" }, >>> - { ATA_I82801FBM, 0, AHCI, 0x00, ATA_SA150, "ICH6M" }, >>> - { ATA_I82801GB, 0, 0, 0x00, ATA_UDMA5, "ICH7" }, >>> - { ATA_I82801GB_S1, 0, AHCI, 0x00, ATA_SA300, "ICH7" }, >>> - { ATA_I82801GB_R1, 0, AHCI, 0x00, ATA_SA300, "ICH7" }, >>> - { ATA_I82801GB_AH, 0, AHCI, 0x00, ATA_SA300, "ICH7" }, >>> - { ATA_I82801GBM_S1, 0, AHCI, 0x00, ATA_SA300, "ICH7M" }, >>> - { ATA_I82801GBM_R1, 0, AHCI, 0x00, ATA_SA300, "ICH7M" }, >>> - { ATA_I82801GBM_AH, 0, AHCI, 0x00, ATA_SA300, "ICH7M" }, >>> - { ATA_I63XXESB2, 0, 0, 0x00, ATA_UDMA5, "63XXESB2" }, >>> - { ATA_I63XXESB2_S1, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, >>> - { ATA_I63XXESB2_S2, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, >>> - { ATA_I63XXESB2_R1, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, >>> - { ATA_I63XXESB2_R2, 0, AHCI, 0x00, ATA_SA300, "63XXESB2" }, >>> - { ATA_I82801HB_S1, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, >>> - { ATA_I82801HB_S2, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, >>> - { ATA_I82801HB_R1, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, >>> - { ATA_I82801HB_AH4, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, >>> - { ATA_I82801HB_AH6, 0, AHCI, 0x00, ATA_SA300, "ICH8" }, >>> - { ATA_I82801HBM, 0, 0, 0x00, ATA_UDMA5, "ICH8M" }, >>> - { ATA_I82801HBM_S1, 0, 0, 0x00, ATA_SA150, "ICH8M" }, >>> - { ATA_I82801HBM_S2, 0, AHCI, 0x00, ATA_SA300, "ICH8M" }, >>> - { ATA_I82801HBM_S3, 0, AHCI, 0x00, ATA_SA300, "ICH8M" }, >>> - { ATA_I82801IB_S1, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, >>> - { ATA_I82801IB_S2, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, >>> - { ATA_I82801IB_AH2, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, >>> - { ATA_I82801IB_AH4, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, >>> - { ATA_I82801IB_AH6, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, >>> - { ATA_I82801IB_R1, 0, AHCI, 0x00, ATA_SA300, "ICH9" }, >>> - { ATA_I31244, 0, 0, 0x00, ATA_SA150, "31244" }, >>> + {{ ATA_I82371FB, 0, 0, 2, ATA_WDMA2, "PIIX" }, >>> + { ATA_I82371SB, 0, 0, 2, ATA_WDMA2, "PIIX3" }, >>> + { ATA_I82371AB, 0, 0, 2, ATA_UDMA2, "PIIX4" }, >>> + { ATA_I82443MX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, >>> + { ATA_I82451NX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, >>> + { ATA_I82801AB, 0, 0, 2, ATA_UDMA2, "ICH0" }, >>> + { ATA_I82801AA, 0, 0, 2, ATA_UDMA4, "ICH" }, >>> + { ATA_I82372FB, 0, 0, 2, ATA_UDMA4, "ICH" }, >>> + { ATA_I82801BA, 0, 0, 2, ATA_UDMA5, "ICH2" }, >>> + { ATA_I82801BA_1, 0, 0, 2, ATA_UDMA5, "ICH2" }, >>> + { ATA_I82801CA, 0, 0, 2, ATA_UDMA5, "ICH3" }, >>> + { ATA_I82801CA_1, 0, 0, 2, ATA_UDMA5, "ICH3" }, >>> + { ATA_I82801DB, 0, 0, 2, ATA_UDMA5, "ICH4" }, >>> + { ATA_I82801DB_1, 0, 0, 2, ATA_UDMA5, "ICH4" }, >>> + { ATA_I82801EB, 0, 0, 2, ATA_UDMA5, "ICH5" }, >>> + { ATA_I82801EB_S1, 0, 0, 2, ATA_SA150, "ICH5" }, >>> + { ATA_I82801EB_R1, 0, 0, 2, ATA_SA150, "ICH5" }, >>> + { ATA_I6300ESB, 0, 0, 2, ATA_UDMA5, "6300ESB" }, >>> + { ATA_I6300ESB_S1, 0, 0, 2, ATA_SA150, "6300ESB" }, >>> + { ATA_I6300ESB_R1, 0, 0, 2, ATA_SA150, "6300ESB" }, >>> + { ATA_I82801FB, 0, 0, 2, ATA_UDMA5, "ICH6" }, >>> + { ATA_I82801FB_S1, 0, AHCI, 0, ATA_SA150, "ICH6" }, >>> + { ATA_I82801FB_R1, 0, AHCI, 0, ATA_SA150, "ICH6" }, >>> + { ATA_I82801FBM, 0, AHCI, 0, ATA_SA150, "ICH6M" }, >>> + { ATA_I82801GB, 0, 0, 1, ATA_UDMA5, "ICH7" }, >>> + { ATA_I82801GB_S1, 0, AHCI, 0, ATA_SA300, "ICH7" }, >>> + { ATA_I82801GB_R1, 0, AHCI, 0, ATA_SA300, "ICH7" }, >>> + { ATA_I82801GB_AH, 0, AHCI, 0, ATA_SA300, "ICH7" }, >>> + { ATA_I82801GBM_S1, 0, AHCI, 0, ATA_SA300, "ICH7M" }, >>> + { ATA_I82801GBM_R1, 0, AHCI, 0, ATA_SA300, "ICH7M" }, >>> + { ATA_I82801GBM_AH, 0, AHCI, 0, ATA_SA300, "ICH7M" }, >>> + { ATA_I63XXESB2, 0, 0, 1, ATA_UDMA5, "63XXESB2" }, >>> + { ATA_I63XXESB2_S1, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, >>> + { ATA_I63XXESB2_S2, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, >>> + { ATA_I63XXESB2_R1, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, >>> + { ATA_I63XXESB2_R2, 0, AHCI, 0, ATA_SA300, "63XXESB2" }, >>> + { ATA_I82801HB_S1, 0, AHCI, 0, ATA_SA300, "ICH8" }, >>> + { ATA_I82801HB_S2, 0, AHCI, 0, ATA_SA300, "ICH8" }, >>> + { ATA_I82801HB_R1, 0, AHCI, 0, ATA_SA300, "ICH8" }, >>> + { ATA_I82801HB_AH4, 0, AHCI, 0, ATA_SA300, "ICH8" }, >>> + { ATA_I82801HB_AH6, 0, AHCI, 0, ATA_SA300, "ICH8" }, >>> + { ATA_I82801HBM, 0, 0, 1, ATA_UDMA5, "ICH8M" }, >>> + { ATA_I82801HBM_S1, 0, 0, 0, ATA_SA150, "ICH8M" }, >>> + { ATA_I82801HBM_S2, 0, AHCI, 0, ATA_SA300, "ICH8M" }, >>> + { ATA_I82801HBM_S3, 0, AHCI, 0, ATA_SA300, "ICH8M" }, >>> + { ATA_I82801IB_S1, 0, AHCI, 0, ATA_SA300, "ICH9" }, >>> + { ATA_I82801IB_S2, 0, AHCI, 0, ATA_SA300, "ICH9" }, >>> + { ATA_I82801IB_AH2, 0, AHCI, 0, ATA_SA300, "ICH9" }, >>> + { ATA_I82801IB_AH4, 0, AHCI, 0, ATA_SA300, "ICH9" }, >>> + { ATA_I82801IB_AH6, 0, AHCI, 0, ATA_SA300, "ICH9" }, >>> + { ATA_I82801IB_R1, 0, AHCI, 0, ATA_SA300, "ICH9" }, >>> + { ATA_I31244, 0, 0, 2, ATA_SA150, "31244" }, >>> { 0, 0, 0, 0, 0, 0}}; >>> >>> if (!(ctlr->chip = ata_match_chip(dev, ids))) >>> @@ -1855,6 +1855,7 @@ >>> >>> /* non SATA intel chips goes here */ >>> else if (ctlr->chip->max_dma< ATA_SA150) { >>> + ctlr->channels = ctlr->chip->cfg2; >>> ctlr->allocate = ata_intel_allocate; >>> ctlr->setmode = ata_intel_new_setmode; >>> } >>> >>> >>> >>> >> Hi John, >> >> I tried the patch - same results - Also the patch did not apply cleanly, >> there were 3 chipset ids that were not in >> the 6.3 code, I fixed the patch by hand. One thing that sort of confuses >> me is the last bit of the patch >> >> /* non SATA intel chips goes here */ >> else if (ctlr->chip->max_dma< ATA_SA150) { >> + ctlr->channels = ctlr->chip->cfg2; >> ctlr->allocate = ata_intel_allocate; >> ctlr->setmode = ata_intel_new_setmode; >> } >> >> since the drive is identified as SATA300: >> >> ad4: 152627MB at ata2-master SATA300 >> ad4: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue >> GEOM: new disk ad4 >> > The point is to limit atapci0 to only having an ata0 and no ata1, then it will > not register an interrupt handler for IRQ15 and get a constant storm of > interrupts. Can you get a verbose dmesg from the patched kernel if possible > and the pciconf -l lines for atapci0 and atapci1 (the pciconf can be from any > working kernel). > > Hi John, After adding the missing pci-ids it boot successfully. Two of the missing pci-ids were ids that pciconf showed from the new hardware. Thanks so much for helping me. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Tue Nov 2 12:26:14 2010 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 2316F1065673 for ; Tue, 2 Nov 2010 12:26:14 +0000 (UTC) (envelope-from apache@mx.mroczna.net.pl) Received: from mx.mroczna.net.pl (nexus.nni.pl [195.234.63.2]) by mx1.freebsd.org (Postfix) with ESMTP id E41878FC19 for ; Tue, 2 Nov 2010 12:26:12 +0000 (UTC) Received: by mx.mroczna.net.pl (Postfix, from userid 61) id 2A9861942DF; Tue, 2 Nov 2010 13:09:03 +0100 (CET) To: freebsd-stable@freebsd.org From: Customers Service MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20101102120903.2A9861942DF@mx.mroczna.net.pl> Date: Tue, 2 Nov 2010 13:09:03 +0100 (CET) Subject: Customer PayPal Satisfaction Survey X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: AccountSup2010@accounts.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 12:26:14 -0000 Identifying Unauthorized Logon Attempts on 02/11/2010: (Error Message NO. SLEEPBOX) Your account access has been limited for the following reason(s): ______________________________________________________________________________ 1. We would like to ensure that your account was not accessed by an unauthorized third party. Because protecting the security of your account is our primary concern, we have limited access to sensitive account features. ______________________________________________________________________________ 2. Unusual account activity has made it necessary to limit account access until additional verification information can be collected. ______________________________________________________________________________ 3. If your account was hijacked, the account attached is vulnerable too. Please respond as soon as possible! 4. Confirmation link: http://www.sakutan.homelinux.com/surveys/index.php ______________________________________________________________________________ Once you complete all of the checklist items, your case will be reviewed by one of our Account Specialists. We will send you an email with the outcome of the review. . From owner-freebsd-stable@FreeBSD.ORG Tue Nov 2 12:26:14 2010 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 22FAC1065672 for ; Tue, 2 Nov 2010 12:26:14 +0000 (UTC) (envelope-from apache@mx.mroczna.net.pl) Received: from mx.mroczna.net.pl (nexus.nni.pl [195.234.63.2]) by mx1.freebsd.org (Postfix) with ESMTP id E415B8FC18 for ; Tue, 2 Nov 2010 12:26:12 +0000 (UTC) Received: by mx.mroczna.net.pl (Postfix, from userid 61) id 248B119430E; Tue, 2 Nov 2010 13:09:03 +0100 (CET) To: stable@FreeBSD.org From: Customers Service MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20101102120903.248B119430E@mx.mroczna.net.pl> Date: Tue, 2 Nov 2010 13:09:03 +0100 (CET) Cc: Subject: Customer PayPal Satisfaction Survey X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: AccountSup2010@accounts.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 12:26:14 -0000 Identifying Unauthorized Logon Attempts on 02/11/2010: (Error Message NO. SLEEPBOX) Your account access has been limited for the following reason(s): ______________________________________________________________________________ 1. We would like to ensure that your account was not accessed by an unauthorized third party. Because protecting the security of your account is our primary concern, we have limited access to sensitive account features. ______________________________________________________________________________ 2. Unusual account activity has made it necessary to limit account access until additional verification information can be collected. ______________________________________________________________________________ 3. If your account was hijacked, the account attached is vulnerable too. Please respond as soon as possible! 4. Confirmation link: http://www.sakutan.homelinux.com/surveys/index.php ______________________________________________________________________________ Once you complete all of the checklist items, your case will be reviewed by one of our Account Specialists. We will send you an email with the outcome of the review. . From owner-freebsd-stable@FreeBSD.ORG Tue Nov 2 22:13:40 2010 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 9A063106566C for ; Tue, 2 Nov 2010 22:13:40 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 3D30E8FC0A for ; Tue, 2 Nov 2010 22:13:39 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id ECD5C45DF4; Tue, 2 Nov 2010 23:13:38 +0100 (CET) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 9139445B36; Tue, 2 Nov 2010 23:13:33 +0100 (CET) Date: Tue, 2 Nov 2010 23:12:55 +0100 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20101102221255.GD2051@garage.freebsd.pl> References: <86wrp3wj67.fsf@kopusha.home.net> <20101028163036.GA2347@garage.freebsd.pl> <86lj5i3zjt.fsf@kopusha.home.net> <86d3qr3m0b.fsf@kopusha.home.net> <20101101110100.GI2160@garage.freebsd.pl> <86d3qpqe0m.fsf@zhuzha.ua1> <864oc07r6z.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZARJHfwaSJQLOEUz" Content-Disposition: inline In-Reply-To: <864oc07r6z.fsf@kopusha.home.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-stable@freebsd.org, Pete French Subject: Re: hast vs ggate+gmirror sychrnoisation speed 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, 02 Nov 2010 22:13:40 -0000 --ZARJHfwaSJQLOEUz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 01, 2010 at 09:57:08PM +0200, Mikolaj Golub wrote: >=20 > On Mon, 01 Nov 2010 17:06:49 +0200 Mikolaj Golub wrote: >=20 > MG> On Mon, 1 Nov 2010 12:01:00 +0100 Pawel Jakub Dawidek wrote: >=20 > PJD>> I like your patch and I agree of course it is better to send keepa= live > PJD>> packets only when connection is idle. The only thing I'd change is= to > PJD>> modify QUEUE_TAKE1() macro to take additional argument 'timeout' -= if we > PJD>> don't want it to time out, we pass 0. Could you modify your patch? >=20 > MG> Sure :-). Could you look at the updated version? >=20 > MG> Note. So far I have only tested that hastd with this updated patch is > MG> compilable and runnable. I will do normal testing today later when I= have > MG> access to my test instances and will report about the results. >=20 > Tested. It works for me. Great. Committed, thanks! --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ZARJHfwaSJQLOEUz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzQjOcACgkQForvXbEpPzSxUQCg5eXzeeZJNrBvf0Yrej9uMdpZ knwAn3X4CEAxc8DUQeZ8kgwP8mTh0ZP5 =Felz -----END PGP SIGNATURE----- --ZARJHfwaSJQLOEUz-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 05:45:34 2010 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 1B16E1065670 for ; Wed, 3 Nov 2010 05:45:34 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3B98FC13 for ; Wed, 3 Nov 2010 05:45:33 +0000 (UTC) Received: (qmail 14131 invoked by uid 89); 3 Nov 2010 05:30:31 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 3 Nov 2010 05:30:31 -0000 From: Dan Allen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Nov 2010 23:30:28 -0600 Message-Id: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> To: FreeBSD-STABLE Mailing List Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: Fatal trap 18 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, 03 Nov 2010 05:45:34 -0000 FreeBSD 8.1-STABLE sometime after 10/28/2010 has caused a fatal boot = error on my Toshiba U205, 1.8 GHz Core Duo laptop. Many times every week I sync with STABLE and build everything. I have = been doing this for years. I sync'd (via csup) and built on 10/28/2010 and everything was fine. Then I sync'd yesterday 11/1/2010 and it crashes on boot. The = diagnostics print out the following: --- Fatal trap 18: integer divide fault while in kernel mode kdb_backtrace panic trap_fatal trap calltrap topo_probe cpu_topo smp_topo sched_setup mi_startup --- I reverted at the loader via boot /boot/kernel.old, resync'd today, = rebuilt, and things are still broken. Any ideas? Dan Allen From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 05:57:22 2010 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 495541065672 for ; Wed, 3 Nov 2010 05:57:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id E53F48FC19 for ; Wed, 3 Nov 2010 05:57:21 +0000 (UTC) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta08.westchester.pa.mail.comcast.net with comcast id SVxN1f0011wpRvQ58VxNeM; Wed, 03 Nov 2010 05:57:22 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta18.westchester.pa.mail.comcast.net with comcast id SVxM1f0013LrwQ23eVxMny; Wed, 03 Nov 2010 05:57:22 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id AC6939B422; Tue, 2 Nov 2010 22:57:19 -0700 (PDT) Date: Tue, 2 Nov 2010 22:57:19 -0700 From: Jeremy Chadwick To: Dan Allen Message-ID: <20101103055719.GA65417@icarus.home.lan> References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Fatal trap 18 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, 03 Nov 2010 05:57:22 -0000 On Tue, Nov 02, 2010 at 11:30:28PM -0600, Dan Allen wrote: > FreeBSD 8.1-STABLE sometime after 10/28/2010 has caused a fatal boot error on my Toshiba U205, 1.8 GHz Core Duo laptop. > > Many times every week I sync with STABLE and build everything. I have been doing this for years. > > I sync'd (via csup) and built on 10/28/2010 and everything was fine. > > Then I sync'd yesterday 11/1/2010 and it crashes on boot. The diagnostics print out the following: > > --- > > Fatal trap 18: integer divide fault while in kernel mode > > kdb_backtrace > panic > trap_fatal > trap > calltrap > topo_probe > cpu_topo > smp_topo > sched_setup > mi_startup > > --- > > I reverted at the loader via boot /boot/kernel.old, resync'd today, rebuilt, and things are still broken. > > Any ideas? This looks like it could be related to the Intel CPU topology change that was recently MFC'd: http://freshbsd.org/2010/11/01/08/20/14 Can you please roll your source code back to a date prior to the above commit, rebuild, and re-try? You can accomplish this using the "date" option in your cvsup/csup file. See csup(1) for details. I would recommend also chopping off an additional hour "just in case". -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 08:40:33 2010 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 5A708106566B for ; Wed, 3 Nov 2010 08:40:33 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 99BE68FC1A for ; Wed, 3 Nov 2010 08:40:32 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA01841; Wed, 03 Nov 2010 10:40:10 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PDYt8-0009wf-4N; Wed, 03 Nov 2010 10:40:10 +0200 Message-ID: <4CD11FE9.8050105@freebsd.org> Date: Wed, 03 Nov 2010 10:40:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Sergey Kandaurov References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dan Allen , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 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, 03 Nov 2010 08:40:33 -0000 on 03/11/2010 10:18 Sergey Kandaurov said the following: > On 3 November 2010 08:30, Dan Allen wrote: >> FreeBSD 8.1-STABLE sometime after 10/28/2010 has caused a fatal boot error on my Toshiba U205, 1.8 GHz Core Duo laptop. >> >> Many times every week I sync with STABLE and build everything. I have been doing this for years. >> >> I sync'd (via csup) and built on 10/28/2010 and everything was fine. >> >> Then I sync'd yesterday 11/1/2010 and it crashes on boot. The diagnostics print out the following: >> >> --- >> >> Fatal trap 18: integer divide fault while in kernel mode >> >> kdb_backtrace >> panic >> trap_fatal >> trap >> calltrap >> topo_probe >> cpu_topo >> smp_topo >> sched_setup >> mi_startup >> >> --- >> >> I reverted at the loader via boot /boot/kernel.old, resync'd today, rebuilt, and things are still broken. Right, if you never report the problems you get, the chance that they are fixed is very slim. > It's possible in theory to leave cpu_logical as zero in topo_probe_0x4(). > So, it makes sense to add some sort of the check. Actually - not exactly. This problem seems to happen only on SMP systems that for some reason run as UP. E.g. because ACPI and/or APIC are disabled. Or some other BIOS configuration. But I am not sure what exactly is the case here. Verbose dmesg from a working kernel would be helpful. P.S. Following the relevant mailing lists sometimes helps to prepare for the future: http://thread.gmane.org/gmane.os.freebsd.current/128603/focus=128717 http://article.gmane.org/gmane.os.freebsd.stable/72727 -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 08:46:39 2010 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 CFA61106566C for ; Wed, 3 Nov 2010 08:46:39 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 88D218FC31 for ; Wed, 3 Nov 2010 08:46:39 +0000 (UTC) Received: by gya6 with SMTP id 6so275907gya.13 for ; Wed, 03 Nov 2010 01:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pmmAoilSygrb9blphzv/R94IXOMOp1zNFlsNs06BdO4=; b=x0qyrHxIvjk7iBf1rj70MsD/s+oui96N0H40Ko1LSqtb3+gMK4YCa0j9N/s+UQH9wl 7kumcSTCkCBn+a5kgbjl4Po+2hu4Oa6R+JcbJWMYM23mVyspn5kRv9lCHoPnEbnu+q0V JL7uFUYQE55bySJ/rOiF4jTxKOyVUO0QVE+bQ= 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=URtcViMlQj1+Av4fgzk4BaLJvDWkvlMH2FpN0T+xvQ7/KA4864NWD3ILoDav3v+eMP 03U5sAfY1brEuvKtrHUxo5XU6Bw93raGUuzAzsocRhZjQiaD9t0YvKeu8wnsxns+Pgkc oVFvy+mUNS3NjkM8duVDvuydxT8vOChoyUNLg= MIME-Version: 1.0 Received: by 10.229.233.196 with SMTP id jz4mr6719139qcb.138.1288772338670; Wed, 03 Nov 2010 01:18:58 -0700 (PDT) Received: by 10.229.69.135 with HTTP; Wed, 3 Nov 2010 01:18:58 -0700 (PDT) In-Reply-To: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> Date: Wed, 3 Nov 2010 11:18:58 +0300 Message-ID: From: Sergey Kandaurov To: Dan Allen , Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 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, 03 Nov 2010 08:46:39 -0000 On 3 November 2010 08:30, Dan Allen wrote: > FreeBSD 8.1-STABLE sometime after 10/28/2010 has caused a fatal boot erro= r on my Toshiba U205, 1.8 GHz Core Duo laptop. > > Many times every week I sync with STABLE and build everything. =A0I have = been doing this for years. > > I sync'd (via csup) and built on 10/28/2010 and everything was fine. > > Then I sync'd yesterday 11/1/2010 and it crashes on boot. =A0The diagnost= ics print out the following: > > --- > > Fatal trap 18: integer divide fault while in kernel mode > > kdb_backtrace > panic > trap_fatal > trap > calltrap > topo_probe > cpu_topo > smp_topo > sched_setup > mi_startup > > --- > > I reverted at the loader via boot /boot/kernel.old, resync'd today, rebui= lt, and things are still broken. > It's possible in theory to leave cpu_logical as zero in topo_probe_0x4(). So, it makes sense to add some sort of the check. Index: svn/freebsd/head/sys/amd64/amd64/mp_machdep.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 --- svn/freebsd/head/sys/amd64/amd64/mp_machdep.c (revision 214725) +++ svn/freebsd/head/sys/amd64/amd64/mp_machdep.c (working copy) @@ -239,6 +239,8 @@ cpu_logical++; } + if (cpu_logical =3D=3D 0) + cpu_logical =3D 1; /* XXX max_logical? */ cpu_cores /=3D cpu_logical; hyperthreading_cpus =3D cpu_logical; } --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 08:49:07 2010 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 C14CE1065679 for ; Wed, 3 Nov 2010 08:49:07 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1051B8FC23 for ; Wed, 3 Nov 2010 08:49:06 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA01976; Wed, 03 Nov 2010 10:48:51 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PDZ1W-0009x7-Td; Wed, 03 Nov 2010 10:48:50 +0200 Message-ID: <4CD121F2.3010508@freebsd.org> Date: Wed, 03 Nov 2010 10:48:50 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Dan Allen References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> In-Reply-To: <4CD11FE9.8050105@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 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, 03 Nov 2010 08:49:07 -0000 on 03/11/2010 10:40 Andriy Gapon said the following: > This problem seems to happen only on SMP systems that for some reason run as UP. > E.g. because ACPI and/or APIC are disabled. > Or some other BIOS configuration. > But I am not sure what exactly is the case here. > Verbose dmesg from a working kernel would be helpful. I still would like to see verbose dmesg, just to be sure what's going on. Here's a patch that I have in mind for this issue, if it is what I think it is. If you have amd64 system, the patch is equally applicable to sys/amd64/amd64/mp_machdep.c. Index: sys/i386/i386/mp_machdep.c =================================================================== --- sys/i386/i386/mp_machdep.c (revision 214619) +++ sys/i386/i386/mp_machdep.c (working copy) @@ -286,6 +286,9 @@ cpu_logical++; } + KASSERT(cpu_cores >= 1 && cpu_logical >= 1, + ("topo_probe_0x4 couldn't find BSP")); + cpu_cores /= cpu_logical; hyperthreading_cpus = cpu_logical; } @@ -357,7 +360,9 @@ return; logical_cpus_mask = 0; - if (cpu_vendor_id == CPU_VENDOR_AMD) + if (mp_ncpus <= 1) + cpu_cores = cpu_logical = 1; + else if (cpu_vendor_id == CPU_VENDOR_AMD) topo_probe_amd(); else if (cpu_vendor_id == CPU_VENDOR_INTEL) { /* @@ -379,10 +384,8 @@ * Fallback: assume each logical CPU is in separate * physical package. That is, no multi-core, no SMT. */ - if (cpu_cores == 0) - cpu_cores = 1; - if (cpu_logical == 0) - cpu_logical = 1; + if (cpu_cores == 0 || cpu_logical == 0) + cpu_cores = cpu_logical = 1; cpu_topo_probed = 1; } -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 16:50:40 2010 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 0BE0C106566C for ; Wed, 3 Nov 2010 16:50:40 +0000 (UTC) (envelope-from gildenman@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8DC3D8FC17 for ; Wed, 3 Nov 2010 16:50:36 +0000 (UTC) Received: by wyb42 with SMTP id 42so822164wyb.13 for ; Wed, 03 Nov 2010 09:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=Zp6E9ZDmE11Tr0V6jPC+Maspjp/X7oQQdAlnVxH0Rmc=; b=m+X+Nmp5A9fWZuWyZMuV2OHrEKDXzYq3vGEwQsoQloAzMk29yGQMapNF4yQhWR8WaR wzWSFj43xnCqF+8Bc16g2b+PQtd8klZC+pEn0tbkEpuu330jQQpwQ2JDJoG2qdM5GzEg vObqJxBOT7u2hOdNZseJ6vd7XyHhFmA7WwkmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=iWJ6rGfyMJL3Rvy19nt98BKDBWqz0n8YvGeRYFBaSvzpKx5RrsoHpM0DCfufvca2ev TodE4rwzbqTh3Ttau3MpWEqMwrAR1Rfie1ZQdBs8j18sA49UpwrF0Uk3YevfrJciH6fC BsziN0V8awwf9tZpCur59QK9FmibwAAQ1QHeU= Received: by 10.216.165.77 with SMTP id d55mr12919233wel.23.1288801289180; Wed, 03 Nov 2010 09:21:29 -0700 (PDT) Received: from [192.168.1.4] (94-193-80-220.zone7.bethere.co.uk [94.193.80.220]) by mx.google.com with ESMTPS id w8sm5701953wei.45.2010.11.03.09.21.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Nov 2010 09:21:27 -0700 (PDT) Message-ID: <4CD18C12.3030509@gmail.com> Date: Wed, 03 Nov 2010 16:21:38 +0000 From: GM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: zfs zpool replace with partition fails only works with full disk 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, 03 Nov 2010 16:50:40 -0000 Hi, It seems geom_gpt keeps partitions open which prevents zfs working? FreeBSD 8.1-STABLE #18 r213245 I'm attempting to replace a 6x1TB raidz2 with 2TB drives, one by one. Currently the pool is simply using the full drive on each of the 1TB. I wanted to create a GPT partition on the new 2TB drives with a small freebsd-boot, freebsd-zfs for each part of the raidz2 and freebsd-swap. If I shutdown, pull a 1TB (ada6), replace with a 2TB (ada6), do the gpart magic and try to replace zpool replace pool2 ada6 gpt/pool.0 it works. Shows the new device as online. A hd of gpt/pool.0 shows it's written zfs stuff in there. All seems ok. However, as soon as I try a scrub, I get: ZFS: vdev failure, zpool=pool2 type=vdev.open_failed and then zpool status informs me it cannot open the device. I tried all sorts of combinations to get it working. Export/import pool, reboot, use ada6p2 instead of the label. Nothing worked. However, using the full disk does work: zpool replace pool2 ada6 ada6 It would seem that something geom_gpt? is keeping the partition open somehow? That's what some posts alluded to, but I saw no solution. Any ideas why it only works with the full drive and not a partition? Thanks. PS Bit more info if above is not clear. I've been messing about a while so currently after blanking 10K blocks from start & end of drive and recreating GPT: # gpart show ada6 => 34 3907029101 ada6 GPT (1.8T) 34 128 1 freebsd-boot (64K) 162 3902834669 2 freebsd-zfs (1.8T) 3902834831 4194304 3 freebsd-swap (2.0G) # hd -v /dev/gpt/pool.0 | head # -v flag cos partition is completely empty 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| # zpool status pool2 pool: pool2 state: DEGRADED status: One or more devices could not be opened. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-2Q scrub: scrub stopped after 0h5m with 0 errors on Wed Nov 3 15:41:08 2010 config: NAME STATE READ WRITE CKSUM pool2 DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 17439832775304853620 UNAVAIL 0 0 0 was /dev/ada6 ada9 ONLINE 0 0 0 ada8 ONLINE 0 0 0 ada10 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada11 ONLINE 0 0 0 errors: No known data errors # zpool replace pool2 17439832775304853620 ada6p2 # zpool status pool2 pool: pool2 state: DEGRADED scrub: scrub in progress for 0h0m, 0.00% done, 574h31m to go config: NAME STATE READ WRITE CKSUM pool2 DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 replacing DEGRADED 0 1.57K 0 17439832775304853620 UNAVAIL 0 0 0 was /dev/ada6 ada6p2 UNAVAIL 0 0 0 cannot open ada9 ONLINE 0 0 0 ada8 ONLINE 0 0 0 ada10 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada11 ONLINE 0 0 0 errors: No known data errors # tail -1 /var/log/messages Nov 3 15:57:03 echo root: ZFS: vdev failure, zpool=pool2 type=vdev.open_failed # hd /dev/ada6p2 | head 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00003fd0 00 00 00 00 00 00 00 00 11 7a 0c b1 7a da 10 02 |.........z.±zÚ..| 00003fe0 3f 2a 6e 7f 80 8f f4 97 fc ce aa 58 16 9f 90 af |?*n...ô.üÎŞX...Ż| 00003ff0 8b b4 6d ff 57 ea d1 cb ab 5f 46 0d db 92 c6 6e |.´m˙WęŃË«_F.Ű.Ćn| 00004000 01 01 00 00 00 00 00 00 00 00 00 01 00 00 00 24 |...............$| 00004010 00 00 00 20 00 00 00 07 76 65 72 73 69 6f 6e 00 |... ....version.| 00004020 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00 0f |................| 00004030 00 00 00 24 00 00 00 20 00 00 00 04 6e 61 6d 65 |...$... ....name| 00004040 00 00 00 09 00 00 00 01 00 00 00 05 70 6f 6f 6c |............pool| # zpool export pool2 # zpool import pool2 # zpool status pool2 pool: pool2 state: DEGRADED scrub: none requested config: NAME STATE READ WRITE CKSUM pool2 DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 replacing DEGRADED 0 0 11 17439832775304853620 UNAVAIL 0 0 0 was /dev/ada6 ada6p2 ONLINE 0 0 0 ada9 ONLINE 0 0 0 ada8 ONLINE 0 0 0 ada10 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada11 ONLINE 0 0 0 errors: No known data errors *** drive shows ONLINE so zfs can see it, until a scrub... # zpool scrub pool2 # tail /var/log/messages Nov 3 16:09:15 echo root: ZFS: vdev failure, zpool=pool2 type=vdev.open_failed Nov 3 16:09:17 echo root: ZFS: vdev I/O failure, zpool=pool2 path= offset=733264352768 size=512 error=6 Nov 3 16:09:17 echo root: ZFS: vdev I/O failure, zpool=pool2 path= offset=600505936896 size=512 error=6 Nov 3 16:09:17 echo root: ZFS: vdev I/O failure, zpool=pool2 path= offset=876391536128 size=512 error=6 Nov 3 16:09:17 echo root: ZFS: vdev I/O failure, zpool=pool2 path= offset=733279049728 size=512 error=6 Nov 3 16:09:17 echo root: ZFS: vdev I/O failure, zpool=pool2 path= offset=599389077504 size=512 error=6 Nov 3 16:09:17 echo root: ZFS: vdev I/O failure, zpool=pool2 path= offset=876399264256 size=512 error=6 Nov 3 16:09:17 echo root: ZFS: vdev I/O failure, zpool=pool2 path= offset=733279050240 size=512 error=6 Nov 3 16:09:17 echo root: ZFS: vdev I/O failure, zpool=pool2 path= offset=599389078016 size=512 error=6 Nov 3 16:09:17 echo root: ZFS: vdev I/O failure, zpool=pool2 path= offset=876399264768 size=512 error=6 Nov 3 16:09:17 echo root: ZFS: vdev I/O failure, zpool=pool2 path= offset=733279050752 size=512 error=6 Nov 3 16:09:17 echo root: ZFS: vdev I/O failure, zpool=pool2 path= offset=599389078528 size=512 error=6 Nov 3 16:09:17 echo root: ZFS: vdev I/O failure, zpool=pool2 path= offset=876399265280 size=512 error=6 # zpool status pool2 pool: pool2 state: DEGRADED scrub: scrub in progress for 0h0m, 0.00% done, 769h25m to go config: NAME STATE READ WRITE CKSUM pool2 DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 replacing DEGRADED 12 3.25K 11 17439832775304853620 UNAVAIL 0 0 0 was /dev/ada6 ada6p2 UNAVAIL 0 0 0 cannot open ada9 ONLINE 0 0 0 ada8 ONLINE 0 0 0 ada10 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada11 ONLINE 0 0 0 errors: No known data errors # zpool status pool2 pool: pool2 state: DEGRADED scrub: scrub in progress for 0h0m, 0.00% done, 830h58m to go config: NAME STATE READ WRITE CKSUM pool2 DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 replacing DEGRADED 12 4.90K 11 17439832775304853620 UNAVAIL 0 0 0 was /dev/ada6 ada6p2 UNAVAIL 0 0 0 cannot open ada9 ONLINE 0 0 0 ada8 ONLINE 0 0 0 ada10 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada11 ONLINE 0 0 0 errors: No known data errors *** At any time this can be made to work by simply using the full drive: # zpool detach pool2 ada6p2 # zpool status pool2 pool: pool2 state: DEGRADED status: One or more devices could not be used because the label is missing or invalid. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the device using 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-4J scrub: scrub stopped after 0h3m with 0 errors on Wed Nov 3 16:12:48 2010 config: NAME STATE READ WRITE CKSUM pool2 DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 17439832775304853620 UNAVAIL 0 0 0 was /dev/ada6 ada9 ONLINE 0 0 0 ada8 ONLINE 0 0 0 ada10 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada11 ONLINE 0 0 0 errors: No known data errors # zpool replace pool2 17439832775304853620 ada6 # zpool status pool2 pool: pool2 state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scrub: resilver in progress for 0h0m, 0.00% done, 603h22m to go config: NAME STATE READ WRITE CKSUM pool2 DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 replacing DEGRADED 0 0 0 17439832775304853620 UNAVAIL 0 0 0 was /dev/ada6/old ada6 ONLINE 0 0 0 12.1M resilvered ada9 ONLINE 0 0 0 ada8 ONLINE 0 0 0 ada10 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada11 ONLINE 0 0 0 errors: No known data errors # zpool status pool2 pool: pool2 state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scrub: resilver in progress for 0h6m, 1.48% done, 7h27m to go config: NAME STATE READ WRITE CKSUM pool2 DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 replacing DEGRADED 0 0 0 17439832775304853620 UNAVAIL 0 0 0 was /dev/ada6/old ada6 ONLINE 0 0 0 13.2G resilvered ada9 ONLINE 0 0 0 ada8 ONLINE 0 0 0 ada10 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada11 ONLINE 0 0 0 errors: No known data errors From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 19:20:32 2010 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 AC27B10656C6 for ; Wed, 3 Nov 2010 19:20:32 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 88C098FC1C for ; Wed, 3 Nov 2010 19:20:32 +0000 (UTC) Received: (qmail 13437 invoked by uid 89); 3 Nov 2010 19:20:30 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 3 Nov 2010 19:20:30 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: <4CD121F2.3010508@freebsd.org> Date: Wed, 3 Nov 2010 13:20:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <4CD121F2.3010508@freebsd.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 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, 03 Nov 2010 19:20:32 -0000 On 3 Nov 2010, at 2:48 AM, Andriy Gapon wrote: > I still would like to see verbose dmesg, just to be sure what's going = on. Here is the output of dmesg from the last working kerneL, with sources = sync'd Oct 28th: Dan --- Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-STABLE #2: Thu Oct 28 14:56:36 MDT 2010 root@u205.airwired.net:/usr/obj/usr/src/sys/DKA i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Genuine Intel(R) CPU T2400 @ 1.83GHz (1828.76-MHz = 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x6e8 Family =3D 6 Model =3D e = Stepping =3D 8 = Features=3D0xbfe9fbff Features2=3D0xc1a9 TSC: P-state invariant real memory =3D 1073741824 (1024 MB) avail memory =3D 1027780608 (980 MB) WARNING: Non-uniform processors. WARNING: Using suboptimal topology. kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3f6a0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 cpu0: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on = acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xcff8-0xcfff mem = 0xffd80000-0xffdfffff,0xe0000000-0xefffffff,0xffd40000-0xffd7ffff irq 10 = at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: mem 0xffc80000-0xffcfffff at device = 2.1 on pci0 pci0: at device 27.0 (no driver attached) pcib1: irq 11 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 11 at device 28.2 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) uhci0: port 0xcf80-0xcf9f irq = 11 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0xcf60-0xcf7f irq = 11 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0xcf40-0xcf5f irq = 11 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0xcf20-0xcf3f irq = 10 at device 29.3 on pci0 uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem = 0xffd3bc00-0xffd3bfff irq 11 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib3: at device 30.0 on pci0 pci3: on pcib3 fxp0: port 0xbf40-0xbf7f mem = 0xff9ff000-0xff9fffff irq 11 at device 8.0 on pci3 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:0e:7b:30:ca:e5 fxp0: [ITHREAD] cbb0: at device 11.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] fwohci0: <1394 Open Host Controller Interface> mem = 0xff9fe800-0xff9fefff,0xff9f8000-0xff9fbfff irq 11 at device 11.1 on = pci3 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:39:00:00:96:6a:bb fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:39:96:6a:bb fwe0: Ethernet address: 02:00:39:96:6a:bb fwip0: on firewire0 fwip0: Firewire address: 00:00:39:00:00:96:6a:bb @ 0xfffe00000000, S400, = maxrec 2048 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1078000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=3D0x00000000, SelfID Count=3D1, = CYCLEMASTER mode pci3: at device 11.2 (no driver attached) pci3: at device 11.3 (no driver = attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xafa0-0xafaf irq 11 at device 31.2 = on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] acpi_lid0: on acpi0 battery0: on acpi0 acpi_button0: on acpi0 acpi_acad0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0 atrtc0: port 0x70-0x71 irq 8 on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xe0000-0xeffff pnpid = ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 ppc0: parallel port not found. est0: on cpu0 p4tcc0: on cpu0 Timecounter "TSC" frequency 1828760835 Hz quality 800 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <=3D 0 cable IRM irm(0) (me)=20 firewire0: bus manager 0=20 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ad0: 114473MB at ata0-master UDMA100 SATA 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 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered acd0: DVDR at ata1-master UDMA33 SATA Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered Root mount waiting for: usbus4 Trying to mount root from ufs:/dev/ad0s2a ugen1.2: at usbus1 From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 19:45:41 2010 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 13576106564A for ; Wed, 3 Nov 2010 19:45:41 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id C9F2F8FC1A for ; Wed, 3 Nov 2010 19:45:40 +0000 (UTC) Received: (qmail 27854 invoked by uid 89); 3 Nov 2010 19:45:40 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 3 Nov 2010 19:45:40 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: Date: Wed, 3 Nov 2010 13:45:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <36E416FC-2F45-40C8-A7EC-0E7FA3B603A4@airwired.net> References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> To: Sergey Kandaurov , Jeremy Chadwick X-Mailer: Apple Mail (2.1081) Cc: FreeBSD-STABLE Mailing List , Andriy Gapon Subject: Re: Fatal trap 18 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, 03 Nov 2010 19:45:41 -0000 On 3 Nov 2010, at 2:18 AM, Sergey Kandaurov wrote: > + if (cpu_logical =3D=3D 0) > + cpu_logical =3D 1; /* XXX max_logical? */ > cpu_cores /=3D cpu_logical; > hyperthreading_cpus =3D cpu_logical; My machine contains an Intel Core Duo, not a Core 2 Duo. However, both = machines have 2 logical CPUs. Perhaps the bug is not handling a Core = Duo properly. I just sync'd with csup's date command as Jeremy suggested. It is = building right now. We'll see if a 2010.10.28.06.00.00 GMT system has = the problem. I doubt it does. I think this Intel logical CPU code = business is probably the culprit. It is hard to believe that I am the only one with a Core Duo machine = finding this problem! More in a bit... Dan From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 19:58:10 2010 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 9E3241065672 for ; Wed, 3 Nov 2010 19:58:10 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E40038FC08 for ; Wed, 3 Nov 2010 19:58:09 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA13524; Wed, 03 Nov 2010 21:57:43 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PDjSp-000All-L2; Wed, 03 Nov 2010 21:57:43 +0200 Message-ID: <4CD1BEB5.9050806@freebsd.org> Date: Wed, 03 Nov 2010 21:57:41 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Dan Allen References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <4CD121F2.3010508@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 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, 03 Nov 2010 19:58:10 -0000 on 03/11/2010 21:20 Dan Allen said the following: > > On 3 Nov 2010, at 2:48 AM, Andriy Gapon wrote: > >> I still would like to see verbose dmesg, just to be sure what's going on. > > Here is the output of dmesg from the last working kerneL, with sources sync'd Oct 28th: Thank you. But this is not a _verbose_ dmesg though. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 20:01:53 2010 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 EA97E1065694 for ; Wed, 3 Nov 2010 20:01:53 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3A2548FC19 for ; Wed, 3 Nov 2010 20:01:52 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA13567; Wed, 03 Nov 2010 22:01:23 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PDjWN-000Am4-Lq; Wed, 03 Nov 2010 22:01:23 +0200 Message-ID: <4CD1BF92.102@freebsd.org> Date: Wed, 03 Nov 2010 22:01:22 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Dan Allen References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <36E416FC-2F45-40C8-A7EC-0E7FA3B603A4@airwired.net> In-Reply-To: <36E416FC-2F45-40C8-A7EC-0E7FA3B603A4@airwired.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List , Jeremy Chadwick Subject: Re: Fatal trap 18 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, 03 Nov 2010 20:01:54 -0000 on 03/11/2010 21:45 Dan Allen said the following: > > On 3 Nov 2010, at 2:18 AM, Sergey Kandaurov wrote: > >> + if (cpu_logical == 0) + cpu_logical = 1; /* >> XXX max_logical? */ cpu_cores /= cpu_logical; hyperthreading_cpus = >> cpu_logical; > > My machine contains an Intel Core Duo, not a Core 2 Duo. However, both > machines have 2 logical CPUs. Perhaps the bug is not handling a Core Duo > properly. > > I just sync'd with csup's date command as Jeremy suggested. It is building > right now. We'll see if a 2010.10.28.06.00.00 GMT system has the problem. I > doubt it does. I think this Intel logical CPU code business is probably the > culprit. I am quite sure of that. > It is hard to believe that I am the only one with a Core Duo machine finding > this problem! Yeah, true. But there could be something unusual about your setup. I mean these lines from your dmesg: > WARNING: Non-uniform processors. > WARNING: Using suboptimal topology. What I propose is that we try to find a resolution, because I suppose you can't stay at the last working revision forever. P.S. so will you be trying the patch I proposed? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 20:10:59 2010 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 AF25C106564A for ; Wed, 3 Nov 2010 20:10:59 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ED1888FC0A for ; Wed, 3 Nov 2010 20:10:58 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA13692; Wed, 03 Nov 2010 22:10:32 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PDjfD-000Amp-Vb; Wed, 03 Nov 2010 22:10:31 +0200 Message-ID: <4CD1C1B7.4090706@freebsd.org> Date: Wed, 03 Nov 2010 22:10:31 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Dan Allen References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <36E416FC-2F45-40C8-A7EC-0E7FA3B603A4@airwired.net> In-Reply-To: <36E416FC-2F45-40C8-A7EC-0E7FA3B603A4@airwired.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List , Jeremy Chadwick Subject: Re: Fatal trap 18 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, 03 Nov 2010 20:10:59 -0000 on 03/11/2010 21:45 Dan Allen said the following: > > On 3 Nov 2010, at 2:18 AM, Sergey Kandaurov wrote: > >> + if (cpu_logical == 0) + cpu_logical = 1; /* >> XXX max_logical? */ cpu_cores /= cpu_logical; hyperthreading_cpus = >> cpu_logical; > > My machine contains an Intel Core Duo, not a Core 2 Duo. However, both > machines have 2 logical CPUs. Perhaps the bug is not handling a Core Duo > properly. Hm, and in your dmesg I see that you have the situation that I described: your CPU is supposedly dual-core (and supports HTT on top of that), but FreeBSD for some reason [*] sees only one cpu, e.g.: > cpu0: on acpi0 So I am quite sure that the patch that I posted should help you. [*] - yes, I do want to see your *verbose* dmesg from the working kernel. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 20:11:58 2010 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 2AF1F1065672 for ; Wed, 3 Nov 2010 20:11:58 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id C5C0A8FC16 for ; Wed, 3 Nov 2010 20:11:57 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA11.westchester.pa.mail.comcast.net with comcast id SfSy1f0040EZKEL5BkBxYY; Wed, 03 Nov 2010 20:11:57 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta01.westchester.pa.mail.comcast.net with comcast id SkBw1f00E3LrwQ23MkBxSa; Wed, 03 Nov 2010 20:11:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 203E89B422; Wed, 3 Nov 2010 13:11:55 -0700 (PDT) Date: Wed, 3 Nov 2010 13:11:55 -0700 From: Jeremy Chadwick To: Andriy Gapon Message-ID: <20101103201155.GA80641@icarus.home.lan> References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <36E416FC-2F45-40C8-A7EC-0E7FA3B603A4@airwired.net> <4CD1BF92.102@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CD1BF92.102@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Dan Allen , Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 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, 03 Nov 2010 20:11:58 -0000 On Wed, Nov 03, 2010 at 10:01:22PM +0200, Andriy Gapon wrote: > [snipping since I wanna keep it terse] > > What I propose is that we try to find a resolution, because I suppose you can't > stay at the last working revision forever. > > P.S. so will you be trying the patch I proposed? Andriy, I can try your patch out on a Core 2 Duo (E8400) which helped test the latest Intel CPU topology change when you were looking for testers (and had no problem), and can also try it out on a Core 2 Quad Q8400 if need be. Both run amd64. Let me know. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 20:25:39 2010 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 7ED08106566C for ; Wed, 3 Nov 2010 20:25:39 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 445368FC16 for ; Wed, 3 Nov 2010 20:25:39 +0000 (UTC) Received: (qmail 16104 invoked by uid 89); 3 Nov 2010 20:25:38 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 3 Nov 2010 20:25:38 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: <20101103055719.GA65417@icarus.home.lan> Date: Wed, 3 Nov 2010 14:25:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9D3D7D0B-94DC-4711-935E-C37E78C05068@airwired.net> References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <20101103055719.GA65417@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable@freebsd.org Subject: Re: Fatal trap 18 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, 03 Nov 2010 20:25:39 -0000 On 2 Nov 2010, at 11:57 PM, Jeremy Chadwick wrote: > Can you please roll your source code back to a date prior to the above > commit, rebuild, and re-try? You can accomplish this using the "date" > option in your cvsup/csup file. See csup(1) for details. I would > recommend also chopping off an additional hour "just in case". I did this and the results are as expected, i.e., everything worked just = fine. So we are zeroing in on this... Dan From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 20:26:34 2010 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 A1E781065672 for ; Wed, 3 Nov 2010 20:26:34 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 64D8D8FC18 for ; Wed, 3 Nov 2010 20:26:34 +0000 (UTC) Received: (qmail 16577 invoked by uid 89); 3 Nov 2010 20:26:34 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 3 Nov 2010 20:26:34 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: <4CD1BF92.102@freebsd.org> Date: Wed, 3 Nov 2010 14:26:33 -0600 Content-Transfer-Encoding: 7bit Message-Id: <560259EA-222B-451B-B285-A1E6BC19173E@airwired.net> References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <36E416FC-2F45-40C8-A7EC-0E7FA3B603A4@airwired.net> <4CD1BF92.102@freebsd.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List , Jeremy Chadwick Subject: Re: Fatal trap 18 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, 03 Nov 2010 20:26:34 -0000 On 3 Nov 2010, at 2:01 PM, Andriy Gapon wrote: > P.S. so will you be trying the patch I proposed? Yes. I will csup with today's sources and then apply the patch. Results soon... Dan From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 20:59:35 2010 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 A34BD1065675 for ; Wed, 3 Nov 2010 20:59:35 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E92E98FC1D for ; Wed, 3 Nov 2010 20:59:34 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA14133; Wed, 03 Nov 2010 22:59:02 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PDkQ9-000AqP-Q0; Wed, 03 Nov 2010 22:59:01 +0200 Message-ID: <4CD1CD14.4090009@freebsd.org> Date: Wed, 03 Nov 2010 22:59:00 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jeremy Chadwick References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <36E416FC-2F45-40C8-A7EC-0E7FA3B603A4@airwired.net> <4CD1BF92.102@freebsd.org> <20101103201155.GA80641@icarus.home.lan> In-Reply-To: <20101103201155.GA80641@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dan Allen , Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 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, 03 Nov 2010 20:59:35 -0000 on 03/11/2010 22:11 Jeremy Chadwick said the following: > On Wed, Nov 03, 2010 at 10:01:22PM +0200, Andriy Gapon wrote: >> [snipping since I wanna keep it terse] >> >> What I propose is that we try to find a resolution, because I suppose you can't >> stay at the last working revision forever. >> >> P.S. so will you be trying the patch I proposed? > > Andriy, > > I can try your patch out on a Core 2 Duo (E8400) which helped test > the latest Intel CPU topology change when you were looking for testers > (and had no problem), and can also try it out on a Core 2 Quad Q8400 > if need be. Both run amd64. But I suppose you don't have any problems? :) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 21:09:07 2010 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 533BB1065670 for ; Wed, 3 Nov 2010 21:09:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id EFA258FC18 for ; Wed, 3 Nov 2010 21:09:06 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta14.westchester.pa.mail.comcast.net with comcast id SjyW1f00327AodY5El97FT; Wed, 03 Nov 2010 21:09:07 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta19.westchester.pa.mail.comcast.net with comcast id Sl951f00E3LrwQ23fl96jE; Wed, 03 Nov 2010 21:09:07 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 97E799B422; Wed, 3 Nov 2010 14:09:04 -0700 (PDT) Date: Wed, 3 Nov 2010 14:09:04 -0700 From: Jeremy Chadwick To: Andriy Gapon Message-ID: <20101103210904.GA81698@icarus.home.lan> References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <36E416FC-2F45-40C8-A7EC-0E7FA3B603A4@airwired.net> <4CD1BF92.102@freebsd.org> <20101103201155.GA80641@icarus.home.lan> <4CD1CD14.4090009@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CD1CD14.4090009@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Dan Allen , Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 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, 03 Nov 2010 21:09:07 -0000 On Wed, Nov 03, 2010 at 10:59:00PM +0200, Andriy Gapon wrote: > on 03/11/2010 22:11 Jeremy Chadwick said the following: > > On Wed, Nov 03, 2010 at 10:01:22PM +0200, Andriy Gapon wrote: > >> [snipping since I wanna keep it terse] > >> > >> What I propose is that we try to find a resolution, because I suppose you can't > >> stay at the last working revision forever. > >> > >> P.S. so will you be trying the patch I proposed? > > > > Andriy, > > > > I can try your patch out on a Core 2 Duo (E8400) which helped test > > the latest Intel CPU topology change when you were looking for testers > > (and had no problem), and can also try it out on a Core 2 Quad Q8400 > > if need be. Both run amd64. > > But I suppose you don't have any problems? :) Correct; with the original patch you wanted tested, I saw no problems on either of the above systems. But I haven't rebuilt kernel since you MFC'd the patch. Anyway, it sounds like me testing isn't necessary since you have a pretty good idea of what's going on with Dan's setup. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 21:15:39 2010 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 D7498106566C for ; Wed, 3 Nov 2010 21:15:39 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 245118FC15 for ; Wed, 3 Nov 2010 21:15:38 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA14379; Wed, 03 Nov 2010 23:15:24 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PDkg0-000Arr-4j; Wed, 03 Nov 2010 23:15:24 +0200 Message-ID: <4CD1D0EB.7020909@freebsd.org> Date: Wed, 03 Nov 2010 23:15:23 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jeremy Chadwick References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <36E416FC-2F45-40C8-A7EC-0E7FA3B603A4@airwired.net> <4CD1BF92.102@freebsd.org> <20101103201155.GA80641@icarus.home.lan> <4CD1CD14.4090009@freebsd.org> <20101103210904.GA81698@icarus.home.lan> In-Reply-To: <20101103210904.GA81698@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dan Allen , Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 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, 03 Nov 2010 21:15:39 -0000 on 03/11/2010 23:09 Jeremy Chadwick said the following: > Anyway, it sounds like me testing isn't necessary since you have a > pretty good idea of what's going on with Dan's setup. I hope that I won't need any extra testing here, but I will keep your offer in mind if anything goes different from my expectations. And thanks a lot for the offer! Right now I want to squeeze out everything possible from Dan :-) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 21:17:33 2010 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 C98041065675 for ; Wed, 3 Nov 2010 21:17:33 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 8ABFA8FC0A for ; Wed, 3 Nov 2010 21:17:33 +0000 (UTC) Received: (qmail 11191 invoked by uid 89); 3 Nov 2010 21:17:31 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 3 Nov 2010 21:17:31 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: <20101103210904.GA81698@icarus.home.lan> Date: Wed, 3 Nov 2010 15:17:27 -0600 Content-Transfer-Encoding: 7bit Message-Id: <1D66762C-27BC-45DA-B966-8C39B7EBF3CE@airwired.net> References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <36E416FC-2F45-40C8-A7EC-0E7FA3B603A4@airwired.net> <4CD1BF92.102@freebsd.org> <20101103201155.GA80641@icarus.home.lan> <4CD1CD14.4090009@freebsd.org> <20101103210904.GA81698@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1081) Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List , Andriy Gapon Subject: Re: Fatal trap 18 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, 03 Nov 2010 21:17:33 -0000 On 3 Nov 2010, at 3:09 PM, Jeremy Chadwick wrote: > Anyway, it sounds like me testing isn't necessary since you have a > pretty good idea of what's going on with Dan's setup. Well I am certainly testing, and the patch that Andriy posted WORKS! Steps: 1. I csup'd to today's very latest sources. 2. Installed the patch. 3. Rebuilt and reinstalled the kernel. 4. Boots up fine! So, will this patch be integrated into STABLE soon? Dan From owner-freebsd-stable@FreeBSD.ORG Wed Nov 3 21:23:45 2010 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 293E0106566B for ; Wed, 3 Nov 2010 21:23:45 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6A73B8FC13 for ; Wed, 3 Nov 2010 21:23:44 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA14453; Wed, 03 Nov 2010 23:23:27 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PDknn-000Asb-FQ; Wed, 03 Nov 2010 23:23:27 +0200 Message-ID: <4CD1D2CF.8050904@freebsd.org> Date: Wed, 03 Nov 2010 23:23:27 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Dan Allen References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <36E416FC-2F45-40C8-A7EC-0E7FA3B603A4@airwired.net> <4CD1BF92.102@freebsd.org> <20101103201155.GA80641@icarus.home.lan> <4CD1CD14.4090009@freebsd.org> <20101103210904.GA81698@icarus.home.lan> <1D66762C-27BC-45DA-B966-8C39B7EBF3CE@airwired.net> In-Reply-To: <1D66762C-27BC-45DA-B966-8C39B7EBF3CE@airwired.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List , Jeremy Chadwick Subject: Re: Fatal trap 18 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, 03 Nov 2010 21:23:45 -0000 on 03/11/2010 23:17 Dan Allen said the following: > > On 3 Nov 2010, at 3:09 PM, Jeremy Chadwick wrote: > >> Anyway, it sounds like me testing isn't necessary since you have a >> pretty good idea of what's going on with Dan's setup. > > Well I am certainly testing, and the patch that Andriy posted WORKS! > > Steps: > > 1. I csup'd to today's very latest sources. > 2. Installed the patch. > 3. Rebuilt and reinstalled the kernel. > 4. Boots up fine! > > So, will this patch be integrated into STABLE soon? Yes. Most likely I will commit it to head tomorrow and then MFC it after three or so days. Thank you for the report and testing again! -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Nov 4 09:57:35 2010 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 80115106566C for ; Thu, 4 Nov 2010 09:57:35 +0000 (UTC) (envelope-from simonln@me.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 67B698FC0C for ; Thu, 4 Nov 2010 09:57:35 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [10.6.2.126] (fr.ffw.spectronic-systems.com [90.184.203.251]) by asmtp024.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LBC00ENHRI5ZA00@asmtp024.mac.com>; Thu, 04 Nov 2010 01:56:32 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-04_04:2010-11-04, 2010-11-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1011040035 From: "Simon L. B. Nielsen" Date: Thu, 04 Nov 2010 09:55:28 +0100 To: freebsd-stable@freebsd.org, freebsd-current Message-id: X-Mailer: Apple Mail (2.1081) Cc: Subject: svn2cvs replication down for the moment 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, 04 Nov 2010 09:57:35 -0000 Hey, The FreeBSD svn2cvs exporter is currently down and won't be fixed until tonight CET at the earliest. This basically mean that until that is fixed, any change in svn (IE, src/) won't be available via CVS or CVSup. A change yesterday morning "replaced" an entire directory, which svn2cvs don't know how to deal with. As it's an entire directory I can't just use our usual hack and ignore the delete part as that will leave files in the directory in CVS which wasn't supposed to be there. As that not a quick thing to do I won't be able to fix it before getting home from work. -- Simon L. B. Nielsen Hat: FreeBSD.org cluster admins team From owner-freebsd-stable@FreeBSD.ORG Thu Nov 4 21:33:31 2010 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 A072E106566B; Thu, 4 Nov 2010 21:33:30 +0000 (UTC) (envelope-from simon@nitro.dk) Received: from smtp.fullrate.dk (smtp.fullrate.dk [90.185.1.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5F8498FC1D; Thu, 4 Nov 2010 21:33:30 +0000 (UTC) Received: from [192.168.4.26] (4304ds2-vlb.1.fullrate.dk [90.184.171.166]) by smtp.fullrate.dk (Postfix) with ESMTP id 4CF209CD84; Thu, 4 Nov 2010 22:14:01 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Simon L. B. Nielsen" In-Reply-To: Date: Thu, 4 Nov 2010 22:14:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <69CE6B92-910F-4F45-9376-175901A9B4CA@nitro.dk> References: To: Simon L. B. Nielsen X-Mailer: Apple Mail (2.1081) Cc: freebsd-current , freebsd-stable@freebsd.org Subject: Re: svn2cvs replication down for the moment 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, 04 Nov 2010 21:33:31 -0000 On 4 Nov 2010, at 09:55, Simon L. B. Nielsen wrote: > The FreeBSD svn2cvs exporter is currently down and won't be fixed = until tonight CET at the earliest. This basically mean that until that = is fixed, any change in svn (IE, src/) won't be available via CVS or = CVSup. >=20 > A change yesterday morning "replaced" an entire directory, which = svn2cvs don't know how to deal with. > As it's an entire directory I can't just use our usual hack and ignore = the delete part as that will leave files in the directory in CVS which = wasn't supposed to be there. After some handholding (and 'evil' direct cvs commit) cvs2svn is now = running again. --=20 Simon L. B. Nielsen Hat: FreeBSD.org cluster admins team From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 06:01:30 2010 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 56FD21065672 for ; Fri, 5 Nov 2010 06:01:30 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 200CC8FC13 for ; Fri, 5 Nov 2010 06:01:29 +0000 (UTC) Received: by iwn39 with SMTP id 39so2397753iwn.13 for ; Thu, 04 Nov 2010 23:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:cc:content-type; bh=k22tQvk6Etyk5q2Qn37JKKDU762K6oYEhpm0o3NCBU0=; b=M9fpzvS3UKUFnnkhhCASRmO2pGU1X1yPGBE/6NKDAfIBBXuFN5uCEcPoT6QENbd6YA Prtivg7THBMN3qbXRUw2fP46YWMwtAjdq7sV3Nv2hfaGZsyE4h1LB3EJ5wSrP2OcvkF/ urgA04k+TtkvcZDgQFzmdu+u8v3xdQTeRsh5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=qZtpGLfR+GHZ5SqvkPnOVaAUETrHzd0s/x2+DWiG9ivDKYf/1pVygBHIOFCuf9Zq6v G/EyH6B2UjyIXsuA/Jpv+bmJUeQ8Ms1nCfgRUrZ0mU5LzOiG6ebtceRsbg5+6KMiU3Zd bDo2uTF9f2nq5te2iz4zbfsap/HxQlTL0FFq8= MIME-Version: 1.0 Received: by 10.231.168.70 with SMTP id t6mr1313772iby.145.1288935315235; Thu, 04 Nov 2010 22:35:15 -0700 (PDT) Received: by 10.231.184.79 with HTTP; Thu, 4 Nov 2010 22:35:15 -0700 (PDT) Date: Thu, 4 Nov 2010 22:35:15 -0700 Message-ID: From: Josh Carroll To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: rmacklem@uoguelph.ca Subject: NFS deadlock (unkillable nfsd and no mounts work) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@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, 05 Nov 2010 06:01:30 -0000 Greetings! I'm having a problem with nfsd hanging and not serving mount points, during which time it can not not be killed. This problem started happening sometime after November 2nd, since kernel from 11/2 sources does not exhibit this problem. The current kernel I'm running is via SVN I just grabbed this evening (around 5pm PDT on November 4th), but I was having the same problem yesterday around 9pm PDT after a csup yesterday (I switched to SVN today to rule out a stale /usr/src from an out of sync cvsup mirror). Here are the svn details: Path: /usr/src URL: svn://svn.freebsd.org/base/stable/8 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 214807 Node Kind: directory Schedule: normal Last Changed Author: jhb Last Changed Rev: 214791 Last Changed Date: 2010-11-04 10:25:31 -0700 (Thu, 04 Nov 2010) uname -a: FreeBSD 8.1-STABLE FreeBSD 8.1-STABLE #0 r214807: Thu Nov 4 17:13:05 PDT 2010 root@pflog.net:/usr/obj/usr/src/sys/PFLOG amd64 I have a Popcorn Hour, and as soon as I try to connect to my NFS mount with it, it hangs on the Popcorn Hour, then eventually pops up a message that says "Request cannot be processed". Likewise if I try to mount it from my macbook, it hangs then later just says operation timed out or something like that, after it hangs for quite a while. During this hang, there is nothing in /var/log indicating a problem nor any other indications something is wrong, except that none of my NFS mounts work and the nfsd process will not die. When I try to reboot the server, I wind up having to fsck all my drives (except the ZFS one), since nfsd will not die. Even kill -9 doesn't kill it (it's showing as in the D state): root 444 0.0 0.0 5812 1384 ?? D 9:30PM 0:00.00 nfsd: server (nfsd) And if I try to /etc/rc.d/nfsd stop, it just says: Stopping nfsd. Waiting for PIDS: 444 And hangs there indefinitely. I tried to run a ktrace on both the "nfsd: server" and "nfsd: master" processes (ktrace -i -d -f nfsd_server.ktrace and ktrace -i -d -f nfsd_master.ktrace), but when I try to connect to the NFS mount, ktrace doesn't capture anything and the "nfsd: server" process goes to the "D" state and then I can't kill it. If I try to kill the nfsd process BEFORE I attempt to mount anything, it properly stops with /etc/rc.d/nfsd stop or with a kill -TERM. Once I've tried to connect once, however, it can't be killed. Hoping it was perhaps related to ZFS, I commented out the one ZFS mount point in /etc/exports, but it still causes this deadlock in the nfsd process. I even went as far as to comment everything in /etc/exports and create a new export on a different disk, which did not help, I get the same nfsd hang. Another strange thing, if I try to truss on the "nfsd: server" process (the child) before I try to mount anything, it causes the process to exit immediately along with truss. If I look at what truss captured for it, I see: 411: sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 411: sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 411: process exit, rval = 0 My kernel built from sources on 11/2 works fine, so it's something that has changed sometime after November 2nd. At least, my kernel from November 2nd runs fine and does not have this nfsd lockup problem. My kernel is just GENERIC with a few additions: include GENERIC device pf device pflog device coretemp device uchcom device sound device snd_hda option NETATALK option ALTQ option ALTQ_CBQ option ALTQ_HFSC option ALTQ_NOPCC option ALTQ_PRIQ option ALTQ_RED option ALTQ_RIO option COMPAT_LINUX32 option GEOM_MIRROR option LIBICONV option LIBMCHAIN option NETSMB option NULLFS option SMBFS option UDF nooption INET6 If any other information is needed, please let me know. What are the next things I should be doing to diagnose the problem? It seems specific to nfsd, but I'm not sure how to prove it's that and not something related or complimentary to nfsd. For what it's worth rpcbind and mountd both stop fine, it's just the nfsd process that is locking up. Thanks in advance for any advice on troubleshooting or root-causing the issue would be appreciated. Regards, Josh From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 13:21:52 2010 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 6D28D106566C for ; Fri, 5 Nov 2010 13:21:52 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B03C38FC21 for ; Fri, 5 Nov 2010 13:21:51 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA13409; Fri, 05 Nov 2010 15:21:48 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD404EB.4090005@icyb.net.ua> Date: Fri, 05 Nov 2010 15:21:47 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: josh.carroll@gmail.com References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rmacklem@uoguelph.ca, freebsd-stable@freebsd.org Subject: Re: NFS deadlock (unkillable nfsd and no mounts work) 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, 05 Nov 2010 13:21:52 -0000 on 05/11/2010 07:35 Josh Carroll said the following: > Greetings! > > I'm having a problem with nfsd hanging and not serving mount points, > during which time it can not not be killed. This problem started > happening sometime after November 2nd, since kernel from 11/2 sources > does not exhibit this problem. > > The current kernel I'm running is via SVN I just grabbed this evening > (around 5pm PDT on November 4th), but I was having the same problem > yesterday around 9pm PDT after a csup yesterday (I switched to SVN > today to rule out a stale /usr/src from an out of sync cvsup mirror). > Here are the svn details: > > Path: /usr/src > URL: svn://svn.freebsd.org/base/stable/8 > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 214807 > Node Kind: directory > Schedule: normal > Last Changed Author: jhb > Last Changed Rev: 214791 > Last Changed Date: 2010-11-04 10:25:31 -0700 (Thu, 04 Nov 2010) > > uname -a: > > FreeBSD 8.1-STABLE FreeBSD 8.1-STABLE #0 r214807: Thu Nov 4 17:13:05 > PDT 2010 root@pflog.net:/usr/obj/usr/src/sys/PFLOG amd64 > > I have a Popcorn Hour, and as soon as I try to connect to my NFS mount > with it, it hangs on the Popcorn Hour, then eventually pops up a > message that says "Request cannot be processed". Likewise if I try to > mount it from my macbook, it hangs then later just says operation > timed out or something like that, after it hangs for quite a while. > > During this hang, there is nothing in /var/log indicating a problem > nor any other indications something is wrong, except that none of my > NFS mounts work and the nfsd process will not die. > > When I try to reboot the server, I wind up having to fsck all my > drives (except the ZFS one), since nfsd will not die. Even kill -9 > doesn't kill it (it's showing as in the D state): > > root 444 0.0 0.0 5812 1384 ?? D 9:30PM 0:00.00 nfsd: server (nfsd) You can try 'procstat -kk ' next time this happens. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 13:24:09 2010 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 64679106566C; Fri, 5 Nov 2010 13:24:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id EB5F58FC15; Fri, 5 Nov 2010 13:24:08 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEABOi00yDaFvO/2dsb2JhbACDKZ85qnKRBIRUcwSKVQ X-IronPort-AV: E=Sophos;i="4.58,301,1286164800"; d="scan'208";a="99728790" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 05 Nov 2010 09:24:08 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id F36C3B3F49; Fri, 5 Nov 2010 09:24:07 -0400 (EDT) Date: Fri, 5 Nov 2010 09:24:07 -0400 (EDT) From: Rick Macklem To: josh carroll Message-ID: <1984713101.142889.1288963447940.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_142888_1552817635.1288963447938" X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: kib , freebsd-stable@freebsd.org, jhb@freebsd.org Subject: Re: NFS deadlock (unkillable nfsd and no mounts work) 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, 05 Nov 2010 13:24:09 -0000 ------=_Part_142888_1552817635.1288963447938 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > Greetings! > > I'm having a problem with nfsd hanging and not serving mount points, > during which time it can not not be killed. This problem started > happening sometime after November 2nd, since kernel from 11/2 sources > does not exhibit this problem. Please try the attached patch, rick ps: Starting about Monday I won't be able to do commits for about 3 weeks so, if this patch works, could someone else please commit it, thanks, rick ------=_Part_142888_1552817635.1288963447938 Content-Type: text/x-patch; name=nfs_serv.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=nfs_serv.patch LS0tIG5mc19zZXJ2LmMuc2F2CTIwMTAtMTEtMDUgMDg6MTU6NTcuMDAwMDAwMDAwIC0wNDAwDQor KysgbmZzX3NlcnYuYwkyMDEwLTExLTA1IDA4OjE4OjQwLjAwMDAwMDAwMCAtMDQwMA0KQEAgLTMy NTIsNyArMzI1Miw3IEBADQogCQkJbmZocC0+ZmhfZnNpZCA9IG52cC0+dl9tb3VudC0+bW50X3N0 YXQuZl9mc2lkOw0KIAkJCWlmICgoZXJyb3IxID0gVk9QX1ZQVE9GSChudnAsICZuZmhwLT5maF9m aWQpKSA9PSAwKQ0KIAkJCQllcnJvcjEgPSBWT1BfR0VUQVRUUihudnAsIHZhcCwgY3JlZCk7DQot CQkJaWYgKHZwID09IG52cCkNCisJCQlpZiAodXNldmdldCA9PSAwICYmIHZwID09IG52cCkNCiAJ CQkJdnVucmVmKG52cCk7DQogCQkJZWxzZQ0KIAkJCQl2cHV0KG52cCk7DQo= ------=_Part_142888_1552817635.1288963447938-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 14:53:52 2010 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 E744F1065696 for ; Fri, 5 Nov 2010 14:53:52 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id A8FAE8FC16 for ; Fri, 5 Nov 2010 14:53:52 +0000 (UTC) Received: (qmail 14742 invoked by uid 89); 5 Nov 2010 14:53:49 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 5 Nov 2010 14:53:49 -0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dan Allen In-Reply-To: <4CD11FE9.8050105@freebsd.org> Date: Fri, 5 Nov 2010 08:53:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 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, 05 Nov 2010 14:53:53 -0000 On 3 Nov 2010, at 2:40 AM, Andriy Gapon wrote: > This problem seems to happen only on SMP systems that for some reason = run as UP. > E.g. because ACPI and/or APIC are disabled. > Or some other BIOS configuration. > But I am not sure what exactly is the case here. Okay, I have been researching my UP/SMP problem. In the past, before recent "Intel topology" changes, on my Toshiba = Satellite U205 machine if I used a kernel with ACPI support, only 1 = logical CPU showed up in FreeBSD 8.1-STABLE. When I booted into Windows = XP on the same machine, with the same BIOS settings, I would see 2 = logical CPUs. If I built a FreeBSD kernel WITHOUT ACPI support and left = the BIOS settings as they were above, I then would see 2 logical CPUs. Now with these recent FreeBSD changes I cannot get the machine to EVER = recognize a 2nd logical processor, but if I boot into Windows XP I still = see two CPUs, so we still have a bug in this new Intel topology code. This laptop has an Intel Core Duo T2400 @ 1.83 GHz chip. (The BIOS is = set to provide multiple logical CPUs in all cases and Andriy, I am using = your patched kernel.) Is there anything else I can do to help you understand this system = config? What next? Dan From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 15:22:55 2010 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 3D6461065672 for ; Fri, 5 Nov 2010 15:22:55 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 855C38FC19 for ; Fri, 5 Nov 2010 15:22:54 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA15756; Fri, 05 Nov 2010 17:22:15 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD42127.5070902@icyb.net.ua> Date: Fri, 05 Nov 2010 17:22:15 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Dan Allen References: <68E248E0-8619-4859-BFFE-1B5F5ABBC51F@airwired.net> <4CD11FE9.8050105@freebsd.org> <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> In-Reply-To: <5224E1F5-4567-45A8-A12C-868F7B45BC21@airwired.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sergey Kandaurov , FreeBSD-STABLE Mailing List Subject: Re: Fatal trap 18 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, 05 Nov 2010 15:22:55 -0000 on 05/11/2010 16:53 Dan Allen said the following: > > On 3 Nov 2010, at 2:40 AM, Andriy Gapon wrote: > >> This problem seems to happen only on SMP systems that for some reason run as UP. >> E.g. because ACPI and/or APIC are disabled. >> Or some other BIOS configuration. >> But I am not sure what exactly is the case here. > > Okay, I have been researching my UP/SMP problem. > > In the past, before recent "Intel topology" changes, on my Toshiba Satellite U205 machine if I used a kernel with ACPI support, only 1 logical CPU showed up in FreeBSD 8.1-STABLE. When I booted into Windows XP on the same machine, with the same BIOS settings, I would see 2 logical CPUs. If I built a FreeBSD kernel WITHOUT ACPI support and left the BIOS settings as they were above, I then would see 2 logical CPUs. > > Now with these recent FreeBSD changes I cannot get the machine to EVER recognize a 2nd logical processor, but if I boot into Windows XP I still see two CPUs, so we still have a bug in this new Intel topology code. Technically speaking this has nothing to do with topology code. Topology code decides how detected (logical) CPUs are layed out, whether there are multiple sockets, or cores, or both, or etc. Different code is responsible for discovering those multiple processors in the first place. And that code can not work without proper assistance from BIOS. > This laptop has an Intel Core Duo T2400 @ 1.83 GHz chip. (The BIOS is set to provide multiple logical CPUs in all cases and Andriy, I am using your patched kernel.) > > Is there anything else I can do to help you understand this system config? > > What next? Let's look at the following: 0. your kernel config 1. verbose dmesg 2. acpidump -dt output 3. x86info -a (sysutils/x86info) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 16:38:13 2010 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 7C54E1065697 for ; Fri, 5 Nov 2010 16:38:13 +0000 (UTC) (envelope-from thomas.e.zander@googlemail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 38BD98FC14 for ; Fri, 5 Nov 2010 16:38:12 +0000 (UTC) Received: by qwg8 with SMTP id 8so2619506qwg.13 for ; Fri, 05 Nov 2010 09:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=st2rlfUkUQ4Qh4EB/W58ZyTwaV6qFMNATVmbUdMovaE=; b=ph2cI4tr61F5a+j5vR+KFIz/GuvLNNWC/ZYOQLCnp46fxHVlY5I80GMpFhjzT3WOpK hFxt5sKUEGXqekV6gq9xMPaWEC9B4irkKOlyH7VF6Vgu1IiD4SGakp6YXFDLzkLuHhZv pApcsfujuztm1MllAxDXvS6vW6VIR5rQb+Wn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ctiW8UBBDBGBlNZGj6tjJWFgERpkwMUbiwN4HSRUS2LnAVqLRE/Pj7p0cAY36Wd8Ru ClNSGYGWVwTE5RtirzUW7hN+BNFfCnm76uO5XNpSAcWnyNyq+4M2X0A1YC1ZcXf0xoK5 mprJo8E87W2QgbFmZF//dt+GVsigimDsdzO1Q= MIME-Version: 1.0 Received: by 10.224.20.70 with SMTP id e6mr1038847qab.356.1288973354736; Fri, 05 Nov 2010 09:09:14 -0700 (PDT) Received: by 10.229.249.135 with HTTP; Fri, 5 Nov 2010 09:09:14 -0700 (PDT) Date: Fri, 5 Nov 2010 17:09:14 +0100 Message-ID: From: Thomas Zander To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Subject: How to tell whether ECC (memory) is enabled? 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, 05 Nov 2010 16:38:13 -0000 Dear, is there any way to inspect a running STABLE machine for the presence or state of ECC memory before an MCA "error detected" message actually occurs? In comparison when I quickly boot the machine in question with a Linux live CD, I find (among other EDAC messages) the following output in its dmesg: ... EDAC amd64: ECC is enabled by BIOS, Proceeding with EDAC module initialization ... During POST, die BIOS also tells me that ECC memory is installed, so far so good. But I was a little surprised that the FreeBSD kernel tells me absolutely nothing about it. Or do I have to tune loader.conf variables? TIA, Riggs From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 17:27:11 2010 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 CE207106566B for ; Fri, 5 Nov 2010 17:27:11 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 70A218FC14 for ; Fri, 5 Nov 2010 17:27:11 +0000 (UTC) Received: by gxk9 with SMTP id 9so2416432gxk.13 for ; Fri, 05 Nov 2010 10:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=AOThzfot3tT+rYuJFwj61Y6mtQtQTjAZsI5FkSCY7GA=; b=gf8NwOxHucGGgIKBGC6FpKz8U24phHHRDGT8I+WTSDe7f0VwEwaHyZYvXFh30FvDN3 ih/9+s0z6fz2hOuuO/TozscgLOHWWnOZ8gbwThkLp6p1owOWRf7kOQ+v1TKClJ1XseMy XyJzjWMA7D5BGsjwFzK11AsoJWFvRYQDqBCAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=E3+FTeLmZ5JR6k39ea2kG+6mnHBlEOO/vRgrUhFz16FO1bktLceXi03IhM0SL52Slk dEX/pz5aIkTLwXo0heIkSVe7RKR3gBNYaUZdXrzzouNCxLtb4StJJjZz8rkiWMPXuOuL lEwdSntMB21HGJcjIhmcBiR7F2URD6lk2hdLs= MIME-Version: 1.0 Received: by 10.42.166.193 with SMTP id p1mr361122icy.399.1288978030223; Fri, 05 Nov 2010 10:27:10 -0700 (PDT) Received: by 10.231.184.79 with HTTP; Fri, 5 Nov 2010 10:27:09 -0700 (PDT) In-Reply-To: <1984713101.142889.1288963447940.JavaMail.root@erie.cs.uoguelph.ca> References: <1984713101.142889.1288963447940.JavaMail.root@erie.cs.uoguelph.ca> Date: Fri, 5 Nov 2010 10:27:09 -0700 Message-ID: From: Josh Carroll To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: kib , freebsd-stable@freebsd.org, jhb@freebsd.org Subject: Re: NFS deadlock (unkillable nfsd and no mounts work) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@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, 05 Nov 2010 17:27:12 -0000 >> I'm having a problem with nfsd hanging and not serving mount points, >> during which time it can not not be killed. This problem started >> happening sometime after November 2nd, since kernel from 11/2 sources >> does not exhibit this problem. > > Please try the attached patch, rick Thanks! I had to manually patch for some reason, but I can confirmed that nfsd is now well-behaved with your patch applied. I tested a couple of different mounts and played two separate files on the Popcorn Hour (one lower bitrate, the other higher bitrate) and both played without a hiccup. While those were playing I also was able to automount my home directory on the macbook and move around my home directory. So it looks like this patch did the trick. Thanks Rick, really appreciate the fast response. Is there a reason why this doesn't seem to be getting reported a lot? What is particular in my setup that broke it? > ps: Starting about Monday I won't be able to do commits for about 3 weeks > =A0 =A0so, if this patch works, could someone else please commit it, than= ks, > =A0 =A0rick > If someone can commit this, I'd really appreciate it. I will report back if I notice any problems, but I imagine this would probably get fixed in HEAD first, then MFC'd anyway, right? Unless this is already fixed in HEAD. Anyway, thanks again Rick! I appreciate it. Regards, Josh As far as I can tell, there have been no adverse effects or regressions with the kernel built with this patch (I had t From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 18:17:09 2010 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 DFE4F10656C4 for ; Fri, 5 Nov 2010 18:17:09 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 6B9428FC12 for ; Fri, 5 Nov 2010 18:17:08 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-078-042-098-160.hsi3.kabel-badenwuerttemberg.de [78.42.98.160]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id F2F637E9AB for ; Fri, 5 Nov 2010 19:17:07 +0100 (CET) Message-ID: <4CD44A23.2030707@bsdforen.de> Date: Fri, 05 Nov 2010 19:17:07 +0100 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.15) Gecko/20101028 Thunderbird/3.0.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: fetch hangs when trying to http-download from http://ftp5.de.FreeBSD.org/ 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, 05 Nov 2010 18:17:10 -0000 This is an example, I can download the file with firefox, but fetch hangs infinitely, even though HTTP_TIMEOUT is set. http://ftp5.de.FreeBSD.org/pub/FreeBSD/ports/amd64/packages-8-stable/All/ecore-txt-0.9.9.042.tbz The HTTP headers with firefox: GET /pub/FreeBSD/ports/amd64/packages-8-stable/All/ecore-txt-0.9.9.042.tbz HTTP/1.1 Host: ftp5.de.freebsd.org User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.2.12) Gecko/20101029 Firefox/3.6.12 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: UTF-8,* Keep-Alive: 15 Connection: keep-alive Cache-Control: no-cache HTTP/1.1 200 OK Date: Fri, 05 Nov 2010 18:06:36 GMT Server: Cherokee/1.0.1 (UNIX) Etag: 4c9492b8=19c2 Last-Modified: Sat, 18 Sep 2010 10:21:44 GMT Content-Length: 6594 The output of fetch -vv: scheme: [http] user: [] password: [] host: [ftp5.de.FreeBSD.org] port: [0] document: [/pub/FreeBSD/ports/amd64/packages-8-stable/All/ecore-txt-0.9.9.042.tbz] ---> ftp5.de.FreeBSD.org:80 looking up ftp5.de.FreeBSD.org connecting to ftp5.de.FreeBSD.org:80 requesting http://ftp5.de.FreeBSD.org/pub/FreeBSD/ports/amd64/packages-8-stable/All/ecore-txt-0.9.9.042.tbz >>> GET /pub/FreeBSD/ports/amd64/packages-8-stable/All/ecore-txt-0.9.9.042.tbz HTTP/1.1 >>> Host: ftp5.de.FreeBSD.org >>> User-Agent: fetch libfetch/2.0 >>> Connection: close >>> <<< HTTP/1.1 200 OK <<< Connection: close <<< Date: Fri, 05 Nov 2010 18:13:04 GMT <<< Server: Cherokee/1.0.1 (UNIX) <<< ETag: 4c9492b8=19c2 <<< Last-Modified: Sat, 18 Sep 2010 10:21:44 GMT <<< Content-Length: 6594 last modified: [2010-09-18 10:21:44] <<< content length: [6594] offset 0, length -1, size -1, clength 6594 remote size / mtime: 6594 / 1284805304 ecore-txt-0.9.9.042.tbz 0% of 6594 B 0 Bps The last line stays like this until I kill the process. I don't see anything that worries me in the headers, no idea what goes wrong. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 18:51:03 2010 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 7D55F106566B; Fri, 5 Nov 2010 18:51:03 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A50328FC1D; Fri, 5 Nov 2010 18:51:02 +0000 (UTC) Received: by bwz3 with SMTP id 3so2930031bwz.13 for ; Fri, 05 Nov 2010 11:51:01 -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:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=TKPZQ4B/pYcWI+c0Jv3uhc3o4lpVrFV8bm/BjjSEveU=; b=QCooEPeu5hR2Dd1olNCcaH/t8t4A73h731tOp/KgeMPdgmwBMa0fSfNTc1TqTdfBdA 2FjZ9HfEEOqi4moKS0yf1g8lj8FTCIBAQnnckkx1NMiEwZppuq3O9h7oezWyLXdZXC05 +pxhgOIiYxdSJATnOxdkx5a/xlWegyJ+fkN/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=B+hLhEM/W247tAT0gszapiOSMYEhx0HqFYsXzd8O8FVvltJNo+aoGbG1NlkSshtAUA X1VsuWRir7dz2t5NYzC60+k9ttbHNntrUqUfN0Un7qMIn4pLPIHPIDBpFGg1Lr7Ytsip r5A86otQ3zrTXNCuktb2kphe5FB6IysX55OhE= Received: by 10.204.79.142 with SMTP id p14mr2170956bkk.175.1288983061541; Fri, 05 Nov 2010 11:51:01 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id d12sm1251680bkw.19.2010.11.05.11.50.59 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 11:51:00 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CD45209.5010607@FreeBSD.org> Date: Fri, 05 Nov 2010 20:50:49 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: FreeBSD-Current , FreeBSD Stable , freebsd-scsi@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: Sense fetching [Was: cdrtools /devel ...] 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, 05 Nov 2010 18:51:03 -0000 Hi. I've reviewed tests that scgcheck does to SCSI subsystem. It shown combination of several issues in both CAM, ahci(4) and cdrtools itself. Several small patches allow us to pass most of that tests: http://people.freebsd.org/~mav/sense/ ahci_resid.patch: Add support for reporting residual length on data underrun. SCSI commands often returns results shorter then expected. Returned value allows application to know/check how much data it really has. It is also important for sense fetching, as ATAPI and USB devices return sense as data in response to REQUEST_SENSE command. sense_resid.patch: When manually requesting sense data (ATAPI or USB), request only as much data as user requested (not the fixed structure size), and return respective sense residual length. pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon as device freeze released before returning to user-level, user-level application by definition can't reliably fetch sense data if some other application (like hald) tries to access device same time. cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit wanted sense length to CAM and do not clear sense return buffer. It is mostly cosmetics, important probably only for scgcheck. Testers and reviewers welcome. I am especially interested in opinion about pass_autosence.patch -- may be we should lower sense fetching even deeper, to make it work for all cam_periph_runccb() consumers. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 19:34:43 2010 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 ACB35106566B; Fri, 5 Nov 2010 19:34:43 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 3E0318FC1C; Fri, 5 Nov 2010 19:34:42 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id oA5JKSXw068846; Fri, 5 Nov 2010 20:20:28 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id oA5JKSWu068845; Fri, 5 Nov 2010 20:20:28 +0100 (CET) (envelope-from marius) Date: Fri, 5 Nov 2010 20:20:28 +0100 From: Marius Strobl To: Alexander Motin Message-ID: <20101105192028.GA68728@alchemy.franken.de> References: <4CD45209.5010607@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CD45209.5010607@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Joerg.Schilling@fokus.fraunhofer.de, freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] 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, 05 Nov 2010 19:34:43 -0000 On Fri, Nov 05, 2010 at 08:50:49PM +0200, Alexander Motin wrote: > Hi. > > I've reviewed tests that scgcheck does to SCSI subsystem. It shown > combination of several issues in both CAM, ahci(4) and cdrtools itself. > Several small patches allow us to pass most of that tests: > http://people.freebsd.org/~mav/sense/ > > ahci_resid.patch: Add support for reporting residual length on data > underrun. SCSI commands often returns results shorter then expected. > Returned value allows application to know/check how much data it really > has. It is also important for sense fetching, as ATAPI and USB devices > return sense as data in response to REQUEST_SENSE command. > > sense_resid.patch: When manually requesting sense data (ATAPI or USB), > request only as much data as user requested (not the fixed structure > size), and return respective sense residual length. > > pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch > sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon > as device freeze released before returning to user-level, user-level > application by definition can't reliably fetch sense data if some other > application (like hald) tries to access device same time. > > cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit > wanted sense length to CAM and do not clear sense return buffer. It is > mostly cosmetics, important probably only for scgcheck. Please don't commit this to the port directly but let it loop back via upstream (CC'ed) instead, otherwise we would need to obey the following, which is undesirable, especially if these really are mostly cosmetic issues: /* * Warning: you may change this source, but if you do that * you need to change the _scg_version and _scg_auth* string below. * You may not return "schily" for an SCG_AUTHOR request anymore. * Choose your name instead of "schily" and make clear that the version * string is related to a modified source. */ > > Testers and reviewers welcome. I am especially interested in opinion > about pass_autosence.patch -- may be we should lower sense fetching even > deeper, to make it work for all cam_periph_runccb() consumers. > Marius From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 19:50:51 2010 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 61D28106567A for ; Fri, 5 Nov 2010 19:50:51 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 202D78FC17 for ; Fri, 5 Nov 2010 19:50:50 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-078-042-098-160.hsi3.kabel-badenwuerttemberg.de [78.42.98.160]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id E08987E9B6 for ; Fri, 5 Nov 2010 20:50:49 +0100 (CET) Message-ID: <4CD46018.8060207@bsdforen.de> Date: Fri, 05 Nov 2010 20:50:48 +0100 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.15) Gecko/20101028 Thunderbird/3.0.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4CD44A23.2030707@bsdforen.de> In-Reply-To: <4CD44A23.2030707@bsdforen.de> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: fetch hangs when trying to http-download from http://ftp5.de.FreeBSD.org/ 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, 05 Nov 2010 19:50:51 -0000 On 05/11/2010 19:17, Dominic Fandrey wrote: > This is an example, I can download the file with firefox, > but fetch hangs infinitely, even though HTTP_TIMEOUT is set. > http://ftp5.de.FreeBSD.org/pub/FreeBSD/ports/amd64/packages-8-stable/All/ecore-txt-0.9.9.042.tbz The problem has gone away. I suppose there's no way of debugging this without being able to reproduce it. :( -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 19:59:50 2010 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 9C396106566B for ; Fri, 5 Nov 2010 19:59:50 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 812668FC08 for ; Fri, 5 Nov 2010 19:59:50 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta10.emeryville.ca.mail.comcast.net with comcast id TR031f0080vp7WLAAXzpFE; Fri, 05 Nov 2010 19:59:49 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta05.emeryville.ca.mail.comcast.net with comcast id TXzo1f00R3LrwQ28RXzoqC; Fri, 05 Nov 2010 19:59:49 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 868169B422; Fri, 5 Nov 2010 12:59:48 -0700 (PDT) Date: Fri, 5 Nov 2010 12:59:48 -0700 From: Jeremy Chadwick To: Dominic Fandrey Message-ID: <20101105195948.GA29963@icarus.home.lan> References: <4CD44A23.2030707@bsdforen.de> <4CD46018.8060207@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CD46018.8060207@bsdforen.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: fetch hangs when trying to http-download from http://ftp5.de.FreeBSD.org/ 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, 05 Nov 2010 19:59:50 -0000 On Fri, Nov 05, 2010 at 08:50:48PM +0100, Dominic Fandrey wrote: > On 05/11/2010 19:17, Dominic Fandrey wrote: > > This is an example, I can download the file with firefox, > > but fetch hangs infinitely, even though HTTP_TIMEOUT is set. > > http://ftp5.de.FreeBSD.org/pub/FreeBSD/ports/amd64/packages-8-stable/All/ecore-txt-0.9.9.042.tbz > > The problem has gone away. > > I suppose there's no way of debugging this without being able to > reproduce it. :( There's a lot of ways of debugging this, but "fetch -v" isn't going to provide enough information. :-) Hitting Control-T while the process is hung would help, ditto with (in another window) running procstat -kk on the PID of fetch, and "ps -axl | grep fetch". Running fetch under ktrace (with the flag "-t+") might shed some light on what's going on too. You also eventually might need to familiarise yourself with tcpdump if it's an IP/TCP issue. You're also going to need to state if you're using any sort of firewalling stack on the machine itself (ipfw, ipfilter, pf), or if there's a firewall in front of your machine (including NAT). Finally, it would help if you could narrow down the problem to that single mirror server (ftp5.de.FreeBSD.org) or if it happens to you when using other servers as well. Oh, and uname -a output would help too, since you didn't disclose what FreeBSD build/release you're running. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 20:12:35 2010 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 319791065670 for ; Fri, 5 Nov 2010 20:12:35 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id E05538FC15 for ; Fri, 5 Nov 2010 20:12:34 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-078-042-098-160.hsi3.kabel-badenwuerttemberg.de [78.42.98.160]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 45EF87E8AA; Fri, 5 Nov 2010 21:12:33 +0100 (CET) Message-ID: <4CD46530.9080106@bsdforen.de> Date: Fri, 05 Nov 2010 21:12:32 +0100 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.15) Gecko/20101028 Thunderbird/3.0.10 MIME-Version: 1.0 To: Jeremy Chadwick References: <4CD44A23.2030707@bsdforen.de> <4CD46018.8060207@bsdforen.de> <20101105195948.GA29963@icarus.home.lan> In-Reply-To: <20101105195948.GA29963@icarus.home.lan> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: fetch hangs when trying to http-download from http://ftp5.de.FreeBSD.org/ 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, 05 Nov 2010 20:12:35 -0000 On 05/11/2010 20:59, Jeremy Chadwick wrote: > On Fri, Nov 05, 2010 at 08:50:48PM +0100, Dominic Fandrey wrote: >> On 05/11/2010 19:17, Dominic Fandrey wrote: >>> This is an example, I can download the file with firefox, >>> but fetch hangs infinitely, even though HTTP_TIMEOUT is set. >>> http://ftp5.de.FreeBSD.org/pub/FreeBSD/ports/amd64/packages-8-stable/All/ecore-txt-0.9.9.042.tbz >> >> The problem has gone away. >> >> I suppose there's no way of debugging this without being able to >> reproduce it. :( > > There's a lot of ways of debugging this, but "fetch -v" isn't going to > provide enough information. :-) Hitting Control-T while the process is > hung would help, ditto with (in another window) running procstat -kk on > the PID of fetch, and "ps -axl | grep fetch". ... All that requires me to reproduce it. > ... > > Finally, it would help if you could narrow down the problem to that > single mirror server (ftp5.de.FreeBSD.org) or if it happens to you when > using other servers as well. I tried 9 mirrors, this was the only one that caused the problem. I tried dozens of files, the problem occurred with all my attempts. This is RELENG_8: FreeBSD mobileKamikaze.norad 8.1-STABLE FreeBSD 8.1-STABLE #0: Thu Oct 14 01:07:07 CEST 2010 root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6510b-8 amd64 -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 20:21:19 2010 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 23EA11065675 for ; Fri, 5 Nov 2010 20:21:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id C2F118FC19 for ; Fri, 5 Nov 2010 20:21:18 +0000 (UTC) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta10.westchester.pa.mail.comcast.net with comcast id TPmi1f0051uE5Es5AYMJkb; Fri, 05 Nov 2010 20:21:18 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta16.westchester.pa.mail.comcast.net with comcast id TYMH1f00T3LrwQ23cYMJtT; Fri, 05 Nov 2010 20:21:18 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 83E569B422; Fri, 5 Nov 2010 13:21:16 -0700 (PDT) Date: Fri, 5 Nov 2010 13:21:16 -0700 From: Jeremy Chadwick To: Dominic Fandrey Message-ID: <20101105202116.GA30415@icarus.home.lan> References: <4CD44A23.2030707@bsdforen.de> <4CD46018.8060207@bsdforen.de> <20101105195948.GA29963@icarus.home.lan> <4CD46530.9080106@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CD46530.9080106@bsdforen.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: fetch hangs when trying to http-download from http://ftp5.de.FreeBSD.org/ 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, 05 Nov 2010 20:21:19 -0000 On Fri, Nov 05, 2010 at 09:12:32PM +0100, Dominic Fandrey wrote: > On 05/11/2010 20:59, Jeremy Chadwick wrote: > > On Fri, Nov 05, 2010 at 08:50:48PM +0100, Dominic Fandrey wrote: > >> On 05/11/2010 19:17, Dominic Fandrey wrote: > >>> This is an example, I can download the file with firefox, > >>> but fetch hangs infinitely, even though HTTP_TIMEOUT is set. > >>> http://ftp5.de.FreeBSD.org/pub/FreeBSD/ports/amd64/packages-8-stable/All/ecore-txt-0.9.9.042.tbz > >> > >> The problem has gone away. > >> > >> I suppose there's no way of debugging this without being able to > >> reproduce it. :( > > > > There's a lot of ways of debugging this, but "fetch -v" isn't going to > > provide enough information. :-) Hitting Control-T while the process is > > hung would help, ditto with (in another window) running procstat -kk on > > the PID of fetch, and "ps -axl | grep fetch". ... > > All that requires me to reproduce it. Welcome to the joys of debugging. :-) What I'm saying is "fetch -v" is simply insufficient for a problem report. The above should give you some more stuff to run the next time you see it. > > ... > > > > Finally, it would help if you could narrow down the problem to that > > single mirror server (ftp5.de.FreeBSD.org) or if it happens to you when > > using other servers as well. > > I tried 9 mirrors, this was the only one that caused the problem. I > tried dozens of files, the problem occurred with all my attempts. > > This is RELENG_8: > FreeBSD mobileKamikaze.norad 8.1-STABLE FreeBSD 8.1-STABLE #0: Thu Oct 14 01:07:07 CEST 2010 root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6510b-8 amd64 Since you're only seeing this problem with a single mirror, I'd recommend 1) stop using it, and 2) report the problem to the freebsd-hubs mailing list. Usually the mirror maintainers hang out there. Possibly something is going on with the machine itself or the surrounding network which is causing this anomaly for you (and possibly others who just haven't noticed it regularly, re: only happens sometimes). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 20:25:51 2010 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 AB3EE10656AB for ; Fri, 5 Nov 2010 20:25:51 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 698718FC1B for ; Fri, 5 Nov 2010 20:25:51 +0000 (UTC) Received: by qwg8 with SMTP id 8so2804506qwg.13 for ; Fri, 05 Nov 2010 13:25:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.192.76 with SMTP id dp12mr2375993qcb.63.1288986856607; Fri, 05 Nov 2010 12:54:16 -0700 (PDT) Received: by 10.229.235.67 with HTTP; Fri, 5 Nov 2010 12:54:16 -0700 (PDT) X-Originating-IP: [93.203.53.2] In-Reply-To: References: Date: Fri, 5 Nov 2010 20:54:16 +0100 Message-ID: From: "C. P. Ghost" To: Thomas Zander Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable Subject: Re: How to tell whether ECC (memory) is enabled? 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, 05 Nov 2010 20:25:51 -0000 On Fri, Nov 5, 2010 at 5:09 PM, Thomas Zander wrote: > Dear, > > is there any way to inspect a running STABLE machine for the presence > or state of ECC memory before an MCA "error detected" message actually > occurs? > In comparison when I quickly boot the machine in question with a Linux > live CD, I find (among other EDAC messages) the following output in > its dmesg: > > ... > EDAC amd64: ECC is enabled by BIOS, Proceeding with EDAC module initialization > ... > > During POST, die BIOS also tells me that ECC memory is installed, so > far so good. But I was a little surprised that the FreeBSD kernel > tells me absolutely nothing about it. Or do I have to tune loader.conf > variables? Have you tried 'dmidecode' (as run), from the port sysutils/dmidecode? > TIA, > Riggs -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 20:34:38 2010 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 B10491065679 for ; Fri, 5 Nov 2010 20:34:38 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 73CC78FC17 for ; Fri, 5 Nov 2010 20:34:38 +0000 (UTC) Received: by iwn39 with SMTP id 39so3245001iwn.13 for ; Fri, 05 Nov 2010 13:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=tdnZ0fcmRjzveWkKoQJ/yz1tfo7EwmMlPb3Rh9CaSOg=; b=YBw8zPuWIH7jhD6Z18HZ/CzOVqiGbXxARFElygJ2C8XtscqqpqnNeP4fgULg//0RP6 sZNT9cMxmYm8jOB0luL35l1yN7pGYueiRzzhKbS89VS54XK0/x7X5CFFh5clDNxyaGXz u1XaESnrGKeYWWKnRTxp9IKZm8Y0+gyEF47t8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=yA/kFbnT2l5LH3+5N2FaWf6nG4+LxxD20rKN2di1KZOccnn+FikngHAvZn0H428BMS LhHWOu2zO8tI0ZMNridwjiDSH04fPjO3uO0x6Ar1w0Ore+hokhoR488NGMCkL16WHPTu xjVmp7IPoag8em7AsQm8ql4hIHFXJDfM00fOU= MIME-Version: 1.0 Received: by 10.231.168.70 with SMTP id t6mr2088079iby.145.1288989277618; Fri, 05 Nov 2010 13:34:37 -0700 (PDT) Received: by 10.231.184.79 with HTTP; Fri, 5 Nov 2010 13:34:37 -0700 (PDT) In-Reply-To: <4CD46530.9080106@bsdforen.de> References: <4CD44A23.2030707@bsdforen.de> <4CD46018.8060207@bsdforen.de> <20101105195948.GA29963@icarus.home.lan> <4CD46530.9080106@bsdforen.de> Date: Fri, 5 Nov 2010 13:34:37 -0700 Message-ID: From: Josh Carroll To: Dominic Fandrey Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: fetch hangs when trying to http-download from http://ftp5.de.FreeBSD.org/ X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@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, 05 Nov 2010 20:34:38 -0000 On Fri, Nov 5, 2010 at 1:12 PM, Dominic Fandrey wrot= e: > On 05/11/2010 20:59, Jeremy Chadwick wrote: >> On Fri, Nov 05, 2010 at 08:50:48PM +0100, Dominic Fandrey wrote: >>> On 05/11/2010 19:17, Dominic Fandrey wrote: >>>> This is an example, I can download the file with firefox, >>>> but fetch hangs infinitely, even though HTTP_TIMEOUT is set. >>>> http://ftp5.de.FreeBSD.org/pub/FreeBSD/ports/amd64/packages-8-stable/A= ll/ecore-txt-0.9.9.042.tbz >>> >>> The problem has gone away. >>> >>> I suppose there's no way of debugging this without being able to >>> reproduce it. :( >> >> There's a lot of ways of debugging this, but "fetch -v" isn't going to >> provide enough information. =A0:-) =A0Hitting Control-T while the proces= s is >> hung would help, ditto with (in another window) running procstat -kk on >> the PID of fetch, and "ps -axl | grep fetch". =A0... > > All that requires me to reproduce it. I can reproduce it. Here's the info Jeremy requested in a previous mail from my machine where I'm still able to reproduce it (FreeBSD 8.1-STABLE #0 r214807M amd64 arch): floyd@pflog:~% fetch http://ftp5.de.FreeBSD.org/pub/FreeBSD/ports/amd64/packages-8-stable/All/ec= ore-txt-0.9.9.042.tbz ecore-txt-0.9.9.042.tbz 0% of 6594 B 0 Bps At this point it hangs, so I hit ctrl-T and get: load: 0.06 cmd: fetch 97042 [sbwait] 3.50r 0.00u 0.00s 0% 2688k And then ctrl-c'ing the process I see: ecore-txt-0.9.9.042.tbz 62% of 6594 B 744 Bps fetch: transfer interrupted ps -axl for fetch shows: 1001 5382 28735 0 44 0 11964 2704 sbwait S+ 2 0:00.00 fetch: ecore-txt-0.9.9.042.tbz [0% of 6594 B] (fet And here is procstat -kk output: PID TID COMM TDNAME KSTACK 5382 100304 fetch - mi_switch+0x169 sleepq_catch_signals+0x300 sleepq_wait_sig+0xc _sleep+0x251 soreceive_generic+0xf0c dofileread+0x88 kern_readv+0x52 read+0x4e syscallenter+0x181 syscall+0x40 Xfast_syscall+0xe2 ktrace on the process after it hangs shows nothing. I let it run for 30 seconds or more, then ktrace -C'd and don't see anything in the kdump output: root@pflog:~# kdump -f fetch.ktrace root@pflog:~# However, if I ktrace it from the beginning with: ktrace fetch .... Here's the last 30 lines of the output from kdump after it has hung (the trace file no longer gets written to once the fetch process hangs): 0x01f0 f71b 1a83 ad6c 91a6 930e 26b3 8993 c859 f5a3 3dcb 683c af54 621d 0544 b487 3f9d 5730 7e4f 15b8 52e5 f2b6 1584 3ef3 99fa 4326 2910 31b0 3598 c38e 0eae 6d0b |.....l....&....Y..=3D.h<.Tb..D..?.W0~O..R.....>...C&).1.5.....m.| 0x022e c354 7c11 264c ee0f e093 b2d0 4e32 a315 02f1 be3b 0553 7a2b 1466 5195 9a02 21ed 8dd9 99ae 1e03 1f21 0983 a1a3 57f8 fc0d bf49 126b c727 021e f882 edec a5f2 |.T|.&L......N2.....;.Sz+.fQ...!........!....W....I.k.'........| 0x026c e969 905e 5f04 c9dd 36e1 7675 1090 04b0 5407 9129 b113 5127 9189 a83e f066 8088 32c0 b3a6 5fec b06f f67c 1f88 a318 c46d fdf9 66ea 06af 2d65 8cde c324 b6a6 |.i.^_...6.vu....T..)..Q'...>.f..2..._..o.|.....m..f...-e...$..| 0x02aa 804e 91d2 08e2 7d53 5f13 76d6 c486 5168 d6d9 39c3 b88f dbaa 2452 81a9 ce18 1117 31a7 4690 0883 c944 9804 8858 469c 65e5 3c4e 12e7 d582 9cb4 10b6 3b02 e42e |.N....}S_.v...Qh..9.....$R......1.F....D...XF.e. 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 CD86F1065672; Fri, 5 Nov 2010 21:04:52 +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 3E1898FC08; Fri, 5 Nov 2010 21:04:50 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAB4O1EyDaFvO/2dsb2JhbACDKJ8zqnuQcoEigVKBYXMEilY X-IronPort-AV: E=Sophos;i="4.58,305,1286164800"; d="scan'208";a="97967335" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 05 Nov 2010 17:04:50 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 3EBDDB3F5A; Fri, 5 Nov 2010 17:04:50 -0400 (EDT) Date: Fri, 5 Nov 2010 17:04:50 -0400 (EDT) From: Rick Macklem To: josh carroll Message-ID: <1563115557.181398.1288991090198.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-stable@freebsd.org, kib , jhb@freebsd.org Subject: Re: NFS deadlock (unkillable nfsd and no mounts work) 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, 05 Nov 2010 21:04:52 -0000 > >> I'm having a problem with nfsd hanging and not serving mount > >> points, > >> during which time it can not not be killed. This problem started > >> happening sometime after November 2nd, since kernel from 11/2 > >> sources > >> does not exhibit this problem. > > > > Please try the attached patch, rick >=20 > Thanks! I had to manually patch for some reason, but I can confirmed > that nfsd is now well-behaved with your patch applied. I tested a > couple of different mounts and played two separate files on the > Popcorn Hour (one lower bitrate, the other higher bitrate) and both > played without a hiccup. While those were playing I also was able to > automount my home directory on the macbook and move around my home > directory. >=20 > So it looks like this patch did the trick. Thanks Rick, really > appreciate the fast response. Is there a reason why this doesn't seem > to be getting reported a lot? What is particular in my setup that > broke it? >=20 Well, the commit that broke things just hit stable/8 on Nov. 3. Also, I'm not sure what scenarios would have caused the breakage. I think it would be something like a file system where vget worked that dropped out of the loop just after looking up "." or ".." at the root, so that the nvp remained locked. But I'm not sure what the exact scenarios are? (Holding the shared lock shouldn't have stopped further VFS_VGET()s from succeeding, I think?) > > ps: Starting about Monday I won't be able to do commits for about 3 > > weeks > > =C2=A0 =C2=A0so, if this patch works, could someone else please commit = it, > > thanks, > > =C2=A0 =C2=A0rick > > >=20 > If someone can commit this, I'd really appreciate it. I will report > back if I notice any problems, but I imagine this would probably get > fixed in HEAD first, then MFC'd anyway, right? Unless this is already > fixed in HEAD. >=20 The patch isn't in head, but hopefully someone like kib@ or jhb@ can do it, since I won't be able to MFC it before code freeze. They might have a better patch? Anyhow, good to hear it fixes the problem. Thanks for reporting the problem and testing the patch, rick From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 21:22:15 2010 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 1991A106566C for ; Fri, 5 Nov 2010 21:22:15 +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 DF9268FC19 for ; Fri, 5 Nov 2010 21:22:14 +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 5E8A846B03; Fri, 5 Nov 2010 17:22:14 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8255A8A009; Fri, 5 Nov 2010 17:22:13 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 5 Nov 2010 17:21:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051721.05898.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 05 Nov 2010 17:22:13 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Thomas Zander Subject: Re: How to tell whether ECC (memory) is enabled? 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, 05 Nov 2010 21:22:15 -0000 On Friday, November 05, 2010 12:09:14 pm Thomas Zander wrote: > Dear, > > is there any way to inspect a running STABLE machine for the presence > or state of ECC memory before an MCA "error detected" message actually > occurs? > In comparison when I quickly boot the machine in question with a Linux > live CD, I find (among other EDAC messages) the following output in > its dmesg: > > ... > EDAC amd64: ECC is enabled by BIOS, Proceeding with EDAC module initialization > ... > > During POST, die BIOS also tells me that ECC memory is installed, so > far so good. But I was a little surprised that the FreeBSD kernel > tells me absolutely nothing about it. Or do I have to tune loader.conf > variables? I think the EDAC register is using the registers for the QPI PCI buses. There is a driver now to export those PCI buses to the OS in 7.x+. However, someone would need to port the EDAC driver (or something similar) to work with those devices. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 21:28:02 2010 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 87F20106566C; Fri, 5 Nov 2010 21:28:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 19D4B8FC0C; Fri, 5 Nov 2010 21:28:01 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oA5LRvYF038804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Nov 2010 23:27:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oA5LRvZ4055999; Fri, 5 Nov 2010 23:27:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oA5LRvIm055998; Fri, 5 Nov 2010 23:27:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 5 Nov 2010 23:27:57 +0200 From: Kostik Belousov To: Josh Carroll Message-ID: <20101105212757.GG2392@deviant.kiev.zoral.com.ua> References: <1984713101.142889.1288963447940.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZdqPkeGXoIZADpbP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Rick Macklem , freebsd-stable@freebsd.org, jhb@freebsd.org, avg@freebsd.org Subject: Re: NFS deadlock (unkillable nfsd and no mounts work) 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, 05 Nov 2010 21:28:02 -0000 --ZdqPkeGXoIZADpbP Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 05, 2010 at 10:27:09AM -0700, Josh Carroll wrote: > >> I'm having a problem with nfsd hanging and not serving mount points, > >> during which time it can not not be killed. This problem started > >> happening sometime after November 2nd, since kernel from 11/2 sources > >> does not exhibit this problem. > > > > Please try the attached patch, rick >=20 > Thanks! I had to manually patch for some reason, but I can confirmed > that nfsd is now well-behaved with your patch applied. I tested a > couple of different mounts and played two separate files on the > Popcorn Hour (one lower bitrate, the other higher bitrate) and both > played without a hiccup. While those were playing I also was able to > automount my home directory on the macbook and move around my home > directory. >=20 > So it looks like this patch did the trick. Thanks Rick, really > appreciate the fast response. Is there a reason why this doesn't seem > to be getting reported a lot? What is particular in my setup that > broke it? >=20 > > ps: Starting about Monday I won't be able to do commits for about 3 wee= ks > > =9A =9Aso, if this patch works, could someone else please commit it, th= anks, > > =9A =9Arick > > >=20 > If someone can commit this, I'd really appreciate it. I will report > back if I notice any problems, but I imagine this would probably get > fixed in HEAD first, then MFC'd anyway, right? Unless this is already > fixed in HEAD. >=20 > Anyway, thanks again Rick! I appreciate it. >=20 > Regards, > Josh > As far as I can tell, there have been no adverse effects or > regressions with the kernel built with this patch (I had t I agree that the fix a right fix for real issue. It should only affect the filesystems that do support VFS_VGET(). In other words, it is relevant for e.g. UFS exports, but not for ZFS, that is the Andrey case. The change is committed as r214851 with shortest MFC timeout possible. There is further issue with use of VOP_ISLOCKED(). Andrey, can you try this untested change in your settings ? Thanks and sorry. diff --git a/sys/nfsserver/nfs_serv.c b/sys/nfsserver/nfs_serv.c index 2b9131f..668b02c 100644 --- a/sys/nfsserver/nfs_serv.c +++ b/sys/nfsserver/nfs_serv.c @@ -3037,6 +3037,7 @@ nfsrv_readdirplus(struct nfsrv_descript *nfsd, struct= nfssvc_sock *slp, struct vattr va, at, *vap =3D &va; struct nfs_fattr *fp; int len, nlen, rem, xfer, tsiz, i, error =3D 0, error1, getret =3D 1; + int vp_locked; int siz, cnt, fullsiz, eofflag, rdonly, dirlen, ncookies; u_quad_t off, toff, verf; u_long *cookies =3D NULL, *cookiep; /* needs to be int64_t or off_t */ @@ -3067,10 +3068,12 @@ nfsrv_readdirplus(struct nfsrv_descript *nfsd, stru= ct nfssvc_sock *slp, fullsiz =3D siz; error =3D nfsrv_fhtovp(fhp, 1, &vp, &vfslocked, nfsd, slp, nam, &rdonly, TRUE); + vp_locked =3D 1; if (!error && vp->v_type !=3D VDIR) { error =3D ENOTDIR; vput(vp); vp =3D NULL; + vp_locked =3D 0; } if (error) { nfsm_reply(NFSX_UNSIGNED); @@ -3090,6 +3093,7 @@ nfsrv_readdirplus(struct nfsrv_descript *nfsd, struct= nfssvc_sock *slp, error =3D nfsrv_access(vp, VEXEC, cred, rdonly, 0); if (error) { vput(vp); + vp_locked =3D 0; vp =3D NULL; nfsm_reply(NFSX_V3POSTOPATTR); nfsm_srvpostop_attr(getret, &at); @@ -3097,6 +3101,7 @@ nfsrv_readdirplus(struct nfsrv_descript *nfsd, struct= nfssvc_sock *slp, goto nfsmout; } VOP_UNLOCK(vp, 0); + vp_locked =3D 0; rbuf =3D malloc(siz, M_TEMP, M_WAITOK); again: iv.iov_base =3D rbuf; @@ -3110,6 +3115,7 @@ again: io.uio_td =3D NULL; eofflag =3D 0; vn_lock(vp, LK_SHARED | LK_RETRY); + vp_locked =3D 1; if (cookies) { free((caddr_t)cookies, M_TEMP); cookies =3D NULL; @@ -3118,6 +3124,7 @@ again: off =3D (u_quad_t)io.uio_offset; getret =3D VOP_GETATTR(vp, &at, cred); VOP_UNLOCK(vp, 0); + vp_locked =3D 0; if (!cookies && !error) error =3D NFSERR_PERM; if (!error) @@ -3238,8 +3245,10 @@ again: } else { cn.cn_flags &=3D ~ISDOTDOT; } - if (!VOP_ISLOCKED(vp)) + if (!vp_locked) { vn_lock(vp, LK_SHARED | LK_RETRY); + vp_locked =3D 1; + } if ((vp->v_vflag & VV_ROOT) !=3D 0 && (cn.cn_flags & ISDOTDOT) !=3D 0) { vref(vp); @@ -3342,7 +3351,7 @@ invalid: cookiep++; ncookies--; } - if (!usevget && VOP_ISLOCKED(vp)) + if (!usevget && vp_locked) vput(vp); else vrele(vp); --ZdqPkeGXoIZADpbP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzUdtwACgkQC3+MBN1Mb4h7rgCgzrTfMysveofKNTshv4CuxZBM sIoAn0WT9bd1K9Oq1hHiXwUs4gyFAo9t =WGCj -----END PGP SIGNATURE----- --ZdqPkeGXoIZADpbP-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 22:00:44 2010 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 5793E106566C for ; Fri, 5 Nov 2010 22:00:44 +0000 (UTC) (envelope-from ds@ukrhub.net) Received: from relay.ukrhub.net (relay.ukrhub.net [212.90.160.3]) by mx1.freebsd.org (Postfix) with ESMTP id 144088FC17 for ; Fri, 5 Nov 2010 22:00:43 +0000 (UTC) Received: from chaos.ukrhub.net (chaos.ukrhub.net [212.90.160.54]) by relay.ukrhub.net (Postfix) with ESMTP id 8B4F41C13B; Fri, 5 Nov 2010 23:40:45 +0200 (EET) Received: by chaos.ukrhub.net (Postfix, from userid 1000) id D319C40CE; Fri, 5 Nov 2010 23:40:55 +0200 (EET) Date: Fri, 5 Nov 2010 23:40:55 +0200 From: Taras Korenko To: Dominic Fandrey Message-ID: <20101105214055.GA9926@chaos.ukrhub.net> References: <4CD44A23.2030707@bsdforen.de> <4CD46018.8060207@bsdforen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-u Content-Disposition: inline In-Reply-To: <4CD46018.8060207@bsdforen.de> User-Agent: Mutt/1.4.2.3i X-PGP-Key: http://chaos.ukrhub.net/ds.asc X-PGP-Fingerprint: 5128 2A8B 9BC1 A664 21E0 1E61 D838 54D3 8ACC C68B Cc: freebsd-stable@freebsd.org Subject: Re: fetch hangs when trying to http-download from http://ftp5.de.FreeBSD.org/ X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Taras Korenko List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 22:00:44 -0000 On Fri, Nov 05, 2010 at 08:50:48PM +0100, Dominic Fandrey wrote: > On 05/11/2010 19:17, Dominic Fandrey wrote: > > This is an example, I can download the file with firefox, > > but fetch hangs infinitely, even though HTTP_TIMEOUT is set. > > http://ftp5.de.FreeBSD.org/pub/FreeBSD/ports/amd64/packages-8-stable/All/ecore-txt-0.9.9.042.tbz > > The problem has gone away. > I've stored two tcpdumps of fetch & wget conversations. Currently I've no explanation of what's caused that difference in behaviour of fetch and wget. When the file is fetch-ed there are lost two packet fragments from server side (right after 'ack 4345'). Subsequent starts of fetch gave the same result in tcpdump's output. Here are the tcpdumps: http://chaos.ukrhub.net/ftp5.de/ -- Best regards, Taras Korenko From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 22:33:36 2010 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 3E03C106564A for ; Fri, 5 Nov 2010 22:33:36 +0000 (UTC) (envelope-from ras@gerbil.cluepon.net) Received: from gerbil.cluepon.net (cluepon.net [204.93.176.74]) by mx1.freebsd.org (Postfix) with ESMTP id 0F6DC8FC16 for ; Fri, 5 Nov 2010 22:33:35 +0000 (UTC) Received: from gerbil.cluepon.net (ras@localhost [127.0.0.1]) by gerbil.cluepon.net (8.14.4/8.14.4) with ESMTP id oA5MGjgo026420; Fri, 5 Nov 2010 17:16:45 -0500 (CDT) (envelope-from ras@gerbil.cluepon.net) Received: (from ras@localhost) by gerbil.cluepon.net (8.14.4/8.14.4/Submit) id oA5MGjMR026419; Fri, 5 Nov 2010 17:16:45 -0500 (CDT) (envelope-from ras) Date: Fri, 5 Nov 2010 17:16:45 -0500 From: Richard A Steenbergen To: Josh Carroll Message-ID: <20101105221645.GE1902@gerbil.cluepon.net> References: 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) Cc: rmacklem@uoguelph.ca, freebsd-stable@freebsd.org Subject: Re: NFS deadlock (unkillable nfsd and no mounts work) 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, 05 Nov 2010 22:33:36 -0000 On Thu, Nov 04, 2010 at 10:35:15PM -0700, Josh Carroll wrote: > Greetings! > > I'm having a problem with nfsd hanging and not serving mount points, > during which time it can not not be killed. This problem started > happening sometime after November 2nd, since kernel from 11/2 sources > does not exhibit this problem. I had a similar issue on -current a few weeks ago, with processes that would lock up and become unkillable when they tried to access certain parts of the filesystem (running all zfs here). One time it managed to lock up every time you'd do an ls /, but a reboot would always clear it, then a few days later it would pop up again somewhere else. I never lost any data, zfs never found anything wrong, and the drives and hw all checked out. I sync'd up with the latest -current on oct 18th and it stopped happening (or maybe I just stopped noticing it, entirely possible for a very lightly used personal box), plus I was traveling and super busy at the time, so I didn't bother pursuing it further. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From owner-freebsd-stable@FreeBSD.ORG Fri Nov 5 23:24:29 2010 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 3B9C0106564A for ; Fri, 5 Nov 2010 23:24:29 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id F192C8FC12 for ; Fri, 5 Nov 2010 23:24:28 +0000 (UTC) Received: by iwn39 with SMTP id 39so3399681iwn.13 for ; Fri, 05 Nov 2010 16:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=hE8uRMy5+yEFalXTMXdvPoyEQWcfkuO8ONcllJ6bhi8=; b=p/NeSvzqHy2A151Lk4+bfezc+kxSWwT6ngGhLinvR4NYpd155+gz/ka8qFAdqPgynD Pn5Qr2QIH6l7DnCDZWg3YCB/66usFfpL10LNSkcwaogJCYpIC+4niBtImOLVAWDftphy B/BPn0u35pULYryb7b3LMxXFJ9rB4FDQ73UTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=e7ei6oZaj9e7QUavmCZ5tZ0Avwi3LdjCozRJxAB0HfHVjUqCwvv9Iuuu9p8HdlgYD3 gUa55ESc6ryU9LE/9z1v0bgnXsbRVNwqsYNvzBYCvpa9+y0hDBsFto7OGc0bQ+DyWNul MCAf4ZkHsx3bRkTQp4YG95dGgdVJAbuCn4qHM= MIME-Version: 1.0 Received: by 10.231.143.202 with SMTP id w10mr2074948ibu.195.1288999468257; Fri, 05 Nov 2010 16:24:28 -0700 (PDT) Received: by 10.231.184.79 with HTTP; Fri, 5 Nov 2010 16:24:28 -0700 (PDT) In-Reply-To: References: <4CD44A23.2030707@bsdforen.de> <4CD46018.8060207@bsdforen.de> <20101105195948.GA29963@icarus.home.lan> <4CD46530.9080106@bsdforen.de> Date: Fri, 5 Nov 2010 16:24:28 -0700 Message-ID: From: Josh Carroll To: Dominic Fandrey Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: fetch hangs when trying to http-download from http://ftp5.de.FreeBSD.org/ X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@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, 05 Nov 2010 23:24:29 -0000 > Here's the last 30 lines of the output from kdump after it has hung > (the trace file no longer gets written to once the fetch process > hangs): *snip* > =A038016 fetch =A0 =A0RET =A0 read 53/0x35 > =A038016 fetch =A0 =A0CALL =A0read(0x3,0x81006835,0x3cb) I believe this read corresponds to this part of fetch.c (with line numbers for reference from stable/8 svn): 625 if ((size =3D fread(buf, 1, size, f)) =3D=3D 0) { 626 if (ferror(f) && errno =3D=3D EINTR && !sigint) 627 clearerr(f); 628 else 629 break; 630 } This fread() never returns the second time through the loop in the bad case. Since I'm not very good with gdb, I just added some printf()'s throughout this section of the code and pulled the fread() out of the if() so I could check the return value explicitly. Comparing a fetch from that http server and from my own local http server (with a copy of the file in question) shows the following. The first time through the loop, the first 4096 bytes are properly read in: before stat_start() ecore-txt-0.9.9.042.tbz 0% of 6594 B 0 Bpsafter stat_start() reset sigalrm, siginfo and sigint to 0 setup SIGINFO handler while we don't get a sigint size set to B_size: 4096 Before calling: size =3D fread(buf, 1, 4096, f) (fileno(f) is: -1) after fread(), fread returned setting size =3D 4096 After check for size ?=3D 0 and fread() After stat_update() while we don't get a sigint size =3D 6594 - 4096 =3D 2498 size after: 2498 Before calling: size =3D fread(buf, 1, 2498, f) (fileno(f) is: -1) But this is where it hangs in the case of that particular server/file combination. If I fetch the same file from my local apache server, I see it properly read the remaining 2498 bytes and finish up: after fread(), fread returned setting size =3D 2498 After check for size ?=3D 0 and fread() After stat_update() while we don't get a sigint size =3D 6594 - 6594 =3D 0 size after: 0 Before calling: size =3D fread(buf, 1, 0, f) (fileno(f) is: -1) after fread(), fread returned setting size =3D 0 fread() returned 0 We weren't interrupted, break out of while() AFTER large while(!sigint) loop !sigalarm Set SIGINFO back to SIG_DFL Before stat_end() ecore-txt-0.9.9.042.tbz 100% of 6594 B 59 MBps after stat_end() So for some reason it's hanging during that second fread() for that particular file for that particular server. Perhaps the pcap Taras provided will shed some light on why this fread() is hanging. I was able to fetch a different tarball (zsh-4.3.10_4.tbz) from that server without any problem, so there is something in particular about the combination of that file/server that is causing the problem. Thanks, Josh From owner-freebsd-stable@FreeBSD.ORG Sat Nov 6 09:37:01 2010 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 CE276106564A for ; Sat, 6 Nov 2010 09:37:01 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7CDF58FC21 for ; Sat, 6 Nov 2010 09:37:01 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id oA69b0tq027779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Nov 2010 10:37:00 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1289036220; bh=nE5G2A3QoqJsMz4kshpHc4PQhCdTcZnd+rO+NKUACl4=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=Lc/D8+Ys/AuWcvji2kJ/6T/QPLl9Qaq9ohWpTahR8xC8gGCnpYzlSa/t6Yf4KeZMX zA1RaqrRAF0ZOknQ5mihll/+vQJRpNJSqjHKDRTtSgwFE3PvKuzl0w6/ua8zlTZtiW w//yv2evqv0zk+eD5jU8e0BxO3/5VM9naXJKv3M0= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id oA69b0KI027778; Sat, 6 Nov 2010 10:37:00 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Sat, 6 Nov 2010 10:37:00 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Pyun YongHyeon Message-ID: <20101106093700.GW85693@acme.spoerlein.net> Mail-Followup-To: Pyun YongHyeon , stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org Subject: Abysmal re(4) performance under 8.1-STABLE (mid-August) 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, 06 Nov 2010 09:37:02 -0000 Hello Pyun, On this new server, I cannot get more than ~280kByte/s up/downstream out of re(4) without any tweaking. re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:21:85:63:74:34 inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.191 nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active re0@pci0:2:0:0: class=0x020000 card=0x368c1462 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff irq 19 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:21:85:63:74:34 re0: [FILTER] It's interesting to note, that re0 only negotiates half-duplex, where linux will negotiate full-duplex (and gets ~10MByte/s as expected). Next, I disabled almost all options, except that I cannot disable VLAN_MTU, VLAN_HWCSUM. I also forced the adapter into full-duplex. # ifconfig re0 -vlanmtu # ifconfig re0 -vlanhwcsum ifconfig: -vlanhwcsum: bad value # ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=88 ether 00:21:85:63:74:34 inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.191 nd6 options=3 media: Ethernet 100baseTX (100baseTX ) status: active If I then immediately start the test-download, I get a ~2MByte/s spike, which quickly returns to something around 250kByte/s. Booting with hw.pci.enable_msix=0 hw.pci.enable_msi=0 I can get almost up to 400kByte/s, but this may be coincidence. So this is usually as far as it gets: re0 in 190.504 KB/s 246.136 KB/s 66.709 MB out 10.290 KB/s 12.985 KB/s 6.076 MB But then I ran tcpdump in another session, and it looks like the ssh traffic on the upstream of the interface will make the downloads running in another window go faster: re0 in 805.961 KB/s 1.577 MB/s 116.523 MB out 222.940 KB/s 502.045 KB/s 19.267 MB Any ideas? Uli From owner-freebsd-stable@FreeBSD.ORG Sat Nov 6 10:50:25 2010 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 CA55B106564A; Sat, 6 Nov 2010 10:50:25 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DCB0F8FC15; Sat, 6 Nov 2010 10:50:24 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA27731; Sat, 06 Nov 2010 12:50:20 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PEgLk-000MNe-5c; Sat, 06 Nov 2010 12:50:20 +0200 Message-ID: <4CD532EB.1050008@freebsd.org> Date: Sat, 06 Nov 2010 12:50:19 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Kostik Belousov References: <1984713101.142889.1288963447940.JavaMail.root@erie.cs.uoguelph.ca> <20101105212757.GG2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101105212757.GG2392@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Josh Carroll , Rick Macklem , freebsd-stable@freebsd.org, jhb@freebsd.org Subject: Re: NFS deadlock (unkillable nfsd and no mounts work) 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, 06 Nov 2010 10:50:25 -0000 on 05/11/2010 23:27 Kostik Belousov said the following: > I agree that the fix a right fix for real issue. It should only > affect the filesystems that do support VFS_VGET(). In other words, > it is relevant for e.g. UFS exports, but not for ZFS, that is the > Andrey case. Actually ZFS does implement vfs_vget, but with a special quirk for .zfs/ and stuff under it: static int zfs_vget(vfs_t *vfsp, ino_t ino, int flags, vnode_t **vpp) { zfsvfs_t *zfsvfs = vfsp->vfs_data; znode_t *zp; int err; /* * zfs_zget() can't operate on virtual entires like .zfs/ or * .zfs/snapshot/ directories, that's why we return EOPNOTSUPP. * This will make NFS to switch to LOOKUP instead of using VGET. */ if (ino == ZFSCTL_INO_ROOT || ino == ZFSCTL_INO_SNAPDIR) return (EOPNOTSUPP); ... ... -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Nov 6 12:09:35 2010 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 EB2D3106564A for ; Sat, 6 Nov 2010 12:09:34 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5981B8FC14 for ; Sat, 6 Nov 2010 12:09:34 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id oA6C9Xe9003760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Nov 2010 13:09:33 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1289045373; bh=yFFUWLmMZC1+UHDR9o0xDNs5DR0YWxVTEibsuSTODT0=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=B3SjN5/JxeJmcY46I5TvzrHYp5PRdr40gVyfDRsl7TDt6dxRqpo2ixhl1qYBiiVsD z8lVeOhXXX+3Bw+AIF/SBYfAdL7l9ArSx0XdwoDg63Q59acReYiH1ChoLt6BzROToI kg9eE15ECRFAXSlNS7+fzTqH90WYraGJmq83ASyw= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id oA6C9XE6003759; Sat, 6 Nov 2010 13:09:33 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Sat, 6 Nov 2010 13:09:33 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Pyun YongHyeon , stable@freebsd.org Message-ID: <20101106120933.GX85693@acme.spoerlein.net> Mail-Followup-To: Pyun YongHyeon , stable@freebsd.org References: <20101106093700.GW85693@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101106093700.GW85693@acme.spoerlein.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Abysmal re(4) performance under 8.1-STABLE (mid-August) 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, 06 Nov 2010 12:09:35 -0000 On Sat, 06.11.2010 at 10:37:00 +0100, Ulrich Spörlein wrote: > Hello Pyun, > > On this new server, I cannot get more than ~280kByte/s up/downstream out of > re(4) without any tweaking. > > re0: flags=8843 metric 0 mtu 1500 > options=389b > ether 00:21:85:63:74:34 > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.191 > nd6 options=3 > media: Ethernet autoselect (100baseTX ) > status: active > > re0@pci0:2:0:0: class=0x020000 card=0x368c1462 chip=0x816810ec rev=0x01 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' > class = network > subclass = ethernet One more datapoint, I know that this (newer) revision re0@pci0:6:0:0: class=0x020000 card=0x75221462 chip=0x816810ec rev=0x02 hdr=0x00 is working just fine in another system/board. > re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff irq 19 at device 0.0 on pci2 > re0: Using 1 MSI messages > re0: Chip rev. 0x38000000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > re0: Ethernet address: 00:21:85:63:74:34 > re0: [FILTER] > > > It's interesting to note, that re0 only negotiates half-duplex, where > linux will negotiate full-duplex (and gets ~10MByte/s as expected). > > Next, I disabled almost all options, except that I cannot disable > VLAN_MTU, VLAN_HWCSUM. I also forced the adapter into full-duplex. > > # ifconfig re0 -vlanmtu > # ifconfig re0 -vlanhwcsum > ifconfig: -vlanhwcsum: bad value > # ifconfig re0 > re0: flags=8843 metric 0 mtu 1500 > options=88 > ether 00:21:85:63:74:34 > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1 > inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.191 > nd6 options=3 > media: Ethernet 100baseTX (100baseTX ) > status: active > > If I then immediately start the test-download, I get a ~2MByte/s spike, > which quickly returns to something around 250kByte/s. > > Booting with > hw.pci.enable_msix=0 > hw.pci.enable_msi=0 > > I can get almost up to 400kByte/s, but this may be coincidence. > > So this is usually as far as it gets: > > re0 in 190.504 KB/s 246.136 KB/s 66.709 MB > out 10.290 KB/s 12.985 KB/s 6.076 MB > > But then I ran tcpdump in another session, and it looks like the ssh traffic on > the upstream of the interface will make the downloads running in another window > go faster: > > re0 in 805.961 KB/s 1.577 MB/s 116.523 MB > out 222.940 KB/s 502.045 KB/s 19.267 MB > > Any ideas? > > Uli > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Nov 6 12:21:03 2010 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 ED36D106566B for ; Sat, 6 Nov 2010 12:21:03 +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 ACD498FC13 for ; Sat, 6 Nov 2010 12:21:03 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEALbe1EyDaFvO/2dsb2JhbACDMZ9IqyCQYIEigzNzBIpV X-IronPort-AV: E=Sophos;i="4.58,307,1286164800"; d="scan'208";a="98005232" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 06 Nov 2010 07:52:28 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 46AC1B3F54; Sat, 6 Nov 2010 07:52:28 -0400 (EDT) Date: Sat, 6 Nov 2010 07:52:28 -0400 (EDT) From: Rick Macklem To: =?utf-8?Q?Ulrich_Sp=C3=B6rlein?= Message-ID: <577449795.190094.1289044348243.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20101106093700.GW85693@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: Pyun YongHyeon , stable@freebsd.org Subject: Re: Abysmal re(4) performance under 8.1-STABLE (mid-August) 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, 06 Nov 2010 12:21:04 -0000 > Hello Pyun, > > On this new server, I cannot get more than ~280kByte/s up/downstream > I have been working on a similar problem with Pyun's help. Not yet resolved and no idea if it is the same problem, but see below... > > Any ideas? I have been chasing a similar problem w.r.t. re(4) { slow NFS reads on -current }. You could try building a kernel with "options DEVICE_POLLING" and see if that helps. If that makes it work faster, then it might be the same issue. rick From owner-freebsd-stable@FreeBSD.ORG Sat Nov 6 12:25:09 2010 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 9F0B2106566C for ; Sat, 6 Nov 2010 12:25:09 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 6450C8FC15 for ; Sat, 6 Nov 2010 12:25:09 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 72A6EAB7DD; Sat, 6 Nov 2010 13:25:06 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: <20101106093700.GW85693@acme.spoerlein.net> Date: Sat, 6 Nov 2010 13:25:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101106093700.GW85693@acme.spoerlein.net> To: Pyun YongHyeon X-Mailer: Apple Mail (2.1081) Cc: stable@freebsd.org, =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= Subject: Re: Abysmal re(4) performance under 8.1-STABLE (mid-August) 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, 06 Nov 2010 12:25:09 -0000 Am 06.11.2010 um 10:37 schrieb Ulrich Sp=F6rlein: > On this new server, I cannot get more than ~280kByte/s up/downstream = out of > re(4) without any tweaking. >=20 > re0: flags=3D8843 metric 0 mtu = 1500 > = options=3D389b > ether 00:21:85:63:74:34 > inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1=20 > inet 46.4.12.147 netmask 0xffffffc0 broadcast 46.4.12.191 > nd6 options=3D3 > media: Ethernet autoselect (100baseTX ) > status: active AOL: re0@pci0:1:0:0: class=3D0x020000 card=3D0x82c61043 chip=3D0x816810ec = rev=3D0x02 hdr=3D0x00 vendor =3D 'Realtek Semiconductor' device =3D 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class =3D network subclass =3D ethernet re0: port = 0xd800-0xd8ff mem 0xfdfff000-0xfdffffff,0xfdfe0000-0xfdfeffff irq 18 at = device 0.0 on pci1 re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-FDX, auto re0: Ethernet address: 00:26:18:d5:2c:23 re0: [FILTER] I believe that it was working properly some months ago, but reading = Rick's thread over on -current I checked and transfer over NFS seems to = be limited to a couple hundred KB as well. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Sat Nov 6 16:04:30 2010 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 13AE1106566B for ; Sat, 6 Nov 2010 16:04:30 +0000 (UTC) (envelope-from thomas.e.zander@googlemail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id B9DD48FC08 for ; Sat, 6 Nov 2010 16:04:29 +0000 (UTC) Received: by qyk7 with SMTP id 7so437197qyk.13 for ; Sat, 06 Nov 2010 09:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=6gfPEThRbXTVp4rWQQOj58ZfDep5AWRn9CJfrgSEvFw=; b=Ixgv4fIOdsjIFh/qzOiNEiPLzbCty6xgFD2Z+m/dXXVX/J6pvOp0OCVgHJQcmbZPqv T2ekCvPHz8z3rkXLUcjO6yG/ejtWNInNRq9oabUGdGpeWGSVlf6OTSd2vrpDozYij+h7 WeBnh4u+8+MsYWIWsXzevygANxwr2PE+cfC1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=YmTCcdqw9ixGOZuLgkKd7P3HCmFgyARFzRqam75dvDe2HdPNu0VQJXVg4ARbmJ4b5E 2PPlICigUvh3oWVpleQ8P8jQWMcGMcCqIRBOweIDOIBo2/Ds5F/WBvXg2duvtdq+JYVG 1LpBoZPX9SIUW346QcwSKtLgX5dj9JDqXc5zU= MIME-Version: 1.0 Received: by 10.229.220.144 with SMTP id hy16mr3160976qcb.259.1289059468396; Sat, 06 Nov 2010 09:04:28 -0700 (PDT) Received: by 10.229.249.135 with HTTP; Sat, 6 Nov 2010 09:04:28 -0700 (PDT) In-Reply-To: References: Date: Sat, 6 Nov 2010 17:04:28 +0100 Message-ID: From: Thomas Zander To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: How to tell whether ECC (memory) is enabled? 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, 06 Nov 2010 16:04:30 -0000 On Fri, Nov 5, 2010 at 20:54, C. P. Ghost wrote: > Have you tried 'dmidecode' (as run), from the port sysutils/dmidecode? I have actually, but the output is somewhat unexpected (besides the fact that there are cases in which its report do not match reality. The manpage says "often".). In my box in question for example, dmidecode reports about the memory controller: Error Detecting Method: 64-bit ECC Error Correcting Capabilities: None ... Supported Memory Types: Standard SDRAM Memory Module Voltage: 2.9 V Associated Memory Slots: 4 0x0006 0x0007 0x0008 0x0009 Enabled Error Correcting Capabilities: None That seems wrong in at least two positions: First, it clearly lacks "ECC" in the "Supported Memory Types" section, and for its voltage I was expecting 1.8 V, not 2.9 V. The output concerning the memory modules itself is also unexpected. Just to pick one: Socket Designation: A0 Bank Connections: 0 1 Current Speed: 5 ns Type: DIMM Installed Size: 2048 MB (Double-bank Connection) Enabled Size: 2048 MB (Double-bank Connection) Error Status: OK While it is correct about the size, I would expect "Type: ECC DIMM" here. Therefore, I don't tend to trust its output, and a kernel message stating "I am running on ECC memory" would be lovely :-) Riggs From owner-freebsd-stable@FreeBSD.ORG Sat Nov 6 16:09:40 2010 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 202DB106564A for ; Sat, 6 Nov 2010 16:09:40 +0000 (UTC) (envelope-from thomas.e.zander@googlemail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id C59DC8FC21 for ; Sat, 6 Nov 2010 16:09:39 +0000 (UTC) Received: by qyk7 with SMTP id 7so440527qyk.13 for ; Sat, 06 Nov 2010 09:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=1iZq5kC1oaqobm0eFPHjktfNXiH0HWsuf434EG8VRus=; b=v3UAOUk3NBt1cZx+pF0zcXK6CuOyI1PKiNPgIK1o578NO/cfTY98e+raLayI3CvkFg 2blAMlCbcVuVflVLaAbVNCpJICvmusRzv6avlfb6ZYh6azsh1SWhMSEEXawM2BkPw0q8 JGFk5XpdDQD0SNfgtSAN4DsSXEYWTGe6XnsY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Jgcfk5oCy1PiaMOw9CpAw97cW761h7R1ahGnRz1dt1Fp4zxLV8S74x4mPm9eV+0HJ3 pLoSlXouNT1+wV6qmzB0C+LqSkglk7SmU7xL+GAWUbgp9xYR/6+TYEoK4iUma5hZhmFS ndkvprfaQh6KsnKCKmX1A8EzAZDzA5q+r+eTE= MIME-Version: 1.0 Received: by 10.224.177.142 with SMTP id bi14mr2168317qab.256.1289059779053; Sat, 06 Nov 2010 09:09:39 -0700 (PDT) Received: by 10.229.249.135 with HTTP; Sat, 6 Nov 2010 09:09:39 -0700 (PDT) In-Reply-To: <201011051721.05898.jhb@freebsd.org> References: <201011051721.05898.jhb@freebsd.org> Date: Sat, 6 Nov 2010 17:09:39 +0100 Message-ID: From: Thomas Zander To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: How to tell whether ECC (memory) is enabled? 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, 06 Nov 2010 16:09:40 -0000 On Fri, Nov 5, 2010 at 22:21, John Baldwin wrote: >> During POST, die BIOS also tells me that ECC memory is installed, so >> far so good. But I was a little surprised that the FreeBSD kernel >> tells me absolutely nothing about it. Or do I have to tune loader.conf >> variables? > > I think the EDAC register is using the registers for the QPI PCI buses. > There is a driver now to export those PCI buses to the OS in 7.x+. =A0How= ever, > someone would need to port the EDAC driver (or something similar) to work > with those devices. I see. Thanks for clarification! This means for now I have to trust the BIOS that ECC is enabled and I should see MCA reports in the dmesg output once a bit error is detected? Riggs From owner-freebsd-stable@FreeBSD.ORG Sat Nov 6 17:56:54 2010 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 A040E1065694 for ; Sat, 6 Nov 2010 17:56:54 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4E8A08FC20 for ; Sat, 6 Nov 2010 17:56:54 +0000 (UTC) Received: by qwg8 with SMTP id 8so3469257qwg.13 for ; Sat, 06 Nov 2010 10:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=xxVw+EMGGUZZ7Se/qEbAsZJeRAXpj2AbE2ojCTII3uk=; b=eecZiBcCvPOPn0mDgmUfAnvHor9tr7X8uSKCZE/oLsiqSmgCmZfwg+u7+8ZfK3Qsp3 dFpITFoA/6QoHIjBiS3DtKQOkrBV6/2OS0Ma5M/lX9Lb0ByE0TfVBGO7KJKqCcptgUs4 apu4UpWZmIMmQsJP2GrmE1Swqqdc/DNhSBHAs= 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=J/eA+vgsoKyPg64efaODwbHnB9JLO+MPTxRiFZrXnG5ioB4ZHCjczaroeI9Togw0k5 j2wnYBc1x4pNER1sTS27LunJ4XWJYITx+yWp+2LpzCdT+1fzeSELzQG3MlIIUN1JehEJ 0+frOMghriKDWnNulJJuRGBhkgjg+qWjGXuVw= MIME-Version: 1.0 Received: by 10.224.128.210 with SMTP id l18mr2296566qas.24.1289066212801; Sat, 06 Nov 2010 10:56:52 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.180.2 with HTTP; Sat, 6 Nov 2010 10:56:52 -0700 (PDT) In-Reply-To: References: <201011051721.05898.jhb@freebsd.org> Date: Sat, 6 Nov 2010 10:56:52 -0700 X-Google-Sender-Auth: 7pRHgDKzesTLphzfv3r0JO9H2EM Message-ID: From: Artem Belevich To: Thomas Zander Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable Subject: Re: How to tell whether ECC (memory) is enabled? 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, 06 Nov 2010 17:56:54 -0000 On Sat, Nov 6, 2010 at 9:09 AM, Thomas Zander wrote: > This means for now I have to trust the BIOS that ECC is enabled and I > should see MCA reports in the dmesg output once a bit error is > detected? Well, you don't have to take BIOS' word for that and test whether ECC really works. All you need is intentionally make one data bit bad.Put some tape on one of the data pads on the DIMM and run memtest. That would conclusively prove whether the motherboard has ECC enabled. See here for more details: http://bluesmoke.sourceforge.net/testing.html --Artem From owner-freebsd-stable@FreeBSD.ORG Sat Nov 6 22:46:45 2010 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 AECBA106564A for ; Sat, 6 Nov 2010 22:46:45 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 6B3B78FC0A for ; Sat, 6 Nov 2010 22:46:45 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 2FAB71CC34 for ; Sat, 6 Nov 2010 18:46:44 -0400 (EDT) Message-ID: <4CD5DAD3.8020304@protected-networks.net> Date: Sat, 06 Nov 2010 18:46:43 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Thunderbird/3.1.6 MIME-Version: 1.0 To: stable@freebsd.org X-Enigmail-Version: 1.1.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: releng_7 buildworld 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: Sat, 06 Nov 2010 22:46:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SVN rev 214875 on 2010-11-06 13:03:33Z breaks buildworld on releng_7. It introduces "siis.4" to /usr/src/share/man/man4/Makefile which doesn't exist (yet?) imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzV2tMACgkQQv9rrgRC1JLgAQCeIOtFEwhHzxs4f2KCsLxg8cQh Aw4AoMEjWsu0Ls2Tto+sb8NzaYH1qfsX =X33+ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 6 22:54:38 2010 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 6B0FE1065674; Sat, 6 Nov 2010 22:54:38 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0C55E8FC1F; Sat, 6 Nov 2010 22:54:37 +0000 (UTC) Received: by qyk7 with SMTP id 7so3612644qyk.13 for ; Sat, 06 Nov 2010 15:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=13zhpnqtSS7Sz0heTARU5X4Ekr4IEhA6nt2inQy+I3Q=; b=i16a4aY2jWT4YnhtwuHn3n/k6osgHcvPZ2mHJ2mJwisw5p48b3tebzw2LVPft6RAMv E2NCWoUQinckXtU0anZBGOTf4Sbu6Qpmct7qYXJsUgL+kJ+9S88jLmfORfvCKqdrnL9F Ynq/Nm/AB0kDqaDesU244yLQ1iAxomWf8ZAXI= 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=kLkeWw5eDtbzvig4/HEL3Tmuv1/UPDeb22FjWzzgNWrkocAAKApd9fzy1G6Jm5FqvI K+X0ySFIz+inKVD4wLAy2Z21eMgkN2SJyrAggJamocMJlhLifmJ9PokooNuaYHfnM0tc Pm1xYgfhd+vdvVOx44cRHM46Z5egTgHjZBphU= MIME-Version: 1.0 Received: by 10.229.233.196 with SMTP id jz4mr3504824qcb.138.1289084077090; Sat, 06 Nov 2010 15:54:37 -0700 (PDT) Received: by 10.229.69.135 with HTTP; Sat, 6 Nov 2010 15:54:37 -0700 (PDT) In-Reply-To: <4CD5DAD3.8020304@protected-networks.net> References: <4CD5DAD3.8020304@protected-networks.net> Date: Sun, 7 Nov 2010 01:54:37 +0300 Message-ID: From: Sergey Kandaurov To: Michael Butler , Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org Subject: Re: releng_7 buildworld 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: Sat, 06 Nov 2010 22:54:38 -0000 On 7 November 2010 01:46, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > SVN rev 214875 on 2010-11-06 13:03:33Z breaks buildworld on releng_7. > > It introduces "siis.4" to /usr/src/share/man/man4/Makefile which doesn't > exist (yet?) I guess that's rather due to SIFTR mismerge. -- wbr, pluknet