From owner-freebsd-stable@FreeBSD.ORG Sun May 4 09:13:01 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 805751065671 for ; Sun, 4 May 2008 09:13:01 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from mail-out1.fuse.net (mail-out1.fuse.net [216.68.8.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5368FC1A for ; Sun, 4 May 2008 09:13:01 +0000 (UTC) (envelope-from jonathan@kc8onw.net) X-CNFS-Analysis: v=1.0 c=1 a=DTl47DImNrQA:15 a=tlCHpfXle7AA:10 a=R_1Sod5e6hMA:10 a=xUvkYoQocQKi/8Los98NoQ==:17 a=NUTUgPtKnhotR9SvR0QA:9 a=wRxoRSevKQFrvVnc1mueuLkJ1SAA:4 a=uZQnKKD9fRsA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Received: from [208.102.162.227] ([208.102.162.227:50973] helo=mail.kc8onw.net) by mail-out1.fuse.net (ecelerity 2.1.1.22 r(17669)) with ESMTP id AF/F4-13383-C1E7D184 for ; Sun, 04 May 2008 05:13:00 -0400 Received: from www.kc8onw.net (localhost [127.0.0.1]) by mail.kc8onw.net (Postfix) with ESMTP id 5156228415; Sun, 4 May 2008 05:13:00 -0400 (EDT) Received: from 80.91.220.50 (SquirrelMail authenticated user jonathan) by www.kc8onw.net with HTTP; Sun, 4 May 2008 05:13:00 -0400 (EDT) Message-ID: <52635.80.91.220.50.1209892380.squirrel@www.kc8onw.net> In-Reply-To: <2a41acea0805010954m3f6f4afdxd3a18a515e0a86e4@mail.gmail.com> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> <58402.80.91.220.50.1209660616.squirrel@www.kc8onw.net> <2a41acea0805010954m3f6f4afdxd3a18a515e0a86e4@mail.gmail.com> Date: Sun, 4 May 2008 05:13:00 -0400 (EDT) From: jonathan@kc8onw.net To: "Jack Vogel" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: em1: Unable to allocate bus resource: memory 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, 04 May 2008 09:13:01 -0000 [snip discussion] Sorry to all for the noise, turns out that with a motherboard BIOS update the card is recognized and initialized fine. For the archives the board was an Asus P5B-VM DO and had the 0505 BIOS. I updated to the 1001 version. Jonathan Stewart From owner-freebsd-stable@FreeBSD.ORG Sun May 4 18:42:15 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB4851065670 for ; Sun, 4 May 2008 18:42:15 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 9DC0D8FC17 for ; Sun, 4 May 2008 18:42:15 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so305339wah.3 for ; Sun, 04 May 2008 11:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=qN7cS9xp/wX7V4fcgIEPsHUXDY/9954maraawUS+wRo=; b=Un0niwHB5VonzPn9qupH7A1XqViRqI57dLCnz0p73oIvNNe2SKul9oocidEzYArTiFwj1ujIbGaSQ+bvn9DVp6G2ehPvzxpEhcwDpIgyEvi5gOPe6AjXIiCdjnUaRzE/W8cCkbp3SAStGLw1ycyEiw+Z+npo7QcFne8FoMPLy9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h0S77hWcuAe4p8boYXbgsu7ueUZvyV9xgwweUp76lUKfaO2iGq+bcKu+6y24eIjpTZQBS0+hH3crjUU6NDVjLjWTjA4VQ8bA8aaMsB9c1QjkPI14Ve3VbiWTksIyUaI5JHPGiR238DGB3gg5Zt+sIOQDhIhibJLdfJdkPwDn3hQ= Received: by 10.114.191.1 with SMTP id o1mr4949259waf.117.1209926535261; Sun, 04 May 2008 11:42:15 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Sun, 4 May 2008 11:42:15 -0700 (PDT) Message-ID: <2a41acea0805041142q286f605bm3bf2fac5065db246@mail.gmail.com> Date: Sun, 4 May 2008 11:42:15 -0700 From: "Jack Vogel" To: jonathan@kc8onw.net In-Reply-To: <52635.80.91.220.50.1209892380.squirrel@www.kc8onw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> <58402.80.91.220.50.1209660616.squirrel@www.kc8onw.net> <2a41acea0805010954m3f6f4afdxd3a18a515e0a86e4@mail.gmail.com> <52635.80.91.220.50.1209892380.squirrel@www.kc8onw.net> Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: em1: Unable to allocate bus resource: memory 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, 04 May 2008 18:42:15 -0000 On Sun, May 4, 2008 at 2:13 AM, wrote: > [snip discussion] > > Sorry to all for the noise, turns out that with a motherboard BIOS update > the card is recognized and initialized fine. > > For the archives the board was an Asus P5B-VM DO and had the 0505 BIOS. I > updated to the 1001 version. > > Jonathan Stewart Excellent, glad to hear that it now works, and thanks the most for getting back on this Jonathan, always good for future searching to have closure :) Jack From owner-freebsd-stable@FreeBSD.ORG Sun May 4 23:48:57 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 197561065675 for ; Sun, 4 May 2008 23:48:57 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing01.lava.net (cake.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b50]) by mx1.freebsd.org (Postfix) with ESMTP id C08AA8FC12 for ; Sun, 4 May 2008 23:48:56 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTP id 04B18D013B; Sun, 4 May 2008 13:48:56 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id 850C0153882; Sun, 4 May 2008 13:48:55 -1000 (HST) Date: Sun, 4 May 2008 13:48:55 -1000 From: Clifton Royston To: Stephen Clark Message-ID: <20080504234854.GB20269@lava.net> Mail-Followup-To: Stephen Clark , freebsd-stable@freebsd.org References: <4819BB3A.6000407@earthlink.net> <481A16E7.8040709@earthlink.net> <20080501210233.GA15528@lava.net> <481B19C4.1040806@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <481B19C4.1040806@earthlink.net> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: FreeBSD 6.2 kernel parameters (Was Re: reboot after panic) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2008 23:48:57 -0000 I got a couple requests for the tuning settings I've been using; it seems I'm not the only one who's had problems with FreeBSD 6.x stability as compared to 4.x. I don't understand the kernel well enough to say whether any of these are to any extent "right", but despite being pure voodoo, they seem to have helped substantially in performance and stability. I picked some of them off the discussion about tuning required to get ZFS running stably, ditto for discussion of ggatec/ggated. (The first 3 settings in sysctl - through kern.ipc.somaxconn - were carried over from my 4.x config.) Here's what I've got, and any solid recommendations from the kernel developers will I'm sure get close attention, and not only from me. I.e. if you can authoritatively tell me I'm an idiot, and some of these aren't really helping, or tell me what will, great. As I say, they seem to help. Ditto if someone can really say authoritatively whether 6.3 is in practice more stable and higher performance than 6.2; with all the discussed problems on list, and the discussions of known fixes not being committed, I have not felt confident about making such a move. /boot/loader.conf: kern.ipc.nmbclusters="32768" vm.kmem_size="512M" vm.kmem_size_max="512M" kern.maxvnodes="400000" /etc/sysctl.conf: # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # TUNING VALUES confirmed by Cal's mailserver testing kern.maxfiles=16384 kern.maxfilesperproc=16384 # Speculative: enlarge listen queue for large number of incoming TCP conns # Default listen queue size = 128, 1024 recommended for busy webservers kern.ipc.somaxconn=1024 # From FreeBSD mailing list, reported on improving stability with # ggatec/ggated. net.inet.tcp.sendspace=1048576 net.inet.tcp.recvspace=1048576 kern.ipc.maxsockbuf=2049152 # Disable hyperthreading "logical CPUs" machdep.hlt_logical_cpus=1 -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Mon May 5 08:31:07 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73E901065677 for ; Mon, 5 May 2008 08:31:07 +0000 (UTC) (envelope-from Ingeborg.Hellemo@cc.uit.no) Received: from mux1.uit.no (mux1.uit.no [129.242.4.252]) by mx1.freebsd.org (Postfix) with ESMTP id E4B608FC0A for ; Mon, 5 May 2008 08:31:06 +0000 (UTC) (envelope-from Ingeborg.Hellemo@cc.uit.no) Received: from flode.cc.uit.no (flode.cc.uit.no [129.242.6.250]) by mux1.uit.no (8.14.2/8.14.2/Mux) with ESMTP id m458V5j6087229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 May 2008 10:31:05 +0200 (CEST) Received: from barnetv.cc.uit.no (barnetv.cc.uit.no [129.242.6.226]) by flode.cc.uit.no (8.13.3/8.13.3) with ESMTP id m458VG6K032220 for ; Mon, 5 May 2008 10:31:16 +0200 (CEST) (envelope-from ingeborg@cc.uit.no) Received: from barnetv.cc.uit.no (localhost.cc.uit.no [127.0.0.1]) by barnetv.cc.uit.no (8.14.2/8.14.2) with ESMTP id m458V4cJ069367 for ; Mon, 5 May 2008 10:31:04 +0200 (CEST) (envelope-from ingeborg@barnetv.cc.uit.no) Message-Id: <200805050831.m458V4cJ069367@barnetv.cc.uit.no> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 05 May 2008 10:31:04 +0200 From: Ingeborg Hellemo X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.63 on 129.242.4.252 Subject: PCI serial card works on 6.2 but not on 6.3 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, 05 May 2008 08:31:07 -0000 We have upgraded a box from 6.2 to 6.3-RELEASE. Afterwards the box does not recognize its ST Lab I-160 serial card with Netmos 9845 Chipset. It worked flawlessly on 6.2 with puc(4) driver. >From dmesg: pci1: at device 8.0 (no driver attached) ~# pciconf -l -v | grep -B 4 UART none2@pci1:8:0: class=0x070002 card=0x00041000 chip=0x98459710 rev=0x01 hdr=0x00 vendor = 'MosChip Semiconductors (Was: Netmos Technology)' device = 'Nm9845 Parallel/Serial Port Adapter' class = simple comms subclass = UART Kernel-config includes device puc device sio ~# kldstat -v | grep puc 184 pccard/puc 185 pci/puc 186 cardbus/puc 196 puc/sio 354 puc/ppc Any ideas? --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg@cc.uit.no (Univ. of Tromsø, Norway) From owner-freebsd-stable@FreeBSD.ORG Mon May 5 08:54:53 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D49C1065670 for ; Mon, 5 May 2008 08:54:53 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id EEB518FC1E for ; Mon, 5 May 2008 08:54:52 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id BA4BF1CC033; Mon, 5 May 2008 01:54:52 -0700 (PDT) Date: Mon, 5 May 2008 01:54:52 -0700 From: Jeremy Chadwick To: Ingeborg Hellemo Message-ID: <20080505085452.GA48510@eos.sc1.parodius.com> References: <200805050831.m458V4cJ069367@barnetv.cc.uit.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200805050831.m458V4cJ069367@barnetv.cc.uit.no> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: PCI serial card works on 6.2 but not on 6.3 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, 05 May 2008 08:54:53 -0000 On Mon, May 05, 2008 at 10:31:04AM +0200, Ingeborg Hellemo wrote: > We have upgraded a box from 6.2 to 6.3-RELEASE. Afterwards the box does not > recognize its ST Lab I-160 serial card with Netmos 9845 Chipset. It worked > flawlessly on 6.2 with puc(4) driver. > > Any ideas? Try loading the uart(4) driver, which can also replace sio(4) if I remember correctly. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon May 5 09:01:28 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C905106566C; Mon, 5 May 2008 09:01:28 +0000 (UTC) (envelope-from Ingeborg.Hellemo@cc.uit.no) Received: from mux2.uit.no (mux2.uit.no [129.242.5.252]) by mx1.freebsd.org (Postfix) with ESMTP id 987CA8FC25; Mon, 5 May 2008 09:01:27 +0000 (UTC) (envelope-from Ingeborg.Hellemo@cc.uit.no) Received: from flode.cc.uit.no (flode.cc.uit.no [129.242.6.250]) by mux2.uit.no (8.14.2/8.14.2/Mux) with ESMTP id m4591PTP038377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 11:01:25 +0200 (CEST) Received: from barnetv.cc.uit.no (barnetv.cc.uit.no [129.242.6.226]) by flode.cc.uit.no (8.13.3/8.13.3) with ESMTP id m4591b1k033100; Mon, 5 May 2008 11:01:37 +0200 (CEST) (envelope-from ingeborg@cc.uit.no) Received: from barnetv.cc.uit.no (localhost.cc.uit.no [127.0.0.1]) by barnetv.cc.uit.no (8.14.2/8.14.2) with ESMTP id m4591Pgh070794; Mon, 5 May 2008 11:01:25 +0200 (CEST) (envelope-from ingeborg@barnetv.cc.uit.no) Message-Id: <200805050901.m4591Pgh070794@barnetv.cc.uit.no> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Jeremy Chadwick In-reply-to: Your message of "Mon, 05 May 2008 01:54:52 PDT." <20080505085452.GA48510@eos.sc1.parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 05 May 2008 11:01:25 +0200 From: Ingeborg Hellemo X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.63 on 129.242.5.252 Cc: freebsd-stable@freebsd.org Subject: Re: PCI serial card works on 6.2 but not on 6.3 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, 05 May 2008 09:01:28 -0000 koitsu@freebsd.org said: > Try loading the uart(4) driver, which can also replace sio(4) if I remember > correctly. With puc(4) and sio(4) you have to make sure that both are either compiled into the kernel or loaded as a module. Do you know if this applies to uart(4) as well? --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg@cc.uit.no (Univ. of Tromsø, Norway) From owner-freebsd-stable@FreeBSD.ORG Mon May 5 17:04:40 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD8F6106566B for ; Mon, 5 May 2008 17:04:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.190]) by mx1.freebsd.org (Postfix) with ESMTP id EAAAB8FC1A for ; Mon, 5 May 2008 17:04:39 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by mu-out-0910.google.com with SMTP id i2so1111544mue.3 for ; Mon, 05 May 2008 10:04:38 -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:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=7mt5EuIlRIPQcqCEo34n220DT53vXziywYcOKSigcLw=; b=fF1GM6vqAyJLDa/Wm4C1prhYHG5dI7bxCtFvtQg7Co5x5bfapDduoJBZOEHbWfza3fongYVtfJ0qys64JwuqkZdPERvuEjT0YY4k/QlqjSW4jde9h6rzmKG79QBh4QRN1iOcgMkejYus3qvDIUm0xcbPzDnnXMKMIW48g8pk+L8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=IeYFHDnkplaCj5grY9bQqJCts93CrFpBXih+3KWEJtZD7MAk1u4/IndOUKhn0anAdynpN1SPgp7CzBjVwdSEnMy2/438WCV154vgS2GPn8cIe+d6SFQuZ6Q7oXJGjW175tZmcSqya6OSmHHa9EskWueaXbZ0zOozXi8LGJx53i8= Received: by 10.86.97.7 with SMTP id u7mr10173454fgb.25.1210005535750; Mon, 05 May 2008 09:38:55 -0700 (PDT) Received: by 10.86.73.10 with HTTP; Mon, 5 May 2008 09:38:55 -0700 (PDT) Message-ID: <3bbf2fe10805050938u4c48acacj673f59b013fd9efc@mail.gmail.com> Date: Mon, 5 May 2008 18:38:55 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 01363645aa1ac8ab Subject: [HEADS UP] lockmgr needing of sys/lockmgr.h on thirdy part codes 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, 05 May 2008 17:04:40 -0000 Hello, after MFC'ed the usage of LOCK_FILE and LOCK_LINE for lockmgr(9), now thirdy part code needs to include sys/lock.h just priorior than sys/lockmgr. Even if the patch doesn't break ABI / KPI (so it doesn't need thirdy part KLD to be recompiled), it worths noting that the new code needs this extra-care in order to be fully compliant. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Mon May 5 19:17:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F41371065742; Mon, 5 May 2008 19:17:17 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.67]) by mx1.freebsd.org (Postfix) with ESMTP id DE6658FC18; Mon, 5 May 2008 19:17:17 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp002-s [10.150.69.65]) by smtpoutm.mac.com (Xserve/smtpout004/MantshX 4.0) with ESMTP id m45J4BgA012603; Mon, 5 May 2008 12:04:11 -0700 (PDT) Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp002/MantshX 4.0) with ESMTP id m45J47Lp013651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 May 2008 12:04:07 -0700 (PDT) Message-Id: <1794FA69-FF9D-4BEF-BC93-934F39498702@mac.com> From: Marcel Moolenaar To: Ingeborg Hellemo In-Reply-To: <200805050901.m4591Pgh070794@barnetv.cc.uit.no> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 5 May 2008 12:04:06 -0700 References: <200805050901.m4591Pgh070794@barnetv.cc.uit.no> X-Mailer: Apple Mail (2.919.2) Cc: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: PCI serial card works on 6.2 but not on 6.3 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, 05 May 2008 19:17:18 -0000 On May 5, 2008, at 2:01 AM, Ingeborg Hellemo wrote: > > koitsu@freebsd.org said: >> Try loading the uart(4) driver, which can also replace sio(4) if I >> remember >> correctly. > > With puc(4) and sio(4) you have to make sure that both are either > compiled > into the kernel or loaded as a module. Do you know if this applies > to uart(4) > as well? Yes. It's a problem/quirk of the kernel module infrastructure, not of drivers. Note that it's save to compile-in puc(4) but have sio(4) or uart(4) loaded as a module. Not the other way around... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-stable@FreeBSD.ORG Mon May 5 23:18:11 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5A5A1065685 for ; Mon, 5 May 2008 23:18:11 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cetus.palisadesys.com (cetus.palisadesys.com [205.237.115.21]) by mx1.freebsd.org (Postfix) with ESMTP id 57B158FC2C for ; Mon, 5 May 2008 23:18:11 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from magellan.palisadesys.com (serverwatch [172.16.1.98]) by cetus.palisadesys.com (8.14.1/8.14.1) with ESMTP id m45Md6vd022602 for ; Mon, 5 May 2008 17:39:06 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Received: from [127.0.0.1] (cetus.palisadesys.com [205.237.115.21]) (authenticated bits=0) by magellan.palisadesys.com (8.14.1/8.14.1) with ESMTP id m45Md3nE061266 for ; Mon, 5 May 2008 17:39:04 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Message-ID: <481F8C9B.1080508@palisadesys.com> Date: Mon, 05 May 2008 17:39:23 -0500 From: Guy Helmer User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (magellan.palisadesys.com [205.237.115.20]); Mon, 05 May 2008 17:39:04 -0500 (CDT) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-3.799, required 6, ALL_TRUSTED -1.80, BAYES_00 -2.60, J_CHICKENPOX_32 0.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Subject: Puzzling VM behavior in 6.3 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, 05 May 2008 23:18:11 -0000 I'm trying to track down a performance regression in a memory-hungry application that seems to be related to switching from FreeBSD 6 as of 2007-01-04 (6.2-ish) to a checkout as of 2007-10-04 (6.3-ish). With these two systems running identical software under load side-by-side on identical hardware, we've observed that the disk is busier on the 6.3 system under the same load, but there shouldn't be much file activity other than logging and the swap usage stays at 0. In trying to track this down, we've found the most significant differences are in statistics from parts of the VM system. A partial snapshot of "systat -vm" shows this: 6-STABLE 2007-10-04 sample Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 2174196 16428 2489520 29168 166416 count All 2340816 28304 6887896 45636 pages 6-STABLE 2007-01-04 sample Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 2092808 15184 2439012 25424 202272 count All 3949748 20856157408972 34392 pages We've also noticed large differences in some sysctl vm stats: 6-STABLE 2007-01-04 6-STABLE 2007-10-04 vm.stats.vm.v_forkpages: 660926510 1607169036 vm.stats.vm.v_pdpages: 608941 1793198 Does this information give anyone a clue as to where I should look next? Thanks for any help, Guy -- Guy Helmer, Ph.D. Chief System Architect Palisade Systems, Inc. From owner-freebsd-stable@FreeBSD.ORG Tue May 6 00:43:15 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 711B5106564A for ; Tue, 6 May 2008 00:43:15 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from scooby.simplesystems.org (scooby.simplesystems.org [65.66.246.67]) by mx1.freebsd.org (Postfix) with ESMTP id 40E7C8FC0A for ; Tue, 6 May 2008 00:43:14 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by scooby.simplesystems.org (8.12.10+Sun/8.12.10) with ESMTP id m460NgCI029430; Mon, 5 May 2008 19:23:42 -0500 (CDT) Date: Mon, 5 May 2008 19:23:42 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: stable@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: static vs shared vs modules 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, 06 May 2008 00:43:15 -0000 Mikhail Teterin requested that I forward this tidbit of info to the list. The GraphicsMagick build currently distributed with FreeBSD 7.0 uses shared libraries but not loadable modules. Some testing I did today shows that FreeBSD is much slower at starting GraphicsMagick as a large static executable (with shared lib dependencies) than it is for a shared library, which itself much slower than the case where parts of the needed code are loaded using modules. This may imply that FreeBSD is abnormally slow at initializing large applications (e.g. Solaris 10 does not exhibit this anomaly since timings vary only by a few percent). For the timings below, I execute the command using this simple shell script: #!/bin/bash i=1 count=1000 time while test $i -lt $count do eval "$@" let i=i+1 done Here is the original email content sent to Mikhail Teterin: I performed some timings for executing a minimal GraphicsMagick command 'gm convert -size 1x1 'xc:#F00' null:' 1000 times. This is under FreeBSD. Static build: real 0m39.558s user 0m24.825s sys 0m14.853s Shared build: real 0m27.828s user 0m18.367s sys 0m9.728s Modules build: real 0m11.041s user 0m4.785s sys 0m6.737s I find it interesting that FreeBSD is not very efficient at starting large (mostly) static programs. Solaris is a lot better at this. Probably much of the difference in performance has to do with how the run-time linker works, and the amount of initialized data which needs to be set. With the static build I can push the generated image size to to 500x500 without much impact on the total run time. The execution overhead is that great. These differences may seem small but if gm is invoked from a simple shell script, it can make the difference between processing 25 small images per second or 90 images per second. Also, the consumed user and system time is dramatically less. Bob ====================================== Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-stable@FreeBSD.ORG Tue May 6 10:25:02 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BC231065678 for ; Tue, 6 May 2008 10:25:02 +0000 (UTC) (envelope-from webmaster@kibab.com) Received: from smtp.spaceweb.ru (smtp.spaceweb.ru [77.222.41.7]) by mx1.freebsd.org (Postfix) with ESMTP id C69B08FC2D for ; Tue, 6 May 2008 10:25:01 +0000 (UTC) (envelope-from webmaster@kibab.com) Received: from [91.76.104.27] (helo=kibab-main.home) by smtp.spaceweb.ru with esmtpa (Exim 4.63) (envelope-from ) id 1JtKMX-00036h-9J for freebsd-stable@FreeBSD.org; Tue, 06 May 2008 14:25:33 +0400 Date: Tue, 6 May 2008 14:24:58 +0400 From: Ilya Bakulin To: freebsd-stable@FreeBSD.org Message-Id: <20080506142458.d7c02db1.webmaster@kibab.com> In-Reply-To: <1209417467.33102.10.camel@localhost> References: <1209417467.33102.10.camel@localhost> Organization: HT-Systems X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: MFC Candidate: convert ffs_softdep.c over to callout(9) 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, 06 May 2008 10:25:02 -0000 On Mon, 28 Apr 2008 17:17:47 -0400 Coleman Kane wrote: > Ilya, > > Yes just go ahead and apply the patch that was attached. Then rebuild > your kernel. Make sure that your softupdates are enabled on the UFS > partition(s). > > Then try hammering it with some sort of file test on that partition > (e.g. unpack a somewhat large source tarball and try building it). > > The kernel did build fine for me when I built it. Unfortunately, due to > my hardware, RELENG_7 doesn't "just work" for me from vanilla sources, > so I'd like to see some testers on better "supported" hardware. > > -- > Coleman Kane So, everything is working pretty good. Kernel build succeeded today on machine running patched version of ffs_softdep and GENERIC kernel. =================================================== kibab@media%uname -a FreeBSD media.home 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue May 6 10:56:39 MSD 2008 root@kibab-main.home:/usr/_OBJDIR/usr/src/sys/GENERIC i386 kibab@media%mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1d on /tmp (ufs, local, soft-updates) /dev/ad0s1f on /usr (ufs, NFS exported, local, soft-updates) /dev/ad0s1e on /var (ufs, local, soft-updates) =================================================== -- Ilya Bakulin From owner-freebsd-stable@FreeBSD.ORG Tue May 6 12:42:17 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40F44106566C for ; Tue, 6 May 2008 12:42:17 +0000 (UTC) (envelope-from freebsd@scottevil.com) Received: from gentoo.gawr.com (gtfo.freethescene.net [66.226.64.49]) by mx1.freebsd.org (Postfix) with ESMTP id 338D38FC23 for ; Tue, 6 May 2008 12:42:17 +0000 (UTC) (envelope-from freebsd@scottevil.com) Received: from [10.34.1.89] (unknown [64.126.14.3]) (Authenticated sender: freebsd@scottevil.com) by gentoo.gawr.com (Postfix) with ESMTP id 7107E264001; Tue, 6 May 2008 07:41:25 -0500 (CDT) Message-ID: <48204E4F.7010402@scottevil.com> Date: Tue, 06 May 2008 07:25:51 -0500 From: Scott Oertel User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: sclark46@earthlink.net References: <4819BB3A.6000407@earthlink.net> In-Reply-To: <4819BB3A.6000407@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: reboot after panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2008 12:42:17 -0000 Stephen Clark wrote: > Hello List > > How do I get my freebsd 6.1 box to automatically reboot after a panic? > > Thanks, > Steve According to the handbook this is the default behavior unless you have KBD option enabled in your kernel, in which case adding KDB_UNATTENDED would cause the machine not to break to the debugger and to reboot after a panic. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-options.html -Scott Oertel From owner-freebsd-stable@FreeBSD.ORG Tue May 6 12:59:38 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECE801065670 for ; Tue, 6 May 2008 12:59:38 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id E173E8FC1D for ; Tue, 6 May 2008 12:59:38 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id C90321CC05F; Tue, 6 May 2008 05:59:38 -0700 (PDT) Date: Tue, 6 May 2008 05:59:38 -0700 From: Jeremy Chadwick To: Stephen Clark Message-ID: <20080506125938.GA8831@eos.sc1.parodius.com> References: <4819BB3A.6000407@earthlink.net> <481A16E7.8040709@earthlink.net> <20080501210233.GA15528@lava.net> <481B19C4.1040806@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <481B19C4.1040806@earthlink.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: reboot after panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2008 12:59:39 -0000 On Fri, May 02, 2008 at 09:40:20AM -0400, Stephen Clark wrote: > Mine is a nvidia 6300 mb with a dual core amd processor. I am causing the panic > while trying to develope a DD for a EVDO usb modem - so it is not a great > problem - I was just surprised it wasn't rebooting. This is a 6.1 system. > > Yes it is sort of discouraging that it is hard to get answers when you > aren't running the latest and greatest kernel. In our case we have over 500 > units in > the field running a mix of 4.9 and 6.1 and it is not feasible to > continually upgrade them, especially since there is no documented way to > reliably upgrade > a remote installation. Does the system reboot OK if you issue the "reboot" command? If not, then the problem is likely with the reboot method being used (ACPI vs. non-ACPI) or ACPI tweakage prior to reboot, and not anything to do with panics. See the following two sysctls: hw.acpi.disable_on_reboot hw.acpi.handle_reboot -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue May 6 13:05:10 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E6F41065674; Tue, 6 May 2008 13:05:10 +0000 (UTC) (envelope-from Ingeborg.Hellemo@cc.uit.no) Received: from mux2.uit.no (mux2.uit.no [129.242.5.252]) by mx1.freebsd.org (Postfix) with ESMTP id E16EF8FC1C; Tue, 6 May 2008 13:05:09 +0000 (UTC) (envelope-from Ingeborg.Hellemo@cc.uit.no) Received: from flode.cc.uit.no (flode.cc.uit.no [129.242.6.250]) by mux2.uit.no (8.14.2/8.14.2/Mux) with ESMTP id m46D57Vw082212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 15:05:07 +0200 (CEST) Received: from barnetv.cc.uit.no (barnetv.cc.uit.no [129.242.6.226]) by flode.cc.uit.no (8.13.3/8.13.3) with ESMTP id m46D5Jb2071646; Tue, 6 May 2008 15:05:19 +0200 (CEST) (envelope-from ingeborg@cc.uit.no) Received: from barnetv.cc.uit.no (localhost.cc.uit.no [127.0.0.1]) by barnetv.cc.uit.no (8.14.2/8.14.2) with ESMTP id m46D57EF097186; Tue, 6 May 2008 15:05:07 +0200 (CEST) (envelope-from ingeborg@barnetv.cc.uit.no) Message-Id: <200805061305.m46D57EF097186@barnetv.cc.uit.no> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Jeremy Chadwick In-reply-to: Your message of "Mon, 05 May 2008 01:54:52 PDT." <20080505085452.GA48510@eos.sc1.parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Tue, 06 May 2008 15:05:07 +0200 From: Ingeborg Hellemo X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.63 on 129.242.5.252 Cc: freebsd-stable@freebsd.org Subject: Re: PCI serial card works on 6.2 but not on 6.3 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, 06 May 2008 13:05:10 -0000 koitsu@freebsd.org said: > Try loading the uart(4) driver, which can also replace sio(4) if I remember > correctly. I have now tried both loading the uart4) -driver and kompiled it into the kernel, but the card is still unrecognized: pci1: at device 8.0 (no driver attached) ~# pciconf -l -v | grep -B 4 UART none2@pci1:8:0: class=0x070002 card=0x00041000 chip=0x98459710 rev=0x01 hdr=0x00 vendor = 'MosChip Semiconductors (Was: Netmos Technology)' device = 'Nm9845 Parallel/Serial Port Adapter' class = simple comms subclass = UART --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg@cc.uit.no (Univ. of Tromsø, Norway) From owner-freebsd-stable@FreeBSD.ORG Tue May 6 13:48:01 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 525A2106567A for ; Tue, 6 May 2008 13:48:01 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by mx1.freebsd.org (Postfix) with ESMTP id 116148FC15 for ; Tue, 6 May 2008 13:48:01 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=I+wuzXZaIM5Kv3JqTpEvxDgMDEkwQ4k+kK3iR9wPqZ8KhorOUSqesDVYq6OjqfLZ; 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 [24.144.77.185] (helo=joker.seclark.com) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JtNWS-0004d4-8p; Tue, 06 May 2008 09:48:00 -0400 Message-ID: <4820618F.3070009@earthlink.net> Date: Tue, 06 May 2008 09:47:59 -0400 From: Stephen Clark User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Jeremy Chadwick References: <4819BB3A.6000407@earthlink.net> <481A16E7.8040709@earthlink.net> <20080501210233.GA15528@lava.net> <481B19C4.1040806@earthlink.net> <20080506125938.GA8831@eos.sc1.parodius.com> In-Reply-To: <20080506125938.GA8831@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec790900fecb0c511ab8ade238b7f33bfcf6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.144.77.185 Cc: freebsd-stable@freebsd.org Subject: Re: reboot after panic 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, 06 May 2008 13:48:01 -0000 Jeremy Chadwick wrote: > On Fri, May 02, 2008 at 09:40:20AM -0400, Stephen Clark wrote: >> Mine is a nvidia 6300 mb with a dual core amd processor. I am causing the panic >> while trying to develope a DD for a EVDO usb modem - so it is not a great >> problem - I was just surprised it wasn't rebooting. This is a 6.1 system. >> >> Yes it is sort of discouraging that it is hard to get answers when you >> aren't running the latest and greatest kernel. In our case we have over 500 >> units in >> the field running a mix of 4.9 and 6.1 and it is not feasible to >> continually upgrade them, especially since there is no documented way to >> reliably upgrade >> a remote installation. > > Does the system reboot OK if you issue the "reboot" command? > > If not, then the problem is likely with the reboot method being used > (ACPI vs. non-ACPI) or ACPI tweakage prior to reboot, and not anything > to do with panics. See the following two sysctls: > > hw.acpi.disable_on_reboot > hw.acpi.handle_reboot > It reboots fine when I "shutdown -r now". It is only after a panic that it hangs. I have it set to save the crash dump: dumpdev="AUTO" # Device to crashdump to (device name, AUTO, or NO). dumpdir="/var/crash" # Directory where crash dumps are to be stored but there is never one. It is like it hangs trying to dump the memory image. This mother board has both sata and pata controllers but I am using only pata drives. dmesg from boot. Copyright (c) 1992-2006 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 6.1-STABLE #36: Fri May 2 09:02:26 EDT 2008 root@J301002.nwv01.com:/mnt/src/sys/i386/compile/WOLFPAC6SMP ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2410.99-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 Cores per package: 2 real memory = 938409984 (894 MB) avail memory = 908926976 (866 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: reservation of 1bf00000, 100000 (3) failed acpi0: reservation of 2bf00000, 100000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 pcib3: at device 4.0 on pci0 pci3: on pcib3 pci0: at device 5.0 (no driver attached) pci0: at device 9.0 (no driver attached) isab0: at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) pci0: at device 10.2 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 11.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 usbd_get_string: getting lang failed, using 0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 8 ports with 8 removable, self powered ehci0: mem 0xfe02e000-0xfe02e0ff at device 11.1 on pci0 ehci0: [GIANT-LOCKED] usb1: waiting for BIOS to give up control usb1: timed out waiting for BIOS usb1: EHCI version 1.0 usb1: companion controller, 8 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 8 ports with 8 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf400 -0xf40f at device 13.0 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70- 0xb73,0xe000-0xe00f mem 0xfe02d000-0xfe02dfff irq 22 at device 14.0 on pci0 ata2: on atapci1 ata3: on atapci1 pcib4: at device 16.0 on pci0 pci4: on pcib4 rl0: port 0xac00-0xacff mem 0xfdaff000-0xfdaff0ff irq 18 at device 6. 0 on pci4 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:50:fc:fb:1e:82 rl1: port 0xa800-0xa8ff mem 0xfdafe000-0xfdafe0ff irq 16 at device 8. 0 on pci4 miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:50:fc:f9:60:24 nve0: port 0xdc00-0xdc07 mem 0xfe02c000-0xfe02cfff irq 2 3 at device 20.0 on pci0 nve0: Ethernet address 00:e0:4c:ea:6b:6d miibus2: on nve0 rlphy2: on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nve0: Ethernet address: 00:e0:4c:ea:6b:6d acpi_tz0: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 4.000 msec Fast IPsec: Initialized Security Association Processing. IP Filter: v4.1.28np1 initialized. Default = pass all, Logging = enabled ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to accept, lo gging unlimited ad0: 38166MB at ata0-master UDMA100 ad2: 38166MB at ata1-master UDMA100 SMP: AP CPU #1 Launched! -- "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 May 6 13:56:42 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65FF31065670 for ; Tue, 6 May 2008 13:56:42 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 599128FC1B for ; Tue, 6 May 2008 13:56:42 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 179221CC05B; Tue, 6 May 2008 06:56:42 -0700 (PDT) Date: Tue, 6 May 2008 06:56:42 -0700 From: Jeremy Chadwick To: Stephen Clark Message-ID: <20080506135642.GA10543@eos.sc1.parodius.com> References: <4819BB3A.6000407@earthlink.net> <481A16E7.8040709@earthlink.net> <20080501210233.GA15528@lava.net> <481B19C4.1040806@earthlink.net> <20080506125938.GA8831@eos.sc1.parodius.com> <4820618F.3070009@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4820618F.3070009@earthlink.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: reboot after panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2008 13:56:42 -0000 On Tue, May 06, 2008 at 09:47:59AM -0400, Stephen Clark wrote: > Jeremy Chadwick wrote: >> On Fri, May 02, 2008 at 09:40:20AM -0400, Stephen Clark wrote: >>> Mine is a nvidia 6300 mb with a dual core amd processor. I am causing the panic >>> while trying to develope a DD for a EVDO usb modem - so it is not a great >>> problem - I was just surprised it wasn't rebooting. This is a 6.1 system. >>> >>> Yes it is sort of discouraging that it is hard to get answers when you >>> aren't running the latest and greatest kernel. In our case we have over >>> 500 units in >>> the field running a mix of 4.9 and 6.1 and it is not feasible to >>> continually upgrade them, especially since there is no documented way to >>> reliably upgrade >>> a remote installation. >> >> Does the system reboot OK if you issue the "reboot" command? >> >> If not, then the problem is likely with the reboot method being used >> (ACPI vs. non-ACPI) or ACPI tweakage prior to reboot, and not anything >> to do with panics. See the following two sysctls: >> >> hw.acpi.disable_on_reboot >> hw.acpi.handle_reboot > > It reboots fine when I "shutdown -r now". It is only after a panic > that it hangs. I have it set to save the crash dump: > dumpdev="AUTO" # Device to crashdump to (device name, AUTO, or NO). > dumpdir="/var/crash" # Directory where crash dumps are to be stored > > but there is never one. It is like it hangs trying to dump the memory image. > > This mother board has both sata and pata controllers but I am using only pata > drives. A kernel panic causes the kernel to dump all memory contents (from start to end) to whatever swap device is available. It's written to the disk in a fairly "raw" format, with some header data of some sort I think. After it's done, the system should reboot. My guess is that you either don't have any swap defined, swap is defined incorrectly (disklabel -r output would be useful), or your swap space is smaller than your total amount of memory. (Swap should usually be 2x RAM). dumpdir and dumpdev are used during the startup process, where savecore(8) is called. The memory dump on the swap device is extracted and stored in a file in $dumpdir, which you can examine later. Keep in mind that savecore(8) will use /dev/dumpdev, which is a symlink to whatever device your swap lives on -- and that's determined by reading /etc/fstab. Does this help? :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue May 6 14:10:34 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61798106566B; Tue, 6 May 2008 14:10:34 +0000 (UTC) (envelope-from bsam@kfs.ru) Received: from kfs.ru (kfs.kfs.ru [62.183.117.194]) by mx1.freebsd.org (Postfix) with ESMTP id 103D08FC17; Tue, 6 May 2008 14:10:34 +0000 (UTC) (envelope-from bsam@kfs.ru) Received: from bsam by kfs.ru with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1JtNYl-0005qF-R3; Tue, 06 May 2008 17:50:23 +0400 To: Ingeborg Hellemo References: <200805061305.m46D57EF097186@barnetv.cc.uit.no> From: Boris Samorodov Date: Tue, 06 May 2008 17:50:23 +0400 In-Reply-To: <200805061305.m46D57EF097186@barnetv.cc.uit.no> (Ingeborg Hellemo's message of "Tue, 06 May 2008 15:05:07 +0200") Message-ID: <29591840@serv3.int.kfs.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: "Boris B. Samorodov" Cc: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: PCI serial card works on 6.2 but not on 6.3 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, 06 May 2008 14:10:34 -0000 On Tue, 06 May 2008 15:05:07 +0200 Ingeborg Hellemo wrote: > koitsu@freebsd.org said: > > Try loading the uart(4) driver, which can also replace sio(4) if I remember > > correctly. > I have now tried both loading the uart4) -driver and kompiled it into the > kernel, but the card is still unrecognized: > pci1: at device 8.0 (no driver attached) > ~# pciconf -l -v | grep -B 4 UART > none2@pci1:8:0: class=0x070002 card=0x00041000 chip=0x98459710 rev=0x01 > hdr=0x00 > vendor = 'MosChip Semiconductors (Was: Netmos Technology)' > device = 'Nm9845 Parallel/Serial Port Adapter' > class = simple comms > subclass = UART You may be interested in kern/58953 (the last followup with the patch): http://www.freebsd.org/cgi/query-pr.cgi?pr=58953 WBR -- A: Because it messes up 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 in e-mail? From owner-freebsd-stable@FreeBSD.ORG Tue May 6 15:49:42 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0D831065676; Tue, 6 May 2008 15:49:42 +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 5DCE68FC1A; Tue, 6 May 2008 15:49:42 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=PdC07lvBs87V/wZrdE4Dc6b3NckaKRMOuT1Z2MBdYRks6YwAWspZfLc/iJ9Daq2e; 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 [24.144.77.185] (helo=joker.seclark.com) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JtPQB-0000M6-KT; Tue, 06 May 2008 11:49:39 -0400 Message-ID: <48207E12.9010009@earthlink.net> Date: Tue, 06 May 2008 11:49:38 -0400 From: Stephen Clark User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Jeremy Chadwick References: <4819BB3A.6000407@earthlink.net> <481A16E7.8040709@earthlink.net> <20080501210233.GA15528@lava.net> <481B19C4.1040806@earthlink.net> <20080506125938.GA8831@eos.sc1.parodius.com> <4820618F.3070009@earthlink.net> <20080506135642.GA10543@eos.sc1.parodius.com> In-Reply-To: <20080506135642.GA10543@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec790d2962a7e92a909adba962b051a83257350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.144.77.185 Cc: freebsd-stable@freebsd.org Subject: Re: reboot after panic 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, 06 May 2008 15:49:42 -0000 Jeremy Chadwick wrote: > On Tue, May 06, 2008 at 09:47:59AM -0400, Stephen Clark wrote: >> Jeremy Chadwick wrote: >>> On Fri, May 02, 2008 at 09:40:20AM -0400, Stephen Clark wrote: >>>> Mine is a nvidia 6300 mb with a dual core amd processor. I am causing the panic >>>> while trying to develope a DD for a EVDO usb modem - so it is not a great >>>> problem - I was just surprised it wasn't rebooting. This is a 6.1 system. >>>> >>>> Yes it is sort of discouraging that it is hard to get answers when you >>>> aren't running the latest and greatest kernel. In our case we have over >>>> 500 units in >>>> the field running a mix of 4.9 and 6.1 and it is not feasible to >>>> continually upgrade them, especially since there is no documented way to >>>> reliably upgrade >>>> a remote installation. >>> Does the system reboot OK if you issue the "reboot" command? >>> >>> If not, then the problem is likely with the reboot method being used >>> (ACPI vs. non-ACPI) or ACPI tweakage prior to reboot, and not anything >>> to do with panics. See the following two sysctls: >>> >>> hw.acpi.disable_on_reboot >>> hw.acpi.handle_reboot >> It reboots fine when I "shutdown -r now". It is only after a panic >> that it hangs. I have it set to save the crash dump: >> dumpdev="AUTO" # Device to crashdump to (device name, AUTO, or NO). >> dumpdir="/var/crash" # Directory where crash dumps are to be stored >> >> but there is never one. It is like it hangs trying to dump the memory image. >> >> This mother board has both sata and pata controllers but I am using only pata >> drives. > > A kernel panic causes the kernel to dump all memory contents (from start > to end) to whatever swap device is available. It's written to the disk > in a fairly "raw" format, with some header data of some sort I think. > After it's done, the system should reboot. > > My guess is that you either don't have any swap defined, swap is defined > incorrectly (disklabel -r output would be useful), or your swap space is > smaller than your total amount of memory. (Swap should usually be 2x > RAM). > > dumpdir and dumpdev are used during the startup process, where > savecore(8) is called. The memory dump on the swap device is extracted > and stored in a file in $dumpdir, which you can examine later. Keep in > mind that savecore(8) will use /dev/dumpdev, which is a symlink to > whatever device your swap lives on -- and that's determined by reading > /etc/fstab. > > Does this help? :-) > Hi Jeremy, Thanks for the response but I think I have everything set up OK. from top: Mem: 33M Active, 19M Inact, 56M Wired, 54M Buf, 762M Free Swap: 2048M Total, 2048M Free $ sudo disklabel /dev/ad0s1 # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 204800 0 4.2BSD 1024 8192 23 b: 4194304 204800 swap c: 78156162 0 unused 0 0 # "raw" part, don't edit d: 45879682 4399104 4.2BSD 2048 16384 89 e: 409600 50278786 4.2BSD 2048 16384 97 f: 2097152 50688386 4.2BSD 2048 16384 89 g: 12685312 52785538 4.2BSD 2048 16384 89 h: 12685312 65470850 4.2BSD 2048 16384 89 J301002:~ 1 gig of memory $ sysctl -a |grep physmem hw.physmem: 929439744 $ ls -al /dev/dumpdev lrwxr-xr-x 1 root wheel 11 May 6 05:39 /dev/dumpdev -> /dev/ad0s1b $ less /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b none swap sw 0 0 Any other ideas? Regards, 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 May 6 16:54:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5619F106566B; Tue, 6 May 2008 16:54:02 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.65]) by mx1.freebsd.org (Postfix) with ESMTP id 3EC038FC29; Tue, 6 May 2008 16:54:02 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp010-s [10.150.69.73]) by smtpoutm.mac.com (Xserve/smtpout002/MantshX 4.0) with ESMTP id m46Grtwi008823; Tue, 6 May 2008 09:53:55 -0700 (PDT) Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp010/MantshX 4.0) with ESMTP id m46GrlYc025217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 May 2008 09:53:48 -0700 (PDT) Message-Id: <770A639E-DDE0-4464-B8A3-1D63EBFA6B65@mac.com> From: Marcel Moolenaar To: Ingeborg Hellemo In-Reply-To: <200805061305.m46D57EF097186@barnetv.cc.uit.no> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 6 May 2008 09:53:42 -0700 References: <200805061305.m46D57EF097186@barnetv.cc.uit.no> X-Mailer: Apple Mail (2.919.2) Cc: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: PCI serial card works on 6.2 but not on 6.3 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, 06 May 2008 16:54:02 -0000 On May 6, 2008, at 6:05 AM, Ingeborg Hellemo wrote: > > koitsu@freebsd.org said: >> Try loading the uart(4) driver, which can also replace sio(4) if I >> remember >> correctly. > > I have now tried both loading the uart4) -driver and kompiled it > into the > kernel, but the card is still unrecognized: > > pci1: at device 8.0 (no driver attached) > > ~# pciconf -l -v | grep -B 4 UART > none2@pci1:8:0: class=0x070002 card=0x00041000 chip=0x98459710 > rev=0x01 > hdr=0x00 > vendor = 'MosChip Semiconductors (Was: Netmos Technology)' > device = 'Nm9845 Parallel/Serial Port Adapter' > class = simple comms > subclass = UART The problem seems to be puc(4). This appears to be a multi-port card, which means puc(4) needs to attach. This is not happening. The problem seems to be revision 1.51.2.3 of src/sys/dev/puc/pucdata.c Could you try the following patch? Index: pucdata.c =================================================================== RCS file: /volume/apg-bbuild09-b/marcelm/ncvs/src/sys/dev/puc/ pucdata.c,v retrieving revision 1.51.2.3 diff -u -r1.51.2.3 pucdata.c --- pucdata.c 15 Dec 2006 22:31:37 -0000 1.51.2.3 +++ pucdata.c 6 May 2008 16:51:02 -0000 @@ -946,7 +946,7 @@ /* NetMos 4S0P PCI: 4S, 0P */ { "NetMos NM9845 Quad UART", - { 0x9710, 0x9845, 0, 0x0014 }, + { 0x9710, 0x9845, 0, 0x0004 }, { 0xffff, 0xffff, 0, 0xffff }, { { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ }, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-stable@FreeBSD.ORG Tue May 6 17:18:31 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAFA51065673; Tue, 6 May 2008 17:18:31 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing02.lava.net (pie.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b8c]) by mx1.freebsd.org (Postfix) with ESMTP id 6228F8FC16; Tue, 6 May 2008 17:18:31 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing02.lava.net (Postfix) with ESMTP id 99042170BD3; Tue, 6 May 2008 07:18:30 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id 3EE2E153882; Tue, 6 May 2008 07:18:30 -1000 (HST) Date: Tue, 6 May 2008 07:18:30 -1000 From: Clifton Royston To: Jeremy Chadwick Message-ID: <20080506171829.GA6784@lava.net> Mail-Followup-To: Jeremy Chadwick , Stephen Clark , freebsd-stable@freebsd.org References: <4819BB3A.6000407@earthlink.net> <481A16E7.8040709@earthlink.net> <20080501210233.GA15528@lava.net> <481B19C4.1040806@earthlink.net> <20080506125938.GA8831@eos.sc1.parodius.com> <4820618F.3070009@earthlink.net> <20080506135642.GA10543@eos.sc1.parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080506135642.GA10543@eos.sc1.parodius.com> User-Agent: Mutt/1.4.2.2i Cc: Stephen Clark , freebsd-stable@freebsd.org Subject: Re: reboot after panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2008 17:18:31 -0000 On Tue, May 06, 2008 at 06:56:42AM -0700, Jeremy Chadwick wrote: > On Tue, May 06, 2008 at 09:47:59AM -0400, Stephen Clark wrote: ... > > but there is never one. It is like it hangs trying to dump the memory image. > > > > This mother board has both sata and pata controllers but I am using only pata > > drives. > > A kernel panic causes the kernel to dump all memory contents (from start > to end) to whatever swap device is available. It's written to the disk > in a fairly "raw" format, with some header data of some sort I think. > After it's done, the system should reboot. > > My guess is that you either don't have any swap defined, swap is defined > incorrectly (disklabel -r output would be useful), or your swap space is > smaller than your total amount of memory. (Swap should usually be 2x > RAM). > > dumpdir and dumpdev are used during the startup process, where > savecore(8) is called. The memory dump on the swap device is extracted > and stored in a file in $dumpdir, which you can examine later. Keep in > mind that savecore(8) will use /dev/dumpdev, which is a symlink to > whatever device your swap lives on -- and that's determined by reading > /etc/fstab. > > Does this help? :-) You might consider the possibility that he is correct in what he has said, rather precisely, is going on. FreeBSD 6.2 (and apparently 6.1) can indeed double-fault or hang during the panic dump in which case no reboot occurs and there is nothing successfully dumped to analyze for debugging, either. It is likely that it only occurs with certain hardware conditions or configurations, which is why not everyone would see it, but that's not the same thing as it being a hardware problem. I've been seeing this on all of my SMP machines since October, and have reported it onlist, and I've been successfully running FreeBSD for nearly 10 years (starting with 3.3) and BSD/OS for years before that. It ain't necessarily PEBKAC. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Wed May 7 08:10:25 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C24A1065670 for ; Wed, 7 May 2008 08:10:25 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (ei.bzerk.org [82.95.223.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6E5BB8FC1D for ; Wed, 7 May 2008 08:10:24 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.13.8) with ESMTP id m477cfZx001901 for ; Wed, 7 May 2008 09:38:41 +0200 (CEST) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.13.8/Submit) id m477ceFu001900 for stable@freebsd.org; Wed, 7 May 2008 09:38:40 +0200 (CEST) (envelope-from mail25@bzerk.org) Date: Wed, 7 May 2008 09:38:40 +0200 From: Ruben de Groot To: stable@freebsd.org Message-ID: <20080507073840.GA1824@ei.bzerk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (ei.bzerk.org [127.0.0.1]); Wed, 07 May 2008 09:38:43 +0200 (CEST) Cc: Subject: Panics in kern_timeout.c (7-STABLE) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2008 08:10:25 -0000 Hi, I've experienced 2 panics in the last couple of days after upgrading to 7-stable sources of about 2 weeks ago: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x9608 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05f095f stack pointer = 0x28:0xd4ceec80 frame pointer = 0x28:0xd4ceecbc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 13 (swi4: clock sio) trap number = 12 panic: page fault cpuid = 0 Uptime: 3d6h24m45s Physical memory: 503 MB Dumping 96 MB: 81 65 49 33 17 1 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) list *0xc05f095f 0xc05f095f is in softclock (/usr/src/sys/kern/kern_timeout.c:203). 198 curticks = softticks; 199 bucket = &callwheel[curticks & callwheelmask]; 200 c = TAILQ_FIRST(bucket); 201 while (c) { 202 depth++; 203 if (c->c_time != curticks) { 204 c = TAILQ_NEXT(c, c_links.tqe); 205 ++steps; 206 if (steps >= MAX_SOFTCLOCK_STEPS) { 207 nextsoftcheck = c; The backtrace doesn't look very informative to me, but I'll include it here for completeness: (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc05de987 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc05dec49 in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc08961cc in trap_fatal (frame=0xd4ceec40, eva=38408) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0896b4f in trap (frame=0xd4ceec40) at /usr/src/sys/i386/i386/trap.c:280 #5 0xc087cb8b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc05f095f in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:202 #7 0xc05bf55b in ithread_loop (arg=0xc2997280) at /usr/src/sys/kern/kern_intr.c:1036 #8 0xc05bc339 in fork_exit (callout=0xc05bf3b0 , arg=0xc2997280, frame=0xd4ceed38) at /usr/src/sys/kern/kern_fork.c:783 #9 0xc087cc00 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 Can anyone offer a hand in how to debug this further? cheers, Ruben From owner-freebsd-stable@FreeBSD.ORG Wed May 7 16:01:09 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A9001065673 for ; Wed, 7 May 2008 16:01:09 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2818FC12 for ; Wed, 7 May 2008 16:01:08 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jtm4n-0003zQ-U1 for freebsd-stable@freebsd.org; Wed, 07 May 2008 16:01:05 +0000 Received: from 92.50.96.215 ([92.50.96.215]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 May 2008 16:01:05 +0000 Received: from saper by 92.50.96.215 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 May 2008 16:01:05 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Marcin Cieslak Date: Wed, 07 May 2008 18:00:41 +0200 Lines: 106 Message-ID: <4821D229.1000300@system.pl> References: <481B4D08.7030507@moneybookers.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig5B28127641B3F429FCB3F5A4" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 92.50.96.215 User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.13) Gecko/20080405 SeaMonkey/1.1.9 Mnenhy/0.7.5.0 In-Reply-To: <481B4D08.7030507@moneybookers.com> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: mpd5.1 and HUAWEI 3g card (ubsa) 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, 07 May 2008 16:01:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5B28127641B3F429FCB3F5A4 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable Stefan Lambrev wrote: > client1: > create bundle template B1 >=20 > create link static L1 modem > set modem device /dev/cuaU0 > set modem speed 115200 > set modem script DialPeer > set modem idle-script AnswerCall > set modem var $DialPrefix "DT" > set modem var $Telephone "*99***1#" > set link no pap chap eap > set link accept pap > set auth authname "MyLogin" > set auth password "MyPassword" > set link max-redial 1 > set link action bundle B1 > open Here's my config for another GPRS/UMTS provider: startup: default: eranet: log ipcp ipcp2 create bundle static B1 set iface route default set ipcp ranges 0.0.0.0/0 10.6.6.6/0 set ipcp disable req-pri-dns req-sec-dns < you probably=20 don'want this set ipcp disable req-pri-nbns req-sec-nbns < you probably=20 don'want this create link static L1 modem set modem device /dev/cuaU0 set modem speed 921600 set modem script GprsDial set modem watch -cd < ignore CD set link disable chap pap set link accept chap pap set link action bundle B1 set auth authname erainternet open My modem script: GprsDial: set $dialResult "FAIL" set $ConnectionSpeed "" if $ConnectTimeout =3D=3D "" set $ConnectTimeout 45 print "AT+CGDCONT=3D1,\"ip\",\"erainternet\"\r\n" << provider=20 specific match "ERR" DialErrorInit wait 5 print "AT+CGATT=3D1\r\n" match "ERR" DialErrorInit wait 5 print "ATDT*99#\r\n" match "NO CARRIER" DialAbortNoCar match "NO DIAL" DialAbortNoDial match "BUSY" DialAbortBusy regex "CONNECT *([0-9]*).*$" DialConnect match "ERR" DialErrorInit wait $ConnectTimeout log "No response from the modem after dialing." failure > Another issues is that after the first attempt to dial the modem freeze= s=20 > for few seconds and I see lot of those messages: > May 2 20:04:10 laptop kernel: ubsa_cfg_request: device request failed,= =20 > err=3DUSBD_ERR_STALLED (ignored) > but this should go to -usb probably :) This may be related to the driver. I am using stock ubsa (with patches=20 for Option GTMAX) without problems. One thing that may make things easier, can you change "link enable pap" to "link enable pap chap" ? --Marcin --------------enig5B28127641B3F429FCB3F5A4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQCVAwUBSCHSLD2W2v2wY27ZAQPJlgQAl8xk9JDifXH50KkhSWBOcTqvZlWhbv+b GXboxE5aFsNSdBWNvsPX9OIVGpW6ir0oQp39fMexnt2IzxEFzsGts8uDT914ioNh wQI+Jgd3CxGiBdVhbxFTogLwsLV5SWnaf/WTXdVnOhqzzMjEDJrua7EzfCwEaBS8 zsSJaiW88WY= =tWhG -----END PGP SIGNATURE----- --------------enig5B28127641B3F429FCB3F5A4-- From owner-freebsd-stable@FreeBSD.ORG Wed May 7 17:19:35 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58533106566B for ; Wed, 7 May 2008 17:19:35 +0000 (UTC) (envelope-from yani@pi-greece.eu) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.freebsd.org (Postfix) with ESMTP id 214C38FC0A for ; Wed, 7 May 2008 17:19:33 +0000 (UTC) (envelope-from yani@pi-greece.eu) Received: from techmx01.pi-greece.eu (athedsl-4448179.home.otenet.gr [79.129.207.163]) by rosebud.otenet.gr (8.13.8/8.13.8/Debian-3) with SMTP id m47Gj94h019464 for ; Wed, 7 May 2008 19:45:09 +0300 Received: (qmail 2005 invoked by uid 0); 7 May 2008 19:45:08 +0300 Received: from 192.168.1.15 by techserver.pi-greece.eu (envelope-from , uid 0) with qmail-scanner-1.25 (clamdscan: 0.93/6817. spamassassin: 3.2.4. Clear:RC:0(192.168.1.15):SA:0(-4.4/5.0):. Processed in 5.144842 secs); 07 May 2008 16:45:08 -0000 X-Spam-Status: No, hits=-4.4 required=5.0 X-Qmail-Scanner-Mail-From: yani@pi-greece.eu via techserver.pi-greece.eu X-Qmail-Scanner: 1.25 (Clear:RC:0(192.168.1.15):SA:0(-4.4/5.0):. Processed in 5.144842 secs) Received: from unimatrix.pi-office (HELO ?192.168.1.15?) (yani@pi-greece.eu@192.168.1.15) by techserver.pi-greece.eu with SMTP; 7 May 2008 19:45:03 +0300 Message-ID: <4821DC99.1050008@pi-greece.eu> Date: Wed, 07 May 2008 19:45:13 +0300 From: Yani Karydis User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20080506120014.60FED10656C9@hub.freebsd.org> In-Reply-To: <20080506120014.60FED10656C9@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Kernel panic - em0 culprit? 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, 07 May 2008 17:19:35 -0000 Hello, My server is experiencing occasional kernel panics when under moderate load. I'm attaching a crash dump and the dmesg output. I'm not sure how to read the kernel backtrace but it looks like the Intel NIC (em0) caused the problem. Occasionally, I used to get a "em0: watchdog timeout -- resetting" error message, but I never had a kernel panic. The problem started last week when I updated the server to the latest 7-STABLE. Can anyone help pinpoint the problem? Thanks, Yani kgdb output: [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". There is no member named pathname. Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/miibus.ko...Reading symbols from /boot/kernel/miibus.ko.symbols...done. done. Loaded symbols for /boot/kernel/miibus.ko Reading symbols from /boot/kernel/if_vr.ko...Reading symbols from /boot/kernel/if_vr.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_vr.ko Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from /boot/kernel/accf_http.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_http.ko Reading symbols from /boot/kernel/bridgestp.ko...Reading symbols from /boot/kernel/bridgestp.ko.symbols...done. done. Loaded symbols for /boot/kernel/bridgestp.ko Reading symbols from /boot/kernel/if_bridge.ko...Reading symbols from /boot/kernel/if_bridge.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_bridge.ko Reading symbols from /boot/kernel/wlan_wep.ko...Reading symbols from /boot/kernel/wlan_wep.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_wep.ko Reading symbols from /boot/kernel/wlan_tkip.ko...Reading symbols from /boot/kernel/wlan_tkip.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_tkip.ko Reading symbols from /boot/kernel/wlan_ccmp.ko...Reading symbols from /boot/kernel/wlan_ccmp.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_ccmp.ko Reading symbols from /boot/kernel/wlan_xauth.ko...Reading symbols from /boot/kernel/wlan_xauth.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_xauth.ko Reading symbols from /boot/kernel/wlan_acl.ko...Reading symbols from /boot/kernel/wlan_acl.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_acl.ko Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/kernel/aio.ko.symbols...done. done. Loaded symbols for /boot/kernel/aio.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/nfslockd.ko...Reading symbols from /boot/kernel/nfslockd.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfslockd.ko Reading symbols from /boot/kernel/krpc.ko...Reading symbols from /boot/kernel/krpc.ko.symbols...done. done. Loaded symbols for /boot/kernel/krpc.ko Unread portion of the kernel message buffer: em0: watchdog timeout -- resetting <5>em0: link state changed to DOWN kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05bc167 stack pointer = 0x28:0xe403ec10 frame pointer = 0x28:0xe403ec2c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 23 (em0 taskq) trap number = 12 panic: page fault Uptime: 1d2h53m51s Physical memory: 1015 MB Dumping 224 MB: 209 193 177 161 145 129 113 97 81 65 49 33 17 1 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) list 190 static __inline struct thread * 191 __curthread(void) 192 { 193 struct thread *td; 194 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); 196 return (td); 197 } 198 #define curthread (__curthread()) 199 (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc058ad84 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc058af84 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc07ccb5c in trap_fatal (frame=0xe403ebd0, eva=20) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc07cd4dd in trap (frame=0xe403ebd0) at /usr/src/sys/i386/i386/trap.c:280 #5 0xc07b721b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc05bc167 in propagate_priority (td=0xc3ab7880) at /usr/src/sys/kern/subr_turnstile.c:272 #7 0xc05bcab8 in turnstile_wait (ts=0xc3a9d370, owner=0xc3ab7880, queue=Variable "queue" is not available. ) at /usr/src/sys/kern/subr_turnstile.c:739 #8 0xc057e88d in _mtx_lock_sleep (m=0xc3baa2f4, tid=3283517440, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:416 #9 0xc04b02d7 in em_handle_rxtx (context=0xc3baa000, pending=1) at /usr/src/sys/dev/em/if_em.c:1666 #10 0xc05bb032 in taskqueue_run (queue=0xc3b94100) at /usr/src/sys/kern/subr_taskqueue.c:255 #11 0xc05bb20d in taskqueue_thread_loop (arg=0xc3baa368) at /usr/src/sys/kern/subr_taskqueue.c:374 #12 0xc0569d34 in fork_exit (callout=0xc05bb190 , arg=0xc3baa368, frame=0xe403ed38) at /usr/src/sys/kern/kern_fork.c:783 #13 0xc07b7290 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 dmesg: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #11: Tue May 6 15:34:11 EEST 2008 root@techserver.pi-greece.eu:/usr/obj/usr/src/sys/TECHSERVER7 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Sempron(tm) 2300+ (1585.75-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc0480800 real memory = 1073676288 (1023 MB) avail memory = 1041485824 (993 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 32M pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xa000-0xa0ff mem 0xd0000000-0xd7ffffff,0xe0000000-0xe000ffff at device 0.0 on pci1 em0: port 0xb000-0xb03f mem 0xe1000000-0xe101ffff,0xe1020000-0xe103ffff irq 17 at device 9.0 on pci0 em0: [FILTER] em0: Ethernet address: 00:07:e9:49:18:b3 aac0: mem 0xd8000000-0xdbffffff irq 18 at device 10.0 on pci0 aac0: Enable Raw I/O aac0: New comm. interface enabled aac0: [ITHREAD] aac0: Adaptec 2610SA, aac driver 2.0.0-1 ahc0: port 0xb400-0xb4ff mem 0xe1042000-0xe1042fff irq 19 at device 11.0 on pci0 ahc0: [ITHREAD] aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs ral0: mem 0xe1040000-0xe1041fff irq 17 at device 13.0 on pci0 ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 ral0: Ethernet address: 00:11:50:14:b7:66 ral0: [ITHREAD] atapci0: port 0xb800-0xb807,0xbc00-0xbc03,0xc000-0xc007,0xc400-0xc403,0xc800-0xc80f,0xcc00-0xccff irq 20 at device 15.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 15.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] uhci0: port 0xd400-0xd41f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd800-0xd81f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xdc00-0xdc1f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xe000-0xe01f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xe1043000-0xe10430ff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 vr0: port 0xe400-0xe4ff mem 0xe1044000-0xe10440ff irq 23 at device 18.0 on pci0 vr0: Quirks: 0x0 vr0: Revision: 0x78 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:0f:ea:e0:eb:cc vr0: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] 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 IntelliMouse Explorer, device ID 4 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xcc000-0xccfff,0xcd000-0xd0fff,0xd1000-0xd17ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] Timecounter "TSC" frequency 1585747239 Hz quality 800 Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle ad0: 305244MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 aacd0: on aac0 aacd0: 953812MB (1953406976 sectors) sa0 at ahc0 bus 0 target 3 lun 0 sa0: Removable Sequential Access SCSI-3 device sa0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit) Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted bridge0: Ethernet address: 86:5b:d2:24:75:72 em0: link state changed to UP From owner-freebsd-stable@FreeBSD.ORG Thu May 8 05:06:20 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C2E5106567D for ; Thu, 8 May 2008 05:06:20 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0098FC20 for ; Thu, 8 May 2008 05:06:19 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.14.2/8.13.1) with SMTP id m4855omC076820 for ; Thu, 8 May 2008 00:05:50 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Thu May 8 00:05:50 2008 Received: (from karl@localhost) by FS.denninger.net (8.14.2/8.13.1/Submit) id m4855oBb076814 for freebsd-stable@freebsd.org; Thu, 8 May 2008 00:05:50 -0500 (CDT) (envelope-from karl) Date: Thu, 8 May 2008 00:05:50 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20080508050550.GA76170@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Best-performing disk I/O options for a DBMS server on 7-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2008 05:06:20 -0000 What's the best option? Assume PCI/Express bus, having to buy a card AND disk(s) are fine. I assume SCSI is the best path forward (either SA/SCSI or traditional) but have been out of the loop on the card(s) that work properly for a good long while. What's my best option? -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.com Musings Of A Sentient Mind From owner-freebsd-stable@FreeBSD.ORG Thu May 8 06:28:46 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8164F106564A for ; Thu, 8 May 2008 06:28:46 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 064628FC14 for ; Thu, 8 May 2008 06:28:45 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1380413fgb.35 for ; Wed, 07 May 2008 23:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=JQSxMLZlTQlNlN0ejq4zi5hl9Y7yENA1NSeBycUj3+w=; b=hMVW6Oo2IwXj5OTXHafih2wKiTSqoMJutyiEN1k6ySlcHJ9e17lYlGjaT3qlHAz2QDI9+vkRATR1fT2OWCuNmIvwpWJTiDkSF1dA/mi5Ry112RmBfsubDOqBB3sbBHPQlYP7SZCtBnR53NpKoW4A/jItQKjmf7AyiKBIwUr259w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=W5YgaKFhJT8/0qBzySFRHH3rx2e4vNjtzsOMrtjXuKLt5ZS6lLQe+/rCkjKcCwKOnulHRk8TBjB5xaLjDpzEay6sIlvvVsKABBb1+nmFCj8Pa2rsjAQlA5cXSUlsShShqw7535vv1YQjGkAgT64yk2jfMPUNTZ8QHAabirWazDc= Received: by 10.86.99.9 with SMTP id w9mr5548164fgb.6.1210228124712; Wed, 07 May 2008 23:28:44 -0700 (PDT) Received: by 10.86.81.6 with HTTP; Wed, 7 May 2008 23:28:44 -0700 (PDT) Message-ID: Date: Thu, 8 May 2008 08:28:44 +0200 From: "Claus Guttesen" To: freebsd-stable@freebsd.org In-Reply-To: <20080508050550.GA76170@FS.denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080508050550.GA76170@FS.denninger.net> Subject: Re: Best-performing disk I/O options for a DBMS server on 7-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2008 06:28:46 -0000 > What's the best option? > > Assume PCI/Express bus, having to buy a card AND disk(s) are fine. > > I assume SCSI is the best path forward (either SA/SCSI or traditional) but > have been out of the loop on the card(s) that work properly for a good long > while. > > What's my best option? I have a HP DL360 G5 with an addon p800-controller with battery-backed cache, a msa70-cabinet and 11 2,5" sas-disks @ 15K in raid-6 and one hotspare. The controller has 512 MB and is performing satisfactory. This is on FreeBSD 7.0 release and postgresql 8.3.1. I've heard many positive remarks on areca's raid-controllers as well, vendor-support on FreeBSD and good performance. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Thu May 8 06:30:45 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B675E106564A for ; Thu, 8 May 2008 06:30:45 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 761308FC0C for ; Thu, 8 May 2008 06:30:45 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 7E97E13F59; Thu, 8 May 2008 16:30:43 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from anzac.hos (132.169.233.220.exetel.com.au [220.233.169.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 72F491392A for ; Thu, 8 May 2008 16:30:39 +1000 (EST) Message-ID: <48229E0F.90004@modulus.org> Date: Thu, 08 May 2008 16:30:39 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.0 (X11/20070426) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20080508050550.GA76170@FS.denninger.net> In-Reply-To: <20080508050550.GA76170@FS.denninger.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Best-performing disk I/O options for a DBMS server on 7-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2008 06:30:45 -0000 Karl Denninger wrote: > I assume SCSI is the best path forward (either SA/SCSI or traditional) but > have been out of the loop on the card(s) that work properly for a good long > while. I've used several of the new 3ware SATA PCI-express cards: 2, 4 and 16 ports. They always work really well under FreeBSD 6 and 7, and are very fast. I haven't tried their SAS cards personally but I understand that it is equally good. FWIW, I have had bad experiences with Areca. - Andrew From owner-freebsd-stable@FreeBSD.ORG Thu May 8 07:27:36 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ED6E106566B; Thu, 8 May 2008 07:27:36 +0000 (UTC) (envelope-from Ingeborg.Hellemo@cc.uit.no) Received: from mux2.uit.no (mux2.uit.no [129.242.5.252]) by mx1.freebsd.org (Postfix) with ESMTP id E0D9D8FC0C; Thu, 8 May 2008 07:27:35 +0000 (UTC) (envelope-from Ingeborg.Hellemo@cc.uit.no) Received: from flode.cc.uit.no (flode.cc.uit.no [129.242.6.250]) by mux2.uit.no (8.14.2/8.14.2/Mux) with ESMTP id m487RWpH079802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 May 2008 09:27:33 +0200 (CEST) Received: from barnetv.cc.uit.no (barnetv.cc.uit.no [129.242.6.226]) by flode.cc.uit.no (8.13.3/8.13.3) with ESMTP id m487RitK033055; Thu, 8 May 2008 09:27:44 +0200 (CEST) (envelope-from ingeborg@cc.uit.no) Received: from barnetv.cc.uit.no (localhost.cc.uit.no [127.0.0.1]) by barnetv.cc.uit.no (8.14.2/8.14.2) with ESMTP id m487RWtp052442; Thu, 8 May 2008 09:27:32 +0200 (CEST) (envelope-from ingeborg@barnetv.cc.uit.no) Message-Id: <200805080727.m487RWtp052442@barnetv.cc.uit.no> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Marcel Moolenaar In-reply-to: Your message of "Tue, 06 May 2008 09:53:42 PDT." <770A639E-DDE0-4464-B8A3-1D63EBFA6B65@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Thu, 08 May 2008 09:27:32 +0200 From: Ingeborg Hellemo X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.63 on 129.242.5.252 Cc: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: PCI serial card works on 6.2 but not on 6.3 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, 08 May 2008 07:27:36 -0000 xcllnt@mac.com said: > The problem seems to be revision 1.51.2.3 of src/sys/dev/puc/pucdata.c > Could you try the following patch? Thank you, it worked! --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg@cc.uit.no (Univ. of Tromsø, Norway) From owner-freebsd-stable@FreeBSD.ORG Thu May 8 07:30:14 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA1AE106564A for ; Thu, 8 May 2008 07:30:14 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 634048FC1C for ; Thu, 8 May 2008 07:30:14 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 1C6F71B10F2F; Thu, 8 May 2008 09:30:13 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id C22461B10ED2 for ; Thu, 8 May 2008 09:30:07 +0200 (CEST) Message-ID: <4822ABFF.3050700@moneybookers.com> Date: Thu, 08 May 2008 10:30:07 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.14 (X11/20080503) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/7060/Thu May 8 08:07:49 2008 on blah.cmotd.com X-Virus-Status: Clean Subject: cvsup.uk.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: Thu, 08 May 2008 07:30:14 -0000 Greetings, cvsup.uk.FreeBSD.org is outdated. I know this is not the proper list, but which one is? -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-stable@FreeBSD.ORG Thu May 8 07:35:42 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E555106567D; Thu, 8 May 2008 07:35:42 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id 2370A8FC16; Thu, 8 May 2008 07:35:42 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id D85D039C95; Thu, 8 May 2008 09:35:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXxWhSu3eSQ3; Thu, 8 May 2008 09:35:40 +0200 (CEST) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id 7C3D139C88; Thu, 8 May 2008 09:35:40 +0200 (CEST) Date: Thu, 8 May 2008 09:35:40 +0200 From: Ollivier Robert To: freebsd-stable@freebsd.org Message-ID: <20080508073540.GA95771@keltia.freenix.fr> References: <4822ABFF.3050700@moneybookers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4822ABFF.3050700@moneybookers.com> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 6.2 / Dell D820 SMP User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-hubs@freebsd.org Subject: Re: cvsup.uk.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: Thu, 08 May 2008 07:35:42 -0000 Stefan Lambrev disait : > cvsup.uk.FreeBSD.org is outdated. > I know this is not the proper list, but which one is? freebsd-hubs is, redirected. I've noticed that recently but I should have send a mail about it, sorry. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin sidhe.keltia.net Version 9.2.0: Tue Feb 5 16:13:22 PST 2008; i386 From owner-freebsd-stable@FreeBSD.ORG Thu May 8 08:26:03 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 326F61065678 for ; Thu, 8 May 2008 08:26:03 +0000 (UTC) (envelope-from paul.koch@statseeker.com) Received: from wally.statseeker.com (wally.statseeker.com [203.39.101.146]) by mx1.freebsd.org (Postfix) with ESMTP id B3CAD8FC20 for ; Thu, 8 May 2008 08:26:02 +0000 (UTC) (envelope-from paul.koch@statseeker.com) Received: from localhost (localhost [127.0.0.1]) by wally.statseeker.com (8.14.2/8.14.2) with ESMTP id m488CRxJ058080 for ; Thu, 8 May 2008 18:12:27 +1000 (EST) (envelope-from paul.koch@statseeker.com) X-Virus-Scanned: amavisd-new at statseeker.com Received: from wally.statseeker.com ([127.0.0.1]) by localhost (wally.statseeker.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8WR4bn1Y6eJP for ; Thu, 8 May 2008 18:12:22 +1000 (EST) Received: from speedy.statseeker.com (speedy.statseeker.com [10.1.1.100]) (authenticated bits=0) by wally.statseeker.com (8.14.2/8.14.2) with ESMTP id m488CLYF058075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 May 2008 18:12:21 +1000 (EST) (envelope-from paul.koch@statseeker.com) From: Paul Koch To: freebsd-stable@freebsd.org Date: Thu, 8 May 2008 18:12:24 +1000 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_oXrIIONLCDwd8Mw" Message-Id: <200805081812.24692.paul.koch@statseeker.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: flock incorrectly detects deadlock on 7-stable and current X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: paul.koch@statseeker.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2008 08:26:03 -0000 --Boundary-00=_oXrIIONLCDwd8Mw Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, We have been trying to track down a problem with one of our apps which does a lot of flock(2) calls. flock returns errno 11 (Resource deadlock avoided) under certain scenarios. Our app works fine on 7-Release, but fails on 7-stable and -current. The problem appears to be when we have at least three processes doing flock() on a file, and one is trying to upgrade a shared lock to an exclusive lock but fails with a deadlock avoided. Attached is a simple flock() test program. a. Process 1 requests and gets a shared lock b. Process 2 requests and blocks for an exclusive lock c. Process 3 requests and gets a shared lock d. Process 3 requests an upgrade to an exclusive lock but fails (errno 11) If we change 'd' to Process 3 requests unlock, then requests exclusive lock, it works. The manual page says: "A shared lock may be upgraded to an exclusive lock, and vice versa, simply by specifying the appropriate lock type; this results in the previous lock being released and the new lock applied (possibly after other processes have gained and released the lock)." The manual page doesn't mention that flock() can fail with a deadlock. Our test environment is: - 8 core Intel machine running i386 stable - 4 core Intel machine running amd64 current (20080508) - 4 core Intel machine running amd64 stable (20080508) - 2 core AMD machine running i386 stable (20080418) - 2 core AMD machine running i386 stable (20080418) - single core (no hyperthreading) i386 stable (20080418) There appears to have been changes to kern_lockf.c and other stuff around the 10th April to do with deadlock detection. We don't see the problem on 6.2-stable, 7-Release, or 7-stable pre ~10th April. Paul. --Boundary-00=_oXrIIONLCDwd8Mw-- From owner-freebsd-stable@FreeBSD.ORG Thu May 8 08:37:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 659341065670 for ; Thu, 8 May 2008 08:37:02 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id 1E0548FC0A for ; Thu, 8 May 2008 08:37:02 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc] (unknown [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id 721EA3F8F; Thu, 8 May 2008 09:37:00 +0100 (BST) Message-Id: <1B6FCF23-413B-452A-B66D-3CCD6257F7BD@rabson.org> From: Doug Rabson To: paul.koch@statseeker.com In-Reply-To: <200805081812.24692.paul.koch@statseeker.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 8 May 2008 09:37:00 +0100 References: <200805081812.24692.paul.koch@statseeker.com> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-stable@freebsd.org Subject: Re: flock incorrectly detects deadlock on 7-stable and current 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, 08 May 2008 08:37:02 -0000 On 8 May 2008, at 09:12, Paul Koch wrote: > Hi, > > We have been trying to track down a problem with one of our apps which > does a lot of flock(2) calls. flock returns errno 11 (Resource > deadlock avoided) under certain scenarios. Our app works fine on > 7-Release, but fails on 7-stable and -current. > > The problem appears to be when we have at least three processes doing > flock() on a file, and one is trying to upgrade a shared lock to an > exclusive lock but fails with a deadlock avoided. > > Attached is a simple flock() test program. > > a. Process 1 requests and gets a shared lock > b. Process 2 requests and blocks for an exclusive lock > c. Process 3 requests and gets a shared lock > d. Process 3 requests an upgrade to an exclusive lock but fails (errno > 11) > > If we change 'd' to > Process 3 requests unlock, then requests exclusive lock, it works. Could you possibly try this patch and tell me if it helps: ==== //depot/user/dfr/lockd/sys/kern/kern_lockf.c#57 - /tank/projects/ lockd/src/sys/kern/kern_lockf.c ==== @@ -1370,6 +1370,18 @@ } /* + * For flock type locks, we must first remove + * any shared locks that we hold before we sleep + * waiting for an exclusive lock. + */ + if ((lock->lf_flags & F_FLOCK) && + lock->lf_type == F_WRLCK) { + lock->lf_type = F_UNLCK; + lf_activate_lock(state, lock); + lock->lf_type = F_WRLCK; + } + + /* * We are blocked. Create edges to each blocking lock, * checking for deadlock using the owner graph. For * simplicity, we run deadlock detection for all @@ -1389,17 +1401,6 @@ } /* - * For flock type locks, we must first remove - * any shared locks that we hold before we sleep - * waiting for an exclusive lock. - */ - if ((lock->lf_flags & F_FLOCK) && - lock->lf_type == F_WRLCK) { - lock->lf_type = F_UNLCK; - lf_activate_lock(state, lock); - lock->lf_type = F_WRLCK; - } - /* * We have added edges to everything that blocks * us. Sleep until they all go away. */ From owner-freebsd-stable@FreeBSD.ORG Thu May 8 09:30:03 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D188106566B for ; Thu, 8 May 2008 09:30:03 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id 065618FC15 for ; Thu, 8 May 2008 09:30:03 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [10.50.50.2] (helo=smaug.rattatosk) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju2Rt-0003xs-8l; Thu, 08 May 2008 10:30:01 +0100 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju2Rt-000C9a-2h; Thu, 08 May 2008 10:30:01 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju2Rt-000MNF-1k; Thu, 08 May 2008 10:30:01 +0100 To: freebsd-stable@freebsd.org, karl@denninger.net In-Reply-To: <20080508050550.GA76170@FS.denninger.net> Message-Id: From: Pete French Date: Thu, 08 May 2008 10:30:01 +0100 Cc: Subject: Re: Best-performing disk I/O options for a DBMS server on 7-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2008 09:30:03 -0000 > I assume SCSI is the best path forward (either SA/SCSI or traditional) but > have been out of the loop on the card(s) that work properly for a good long > while. HP P400 cards are PCI express and SAS - they work very well under FreeBSD. I've also used the cheaper E200 and that appears to be fine too, though I havent run it for as long as the 400's. http://h18004.www1.hp.com/products/servers/proliantstorage/arraycontrollers/smartarrayp400/index.html -pete. From owner-freebsd-stable@FreeBSD.ORG Thu May 8 09:46:46 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38D2C106566C for ; Thu, 8 May 2008 09:46:46 +0000 (UTC) (envelope-from news@streetsoul.lv) Received: from web04.hostnet.lv (web04.hostnet.lv [81.94.239.56]) by mx1.freebsd.org (Postfix) with ESMTP id BD9D68FC19 for ; Thu, 8 May 2008 09:46:45 +0000 (UTC) (envelope-from news@streetsoul.lv) X-ClientAddr: 127.0.0.1 Received: from www.street-soul.eu (localhost [127.0.0.1]) by web04.hostnet.lv (8.12.11.20060308/8.12.11) with ESMTP id m489gonb019906 for ; Thu, 8 May 2008 12:42:50 +0300 Date: Thu, 8 May 2008 12:42:50 +0300 To: stable@freebsd.org From: Streetsoul Message-ID: X-Priority: 3 X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.0 rc1] MIME-Version: 1.0 X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (web04.hostnet.lv [127.0.0.1]); Thu, 08 May 2008 12:42:50 +0300 (EEST) X-HostNet-MailScanner-Information: Hostnet Virus And Antispam software X-HostNet-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-MCPCheck: X-MailScanner-From: news@streetsoul.lv Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: New Arrivals: New brand - Analog Clothing 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, 08 May 2008 09:46:46 -0000 STREETSOUL.EU - Streetwear Clothing Online Store Newsletter ***************************************************************** Sunny Greetings to Ya all!!! New Arrivals - New Brand - Analog Cloting!!! Press here to view new arrivals from Analog Clothing! or copy the link in a browser: http://www.streetsoul.eu/zoom_brand/31 More About Analog Clothing: It's written in our DNA. It's woven into the fabric of our constitution. It was in Trevor Andrew's first Analog I-Pod jacket and it's scratched on the bottom of Nathan Fletcher's 4-fin. It's the ultra-thin thread that ties together surfing, skateboarding and snowboarding. It's the fearless voice calling you to Liberate, Unify, Mobilize and Resolve. It's non-digital, low-technology. It's the new elitism. It's Analogic. Since the beginning of the action sports market, influential kids have gravitated towards progressive and creative movements within snowboarding, skateboarding and surfing. Analog is a clothing company born in outerwear, raised at the beach and entrenched in cities everywhere. Analog is an invitation to take a stand, make a point, challenge a value and open a few minds. Check our internet store or if you happen to be in Riga, you're welcome to visit us @ 85 Terbatas st. :) http://www.streetsoul.eu/streetstore Cheers! streetsoul.eu ----------------------------------------------------------------------------------------------------------------------------------------------------------- streetsoul brands: 667 | Adidas Originals | Airbag | ALAKAZAM! | Alprausch | Amos | BICO | Creative Recreation | Emily The Strange | Encore | Five Four | Goorin Brothers | gsus | Irie Daily | King Apparel | Levi's Engineered Jeans® | Levi's® | Mazine | My Zoo | Nike | OAKLEY | pa:nuu | Reebok | Saddler | Schlepp | Streetsoul | Stussy | Sweet & Toxic | T.U.K. * To no longer receive these messages, please send a blank email to unsubscribe@streetsoul.eu From owner-freebsd-stable@FreeBSD.ORG Thu May 8 11:37:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21A871065678 for ; Thu, 8 May 2008 11:37:02 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id CFD2A8FC1B for ; Thu, 8 May 2008 11:37:01 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [10.50.50.2] (helo=smaug.rattatosk) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju4Qm-0005pB-Co for freebsd-stable@freebsd.org; Thu, 08 May 2008 12:37:00 +0100 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju4Qm-000Dhl-AT for freebsd-stable@freebsd.org; Thu, 08 May 2008 12:37:00 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju4Qm-0005iL-7C for freebsd-stable@freebsd.org; Thu, 08 May 2008 12:37:00 +0100 To: freebsd-stable@freebsd.org Message-Id: From: Pete French Date: Thu, 08 May 2008 12:37:00 +0100 Subject: Re: Dreadful gmirror performance - suggested changes to 'prefer' 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, 08 May 2008 11:37:02 -0000 I am just looking at this again, and am in a bit of a mood for writing some patches, so I wanted to run the following idea past people as regards the priority system in the 'prefer' balancing method. Just to recap, creating a gmirror creates the first device with priority zero. Adding extra devices lets you set their priorities, but you cant set negative values. The upshot is that the first device in the mirror always has the lowest priority - so you cannot (for example) create a mirror with a local disc, subsequently add a remote disc, but then set the mirror up to prefer the local drive. I am thinking of a couple of changes - the first being the patch prroposed from Andrew Snow which would create the mirror with the priority at something other than zero (128 would be my preference) so that extra devices can be inserted both above and below it. This solves the problem for newly created mirrors as the priority can then be set as appropiate. The other change I wanted to make was to add a second 'prefer' mode to gmirror though - one which would prefer the *lowest* priority instead of the highest priority. I would probably rename the existing mode to 'prefer-high' (keeping 'prefer' as a synonym for backward compatibility) and add a 'prefer-low' as well. As an existing gmirror can have it's load balance algorithm changed on the fly, this lets you change which of the drives is preferred in an existing installationg. This is precisely what you need when switching between two machines so that the local and remote drives become reversed. I havent looked at the code in detail, but I can't see that it would be too difficult. What do people think ? -pete. From owner-freebsd-stable@FreeBSD.ORG Thu May 8 12:41:55 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08023106566C for ; Thu, 8 May 2008 12:41:55 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 836688FC1E for ; Thu, 8 May 2008 12:41:54 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ju5RX-0000eT-4O for freebsd-stable@freebsd.org; Thu, 08 May 2008 12:41:51 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 May 2008 12:41:51 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 May 2008 12:41:51 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 08 May 2008 14:41:41 +0200 Lines: 81 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig435046F627FA2D6A2EFA0B8D" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.12 (X11/20080227) In-Reply-To: X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: Dreadful gmirror performance - suggested changes to 'prefer' 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, 08 May 2008 12:41:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig435046F627FA2D6A2EFA0B8D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pete French wrote: > I am just looking at this again, and am in a bit of a mood > for writing some patches, so I wanted to run the following idea past pe= ople > as regards the priority system in the 'prefer' balancing method. >=20 > Just to recap, creating a gmirror creates the first device with priorit= y > zero. Adding extra devices lets you set their priorities, but you cant > set negative values. The upshot is that the first device in the mirror > always has the lowest priority - so you cannot (for example) create a m= irror > with a local disc, subsequently add a remote disc, but then set the mir= ror > up to prefer the local drive. Ok. > I am thinking of a couple of changes - the first being the patch prropo= sed > from Andrew Snow which would create the mirror with the priority at som= ething > other than zero (128 would be my preference) so that extra devices can = be > inserted both above and below it. This solves the problem for newly > created mirrors as the priority can then be set as appropiate. >=20 > The other change I wanted to make was to add a second 'prefer' mode to = gmirror > though - one which would prefer the *lowest* priority instead of the > highest priority. I would probably rename the existing mode to 'prefer-= high' > (keeping 'prefer' as a synonym for backward compatibility) and add > a 'prefer-low' as well. As an existing gmirror can have it's load balan= ce > algorithm changed on the fly, this lets you change which of the drives > is preferred in an existing installationg. This is precisely what you n= eed > when switching between two machines so that the local and remote drives= > become reversed. >=20 > I havent looked at the code in detail, but I can't see that it would be= too > difficult. What do people think ? Couple of ideas: - Don't use "128" as the default since it will lead people to think there's an 8-bit quantity behind the setting (and subsequently develop weird theories about how the setting works), when it isn't so. Use 100 or 1000. - Why not go all the way and make another argument or a switch that will specify exactly which drive to prefer, so you could say "prefer N", where N is any drive / component, not only the one with lowest/highest priority? This is slightly more complex and will probably require an addition to the metadata (which isn't complicated but you have to be careful) and a workaround so the old semantics of the "plain" setting is supported. --------------enig435046F627FA2D6A2EFA0B8D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIIvUFldnAQVacBcgRAr5+AJ0ShVReGJFnWvxI5obV/HlligMEugCfVjNw a1k3Y2BnV1dsNb3j9UyrNCI= =bmCL -----END PGP SIGNATURE----- --------------enig435046F627FA2D6A2EFA0B8D-- From owner-freebsd-stable@FreeBSD.ORG Thu May 8 13:18:25 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39FFF1065678; Thu, 8 May 2008 13:18:25 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id E85598FC1B; Thu, 8 May 2008 13:18:24 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [10.50.50.2] (helo=smaug.rattatosk) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju60t-0006nx-KZ; Thu, 08 May 2008 14:18:23 +0100 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju60t-000Ec3-HG; Thu, 08 May 2008 14:18:23 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju60t-0001c3-GO; Thu, 08 May 2008 14:18:23 +0100 To: freebsd-stable@freebsd.org, ivoras@freebsd.org In-Reply-To: Message-Id: From: Pete French Date: Thu, 08 May 2008 14:18:23 +0100 Cc: Subject: Re: Dreadful gmirror performance - suggested changes to 'prefer' 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, 08 May 2008 13:18:25 -0000 > Couple of ideas: > > - Don't use "128" as the default since it will lead people to think > there's an 8-bit quantity behind the setting (and subsequently develop > weird theories about how the setting works), when it isn't so. Use 100 > or 1000. Are you sure it isn't an 8 bit value underneath ? I know it is defined as an int, but trying to set it to anything outside the range 0-255 results in it wrapping round (e.g. you try making the defalt 1000 and it comes out as 232). I havent looked in detail as *why* thats happening, but it certainly behaves like it is 8 bits, hence my choice of default. > - Why not go all the way and make another argument or a switch that will > specify exactly which drive to prefer, so you could say "prefer N", > where N is any drive / component, not only the one with lowest/highest > priority? This is slightly more complex and will probably require an > addition to the metadata (which isn't complicated but you have to be > careful) and a workaround so the old semantics of the "plain" setting is > supported. I thought about that, but the priority scheme doesnt just specify one drive, it specifies a whole set - effectively you find the highest usable drive. Just defining one isn't sufficient, you need to have a defined way of falling back if that one isn't active. Secondly I want to avoid having to search the whole list event time. Currently the list of drives is created in priority order (no matter what the balance algorithm) so the 'prefer' algorithm simply traverses the list looking for the first active drive. I wanted to keep that and thus simply convert the list to a tailq so I can traverse it both ways, rather than having to seek the whole list every time. It keeps the code as close to the current code as possible. I'll get an initial version out and then maybe take a look at doing something more complex though. cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Thu May 8 13:37:54 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACBD11065673 for ; Thu, 8 May 2008 13:37:54 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 342568FC14 for ; Thu, 8 May 2008 13:37:53 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ju6Jj-0003he-08 for freebsd-stable@freebsd.org; Thu, 08 May 2008 13:37:51 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 May 2008 13:37:50 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 May 2008 13:37:50 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 08 May 2008 15:37:42 +0200 Lines: 72 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6DA7B003B2455196A5899AB1" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.12 (X11/20080227) In-Reply-To: X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: Dreadful gmirror performance - suggested changes to 'prefer' 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, 08 May 2008 13:37:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6DA7B003B2455196A5899AB1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pete French wrote: >> Couple of ideas: >> >> - Don't use "128" as the default since it will lead people to think >> there's an 8-bit quantity behind the setting (and subsequently develop= >> weird theories about how the setting works), when it isn't so. Use 100= >> or 1000. >=20 > Are you sure it isn't an 8 bit value underneath ? I know it is defined = as > an int, but trying to set it to anything outside the range 0-255 result= s > in it wrapping round (e.g. you try making the defalt 1000 and it comes > out as 232). I havent looked in detail as *why* thats happening, but it= > certainly behaves like it is 8 bits, hence my choice of default. Ah, I see; It's defined as u_int d_priority; /* Disk priority. */ in struct g_mirror_disk but as uint8_t md_priority; /* Disk priority. */ in struct g_mirror_metadata. Ok, 128 looks reasonable now. > I thought about that, but the priority scheme doesnt just specify one > drive, it specifies a whole set - effectively you find the highest usab= le > drive. Just defining one isn't sufficient, you need to have a defined > way of falling back if that one isn't active. Secondly I want to avoid > having to search the whole list event time. Currently the list of drive= s > is created in priority order (no matter what the balance algorithm) so > the 'prefer' algorithm simply traverses the list looking for the first > active drive. I wanted to keep that and thus simply convert the list to= > a tailq so I can traverse it both ways, rather than having to seek the > whole list every time. It keeps the code as close to the current code > as possible. Hmm, it would seem you need "N-and-upper" and "N-and-lower", but this is inconvenient. Your original idea is probably better. > I'll get an initial version out and then maybe take a look at doing > something more complex though. --------------enig6DA7B003B2455196A5899AB1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIIwImldnAQVacBcgRAsjSAJ9tPDR9d1k1nsU9XV1CbmA6Z2TlkgCgpDFI p5FTZOLH2ITU2Nb5qg0yWX8= =JEsm -----END PGP SIGNATURE----- --------------enig6DA7B003B2455196A5899AB1-- From owner-freebsd-stable@FreeBSD.ORG Thu May 8 14:15:47 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 681EC1065671; Thu, 8 May 2008 14:15:47 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id 23C348FC0C; Thu, 8 May 2008 14:15:47 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [10.50.50.2] (helo=smaug.rattatosk) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju6uQ-0007LT-9A; Thu, 08 May 2008 15:15:46 +0100 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju6uQ-000F7j-61; Thu, 08 May 2008 15:15:46 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju6uQ-0002LK-52; Thu, 08 May 2008 15:15:46 +0100 To: freebsd-stable@freebsd.org, ivoras@freebsd.org In-Reply-To: Message-Id: From: Pete French Date: Thu, 08 May 2008 15:15:46 +0100 Cc: Subject: Re: Dreadful gmirror performance - suggested changes to 'prefer' 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, 08 May 2008 14:15:47 -0000 > Hmm, it would seem you need "N-and-upper" and "N-and-lower", but this is > inconvenient. Your original idea is probably better. Certainly simpler to implement. Ideally, of course, you could change the priority on the fly (which would solve all of this) but the fact that it is stored in priority order makes that a bit of a pain too I would imagine. Do you have any thoughts on dumping by the way ? I initially implemnted the code to chheck for 'prefer-low' and dump to the last disc instead of the first. But the manual page suggests ways of working with prefer which may well be broken doing it that way, so I took the change out in order to make the manpage advice still correct. I have a working implementation here now if anyone wants to test by the way - I ended up simply adding a 'prefer-low' and changing the default priority. Everything else behaves the same as it always did. -pete. From owner-freebsd-stable@FreeBSD.ORG Thu May 8 14:37:31 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D48731065679 for ; Thu, 8 May 2008 14:37:31 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id 742698FC21 for ; Thu, 8 May 2008 14:37:31 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [10.50.50.2] (helo=smaug.rattatosk) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju7FR-0007Zk-JY for freebsd-stable@freebsd.org; Thu, 08 May 2008 15:37:30 +0100 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju7FR-000FJU-Ap for freebsd-stable@freebsd.org; Thu, 08 May 2008 15:37:29 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ju7FR-0002ZG-9q for freebsd-stable@freebsd.org; Thu, 08 May 2008 15:37:29 +0100 To: freebsd-stable@freebsd.org In-Reply-To: Message-Id: From: Pete French Date: Thu, 08 May 2008 15:37:29 +0100 Subject: Re: Dreadful gmirror performance - suggested changes to 'prefer' 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, 08 May 2008 14:37:31 -0000 O.K., heres an initial version of the patch - relative to 7.0 release. Please test and let me know if there are any problems. Patch should apply cleanly if you are in '/usr'. cheers, -pete. begin 644 gmirror.patch.gz M'XL("",/(T@"`V=M:7)R;W(N<&%T8V@`W3O[4]M(TC_+?\6$JRQV;($D/P!S MX5L6G,1U8/:,DTV^U%0DW'?+?N@4A%H>GJF M>_H]+"P`_X&YU^/S(1>B?` MBBS+^Z&6-$4YD96VK+:9IG:U=E?M'"GQ#ZLKJJ)4ZO7ZSEM`A*>(4#EE:@NP M=9O-%83??\_DUDGCA-7Y_]]_7V$5%D9&Y)C,G!D!ICPS4\T_[\?^PU M.P@7KA,=-)CI>Q-GN@SL_+#G>_;!>8+%\:*Y\4V/!*;0=4P;P%K*62>+(GXO MJ^<5N3C5\4([B/1%X``[HT<`4\XK]>U0JG9ZGB'HB^]8C-BCSPW'JX91L#0C M-C4C5P_LG]DK^*_!EE[H3#W;8A/7F(:U\]+YAADY7XS(+L4!A4$Y M'LRE&]8N!=M/^&!H5M2.KFJRI3#WM-I6N MEE=490?-SR)+M+[=5=2NTBK5>E5MH]K3`T7SJ!^QJSFI:85=!39(-S.$O(/H MC&8V\P,+1,N?@.+.%Z#G7A0R!_[!'T%D>%&#C6W30%$T4I##C"0"\-@(0;=\ MCSDP>>&'3N3X7D6&(S2"R/&F;!+X)QRG@QMPZ*U MH_)%7?\KKNGZAG64L#!>9.OLXI:!Y!P*&=!7ZEO1A'/#=?-XXJT$_M*SY,`' MJ:FP]W`NF1SKS/;`WOMP&L#L=(G(9R`'&=*X[2_1FL>0A#(6QX+'7#M< MT)2U<,([=D"R&I!7E,)ONK`NWX6F M?!&:NNN;8(GO/^HW=U=_ZUVCA0&K=]._'^EO[H:]RZMW533)#19/P+_"!K-T MS_X6H:FM2Z/+_LW?=P47!@S]$5A!]);LG__D9E^^L/3D-?^EAM"25Z^?<[?# MJ3KE.D^/[51]?&:R8CK0EX`_L(B"P(Z6@4>CM926UJG&PQ;^X*XU-,$Q)+SP M)Y%YOC=]P][MW8>>V*_8X'E"CA@MTI$'9E(L;[K]!91(-]'2N.G^^0D2AAD$ M+T@K'^-^-_N>#=[?W%`HT5;/P"35Z<&IG2X`0("CL![(Q M"ZQ%X#\F4#"+.VP>%_`HXC6C\^X/[T=Y@FOG%&>\B/<'D0S\;)M%8I%=0(C( M#BO4LRNLGR9$*18!'KZQ[UZS?[W5;_O#X=U0O^[?_TU_MQ2)4>V"K?<"@>Y\=S7HYY^>37J?^B141B#6WI(C4'[C.DXAO#1,QV+#'S* ML-X/[]]650C4K^TOF%.]#+N,(-EX.5]`0`1>_>7R"$)X@<>+)ZQS)Q.]3M87\I@?G=ZH7D3.W_64D M5",Y"<=R;9[*_@8L>['=5)F^!RG,TN;Z7R8J:)E>AH`YEID:FQO!`T@+Y/"F M:QL>"`PQI\G-'#V(.<2;\Q5N*)E7D"A&^E>(]'$`F0BN#A]_2H993@`)D&"8 MJFC-AMJ$E([_THF#WN-7O!3"?K+3$A2S0$4Q_0$=Q:QJX@204B6Y4)K:1C/( M+)/W5,CYZK@N`%#"B3X8TR9$QI.T0TKG#E?3SB.:WI^LR^UFSDI2:RZ#`&#< M1U1$V+YGFY%MB7W8M!7/CW`[QAB$021Q'!W2R(Q)!($A_AG88Q\@X9B<**:! M$"5XF>%9W'_,`M]S_@$O7#C'X(A=&1XN9_DL]"%FFB&U8SN"L?^A*M4OY@ED M^)S#EDV(9G"L1!!DJ1";+2*RI.;,-A\XYL,T7SY$(4#:#(M+!^2YF/US1'/8 M\L*8XEHNXS/"^+3Q8/U)NBNDFJC#E;\:/!DF+#SV`(!'9G]SPH@R9A(B`VL9 M(:33CCF#C;FP'Q(7VLP1'#3AR,O0^E-=`W!%G3Z@FTB*K/J#'7BVR^E]58NW@-%Z MG/[`!/G"M;TIB-A%;I-)L;`F3$.;>QIX%H-&F,%>F>,%;0'^^EEW/`<2R)^7 M]M*N_1',)NR>5TE-%P1,!Q*JXX7(552UU:3*7ZM3<".L2E72@-?=,H=,!60^ M9'O6R@"K)R^(];\C%N7CD%5.):5PA4KA2<:`VA'8/Z=E<:H0GH$?:6.-\*S3 MT*BH_U2X8ZC("1)`L`3[K9-9J1:S$JXR[%5H8CT_E3TXJTK]/\;1P*L1=""S MVL9TE'*B=!38$R[G8$M>F8OS'V55.!I>4_40%<]"] M%\=)Z>H0:]:E)V:[X")6-Z`/>Q]ZP_M>^4:F\U]K2Q0"QWBR^:O0CE@C;3QK M'%>$X6N=\-JFVCJ-BYOH#-XXH-@&%5G(?^5*RZ+"+3R`L-YQ_2*7"EHW0:JBK^8LM0G*IHLCCB3$5'7H?LQV'O36_8Y89AK6F,$=8W8]'?]=^^ZW*= MVHRJP511QTI5;R/BF[N?=L.KY,E>R\/AW?O!-?S_0W^PAI7\1D?G-SHI`_A1 M=9ITQ==I)8I.82/W];W!W6WO%N-C#^-D#'AYL@F*@A=(DE#U<@G>4X3WEF$) MO2_(X'?96@UQ+(3T`:Q37L3C:7DFKLAZEZY!E!;=@RCMA#%3B!$7ONM/'_6E MAS<$U5I):4?)EG8@9%Y"``WFI/IR>?QR6<.ZS@+T/UO428[+XV3R$]J@BVEA M*(Z"?S=EH))`*AJ\3(Q/ZQ MTDKL:6K$GE8[:]1X^)*]4^+)14X^0T<*-"LWU^^Z6TBI,$BKLIE(>\> M<\MY\5?!B_B05\QL*BX'5TF5I%#S&P?^@^V!/CPX"RSS442H MSI^5D>0FX/F%I'`9<2%V)\0EV5@Y>$YP3H3@G#8SU!_3S6C`6ZVR)@%>+PKA M_&])-X2J.<)S<6FY92&JZ090:ZI*:C5+BL?O>8>+55)"-D)(?P[(=*+E,&';U[G+PMG==%?5DJ1"[9=B#A\E9U+O]5XLZ6M,VD;1CV&*V^& MR?=KY!9Y2CW;(FVZDHM$7[X9]89K:R4<>)IW9UIVH^0I$S@ M_U!#\4Y(.+/U%BKGV+@>QQK842C8ZJCI!P1;.J92(T6!B"P_BWW:H=&+LT\< M*C5,JA1,G6JM+96"\)O^C?^5;3-,^OUBBRZ<1"8)ZGWH7_5$3UKO?C2\^U3C M[>K8;T$M7^N-$F<$@FPP,6G::I@!A)6(F!GFU_17&W\EB1:U8DJ_J?7-CWP& MUCGFQTF+^)%F\YGZD%@YL*=+U\"S=XU'VZJ=ET(YWL1UIK-HS3#/D5,,7-S]WZDW_Z(25.L-&JW"3I%;61=WK^A26A+H009V%0Z7`Z;RDDBA[@ZR>^+ MM'Y04K^[,CR\3#I?_%LB<0,J>2B[>+_;N!U`+/RDD]:YRQ>EN)&XU7)I1<'4CJ!CB\ MII$D;0/$_8\W_9$D-2OR6A"Z_Y!@E_4M,/SR91>XF[N?I/:&7=T"7:MO!W># MWH9]WEY^E-:MN&%+FZ;A1C'J69EI?BP=+^JT]$AB(C4]Q\M0D$3^O97ATM>-1U096H+WBB0$I3HD@F*;W6&( MA3J;^II8_UJ`E^4@EE]&0L!Z/AIVIN>DTXD]2; M;P1B3^K<(C[ER0+^(@ETRVT!SU3.5,.DL+8^2<3-]UG1!)Y*UI(GY) MQ\55F^!63`5/U1JLL,/8L*>$<+BT$6`M?'(,26#,SV%`WW/Z$U$>67\$V`3" MV\K/!<&:B,V5I%3.NS]IB;0K-+\T?Q52^I@A(+-Q[J'XSBDL6B65WF^C(I"2TIB*(H"6TN&?_RBG\0+$Z4SGT MTGOP_*\>UCF?8C%I\>0&O.?)'XF7ORXK!7\D;*'"]NK=8RC=C-PMWST2R&ZQ M%,'^5^*I%%424S7Q<^-V^3>0)[RB?I)V1^[T)9WX0#'PS/FB2O'RP;%E?SF& MY*DM[O90$G"(U5^S]O/>V2;-;;E*3JZN6P:>>I1T(MT[B-M(+74I\2V+DI04 MGIZ'1)\[W])+ECUOJG?[A@ZV=T73A4T^5>B3S/0*9JI/`ILJ1N(+J/2#A5^? M*]LK/D_T,0#NOD-ML?001YF3BZ>5PE6VV)WI[Y#5VN^JH(6E*5&J*A2G_@TF '>\7K!44````` ` end From owner-freebsd-stable@FreeBSD.ORG Thu May 8 14:53:13 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BC30106564A for ; Thu, 8 May 2008 14:53:13 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 1C5378FC0A for ; Thu, 8 May 2008 14:53:13 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id E132617D98; Fri, 9 May 2008 00:53:10 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.20.30.101] (60.218.233.220.exetel.com.au [220.233.218.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 792AE17D94 for ; Fri, 9 May 2008 00:53:03 +1000 (EST) Message-ID: <482313CE.8000805@modulus.org> Date: Fri, 09 May 2008 00:53:02 +1000 From: Andrew Snow User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Dreadful gmirror performance - suggested changes to 'prefer' 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, 08 May 2008 14:53:13 -0000 > I havent looked at the code in detail, but I can't see that it would be too > difficult. What do people think ? If the first drive is always priority=0, then it is going to be stuck at the highest priority, or under your plan, the lower priority. My original idea OTOH (starting the counting at 100) solves the problem with aone-line patch. Call me biased but this is what I prefer :-) - Andrew From owner-freebsd-stable@FreeBSD.ORG Thu May 8 17:40:41 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44C13106566C for ; Thu, 8 May 2008 17:40:41 +0000 (UTC) (envelope-from mi@symbion.zaytman.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id EDE1B8FC26 for ; Thu, 8 May 2008 17:40:40 +0000 (UTC) (envelope-from mi@symbion.zaytman.com) Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 08 May 2008 13:30:32 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.8.6-GA) with ESMTP id JXK89310; Thu, 8 May 2008 13:30:27 -0400 (EDT) Received: from 146-115-44-134.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com (HELO symbion.zaytman.com) ([146.115.44.134]) by smtp01.lnh.mail.rcn.net with ESMTP; 08 May 2008 13:30:24 -0400 Received: from symbion.zaytman.com (localhost.zaytman.com [127.0.0.1]) by symbion.zaytman.com (8.14.2/8.13.8) with ESMTP id m48HUNaH001533 for ; Thu, 8 May 2008 13:30:23 -0400 (EDT) (envelope-from mi@symbion.zaytman.com) Received: (from mi@localhost) by symbion.zaytman.com (8.14.2/8.14.2/Submit) id m48HUNjh001532 for stable@FreeBSD.org; Thu, 8 May 2008 13:30:23 -0400 (EDT) (envelope-from mi) Date: Thu, 8 May 2008 13:30:23 -0400 (EDT) From: Mikhail Teterin Message-Id: <200805081730.m48HUNjh001532@symbion.zaytman.com> To: stable@FreeBSD.org X-Junkmail-Status: score=10/50, host=mr08.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090206.482338B7.002A,ss=1,fgs=0, ip=207.172.4.11, so=2007-10-30 19:00:17, dmn=5.4.3/2008-02-01 X-Junkmail-IWF: false Cc: Subject: panic dd-ing from a USB "disk" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mi@aldan.algebra.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2008 17:40:41 -0000 Hello! I had some troubles mounting the filesystem from: da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 3886MB (7959552 512 byte sectors: 255H 63S/T 495C) and decided to just dd the entire da0 to a file, so that the camera can be disconnected: dd if=/dev/da0 of=/home/mi/da0.dd bs=16384 The dd-ing was proceeding slowly (600Kb/s) and I stopped watching it... The machine paniced about an hour later (at 0:52). The timestamp on /home/mi/da0.dd was 23:45, it was only about 500Mb in size. The stack is below. Would anybody like to look at the complete vmcore dump? The hardware is a quad Opteron with 8Gb RAM. Only 4Gb of these are used, because it runs 7.x/i386 from April 5th (without PAE) -- for the sake of NVidia's card. Please, advise. Thanks! -mi [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". There is no member named pathname. Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /opt/modules/fuse.ko...done. Loaded symbols for /opt/modules/fuse.ko Unread portion of the kernel message buffer: umass0: at uhub0 port 6 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc0449702 stack pointer = 0x28:0xeb74b8bc frame pointer = 0x28:0xeb74b8dc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13989 (dd) trap number = 12 panic: page fault cpuid = 3 Uptime: 12d10h52m16s (da0:dead_sim0:0:0:0): Synchronize cache failed, status == 0x34, scsi status == 0xc8 Physical memory: 3054 MB Dumping 334 MB: (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) #0 doadump () at pcpu.h:195 #1 0xc0599f7b in boot (howto=260) at /ibm/src/sys/kern/kern_shutdown.c:418 #2 0xc059a449 in panic (fmt=0x104
) at /ibm/src/sys/kern/kern_shutdown.c:572 #3 0xc077f60d in trap_fatal (frame=0xeb74b87c, eva=40) at /ibm/src/sys/i386/i386/trap.c:899 #4 0xc077f9aa in trap_pfault (frame=0xeb74b87c, usermode=0, eva=0) at /ibm/src/sys/i386/i386/trap.c:812 #5 0xc078035c in trap (frame=0xeb74b87c) at /ibm/src/sys/i386/i386/trap.c:490 #6 0xc076637b in calltrap () at /ibm/src/sys/i386/i386/exception.s:139 #7 0xc0449702 in xpt_done (done_ccb=0xc690a000) at /ibm/src/sys/cam/cam_xpt.c:4856 #8 0xc044b15c in xpt_action (start_ccb=0xc690a000) at /ibm/src/sys/cam/cam_xpt.c:3057 #9 0xc04462b6 in cam_periph_runccb (ccb=0xc690a000, error_routine=0, camflags=CAM_FLAG_NONE, sense_flags=1, ds=0xc6aea690) at /ibm/src/sys/cam/cam_periph.c:878 #10 0xc0453aa1 in daclose (dp=0xcc862600) at /ibm/src/sys/cam/scsi/scsi_da.c:714 #11 0xc0549b2e in g_disk_access (pp=0xc7e12680, r=0, w=0, e=Variable "e" is not available.) at /ibm/src/sys/geom/geom_disk.c:152 #12 0xc054ec4d in g_access (cp=0xc8a90380, dcr=-1, dcw=0, dce=0) at /ibm/src/sys/geom/geom_subr.c:748 #13 0xc05490f3 in g_dev_close (dev=0xca1dad00, flags=Variable "flags" is not available.) at /ibm/src/sys/geom/geom_dev.c:217 #14 0xc0531f69 in devfs_close (ap=0xeb74ba94) at /ibm/src/sys/fs/devfs/devfs_vnops.c:372 #15 0xc0623e86 in vn_close (vp=0xcc8c1dd0, flags=1, file_cred=0xca36e700, td=0xc8552000) at vnode_if.h:228 #16 0xc0623f37 in vn_closefile (fp=0xca19bdc8, td=0xc8552000) at /ibm/src/sys/kern/vfs_vnops.c:868 #17 0xc0568b14 in fdrop (fp=0xca19bdc8, td=0xc8552000) at file.h:297 #18 0xc056a3c2 in closef (fp=0xca19bdc8, td=0xc8552000) at /ibm/src/sys/kern/kern_descrip.c:1958 #19 0xc056b371 in fdfree (td=0xc8552000) at /ibm/src/sys/kern/kern_descrip.c:1668 #20 0xc05775fa in exit1 (td=0xc8552000, rv=256) at /ibm/src/sys/kern/kern_exit.c:272 #21 0xc0578e1d in sys_exit (td=Could not find the frame base for "sys_exit". ) at /ibm/src/sys/kern/kern_exit.c:98 #22 0xc077fb90 in syscall (frame=0xeb74bd38) at /ibm/src/sys/i386/i386/trap.c:1035 #23 0xc07663e0 in Xint0x80_syscall () at /ibm/src/sys/i386/i386/exception.s:196 #24 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) From owner-freebsd-stable@FreeBSD.ORG Thu May 8 20:59:11 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78284106566B; Thu, 8 May 2008 20:59:11 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 099308FC18; Thu, 8 May 2008 20:59:11 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id DDCA828448; Fri, 9 May 2008 04:59:09 +0800 (CST) Received: from localhost (tarsier.geekcn.org [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 9E020EBBA24; Fri, 9 May 2008 04:59:09 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id 8q--E2qq0iPX; Fri, 9 May 2008 04:59:04 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 8354AEBB956; Fri, 9 May 2008 04:59:03 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=WbHAX7mxieGUWi8nacgUDrEtOELQUW2npob+cRbyc1dt1kDMz+UT3Ba5Vx0Scmc9l DkM/9wqaCPnjbPblb/4Ug== Message-ID: <48236995.4060707@delphij.net> Date: Thu, 08 May 2008 13:59:01 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Randy Schultz References: <200805071621.m47GLbCD018315@www.freebsd.org> <48221188.3020708@wenks.ch> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Fabian Wenk , FreeBSD Stable , freebsd-amd64@freebsd.org Subject: Re: amd64/123495: 7.0 AMD64 doesn't install on a Dell SC1435 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2008 20:59:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Randy, Randy Schultz wrote: | On Wed, 7 May 2008, Fabian Wenk spaketh thusly: | | -}Hello Randy | -} | -}On 07.05.08 18:21, Randy Schultz wrote: | -}> FBSD 6.x AMD64 works great on this system, as does centos linux. | -}> When I try to install 7.0 (AMD64 of course), on boot (off the | -}> cdrom) I notice: | -}> ad4: DMA limited to UDMA33, device found non-ATA66 cable | -}> | -}> Not sure if that is an important clue but it seems to be. I | -}> know my cables are SATA-II, FWIW. | -} | -}Somewhere in the BIOS settings should be an option to switch the SATA disks to | -}AHCI, maybe this helps. | -} | -}On most BIOS this setting is in the P-ATA mode, which is a slower | -}compatibility mode and is needed for the Redmond OS to work. | | Hey Fabian, | | Tnx for the tip. Unfortunately there is no such setting on this system. My | choices are "OFF" or "AUTO". In auto mode they appear to be correctly | identified, giving the make and model #. Could you please show your 'pciconf -lv | grep -A3 ata' output? My 1435 says: atapci1@pci0:2:1: class=0x01018a card=0x01eb1028 chip=0x02141166 rev=0x00 hdr=0x00 ~ vendor = 'ServerWorks (Was: Reliance Computer Corp)' ~ class = mass storage ~ subclass = ATA - -- atapci0@pci3:14:0: class=0x01018f card=0x01eb1028 chip=0x024b1166 rev=0x00 hdr=0x00 ~ vendor = 'ServerWorks (Was: Reliance Computer Corp)' ~ class = mass storage ~ subclass = ATA But it's an SC1435 with SAS disks I believe, so things may different. Also, will it be possible if you find some output from vmstat -i? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkgjaZUACgkQi+vbBBjt66CfogCfQvmKaLUmzw/ua4YMjRZlrCOj 2+MAoJbt2l3vRlhRY2qPU+WA7F6qcGZ3 =oEqd -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu May 8 22:31:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB9121065684 for ; Thu, 8 May 2008 22:31:18 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8EDD48FC12 for ; Thu, 8 May 2008 22:31:17 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JuEdw-0006Kj-JP for freebsd-stable@freebsd.org; Thu, 08 May 2008 22:31:16 +0000 Received: from 92.50.96.215 ([92.50.96.215]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 May 2008 22:31:16 +0000 Received: from saper by 92.50.96.215 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 May 2008 22:31:16 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Marcin Cieslak Date: Fri, 09 May 2008 00:31:03 +0200 Lines: 2151 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig5FBD88E35EF57C5DF23545E0" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 92.50.96.215 User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.13) Gecko/20080405 SeaMonkey/1.1.9 Mnenhy/0.7.5.0 X-Enigmail-Version: 0.95.6 Sender: news Subject: Toshiba PMCIA floppy fdc0: does not respond on pcmcia(4) with 7.0-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2008 22:31:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5FBD88E35EF57C5DF23545E0 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I have tried to plug a Toshiba PCMCIA floppy drive (PA2612U) on to the=20 7.0-STABLE and I got "fdc0: does not respond": ACPI set debug layer 'ACPI_HARDWARE' level 'ACPI_LV_ALL_EXCEPTIONS' Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #5: Thu May 8 23:14:51 CEST 2008 saper@radziecki.saper.info:/usr/obj/usr/src/sys/VAIO Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz (1833.48-MHz=20 K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x6f2 Stepping =3D 2 =20 Features=3D0xbfebfbff Features2=3D0xe3bd AMD Features=3D0x20100800 AMD Features2=3D0x1 Cores per package: 2 usable memory =3D 2122555392 (2024 MB) avail memory =3D 2046763008 (1951 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413= ) acpi0: on motherboard hwacpi-0182 [05] HwSetMode : Attempting to enable ACPI mod= e hwacpi-0218 [05] HwSetMode : Mode 1 successfully enabled acpi0: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on=20 acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem=20 0xf8300000-0xf837ffff,0xd0000000-0xdfffffff,0xf8400000-0xf843ffff irq 16 = at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M acpi_video0: on vgapci0 vgapci1: mem 0xf8380000-0xf83fffff at device=20 2.1 on pci0 pcm0: mem=20 0xf8440000-0xf8443fff irq 21 at device 27.0 on pci0 pcm0: [ITHREAD] pcib1: irq 16 at device 28.0 on pci0 pci2: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci6: on pcib2 wpi0: mem 0xf8100000-0xf8100fff irq 17=20 at device 0.0 on pci6 wpi0: Ethernet address: 00:1b:77:bc:a5:44 wpi0: [ITHREAD] pcib3: irq 18 at device 28.2 on pci0 pci7: on pcib3 mskc0: port 0x3000-0x30ff mem=20 0xf8000000-0xf8003fff irq 18 at device 0.0 on pci7 msk0: on mskc0 msk0: Ethernet address: 00:1a:80:55:25:5e miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto mskc0: [FILTER] pcib4: irq 19 at device 28.3 on pci0 pci8: on pcib4 uhci0: port 0x1820-0x183f irq 19 at=20 device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] uhci0: LegSup =3D 0x003b usb0: on uhci0 usb0: USB revision 1.0 usbd_get_string: getting lang failed, using 0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 19 at=20 device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] uhci1: LegSup =3D 0x0010 usb1: on uhci1 usb1: USB revision 1.0 usbd_get_string: getting lang failed, using 0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 19 at=20 device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] uhci2: LegSup =3D 0x0010 usb2: on uhci2 usb2: USB revision 1.0 usbd_get_string: getting lang failed, using 0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1880-0x189f irq 19 at=20 device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] uhci3: LegSup =3D 0x0010 usb3: on uhci3 usb3: USB revision 1.0 usbd_get_string: getting lang failed, using 0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem=20 0xf8644000-0xf86443ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered uhub5: on uhub4 uhub5: single transaction translator uhub5: 4 ports with 0 removable, self powered ehci_activate_qh: unexpected next ptr QH(0xffffffffd6679f00) at 0x034f9f00: sqtd=3D0xffffffffd667ae00 inactivesqtd=3D0xffffffffd667af80 link=3D0x034ed282 endp=3D0x80012102 addr=3D0x02 inact=3D0 endpt=3D1 eps=3D2 dtc=3D0 hrecl=3D0 mpl=3D0x1 ctl=3D0 nrl=3D8 endphub=3D0x41811c01 smask=3D0x01 cmask=3D0x1c huba=3D0x01 port=3D3 mult=3D1 curqtd=3D0x00000001 Overlay qTD: next=3D0x034faf80<> altnext=3D0x00000001 status=3D0x00000000: toggle=3D0 bytes=3D0x0 ioc=3D0 c_page=3D0x0 cerr=3D0 pid=3D0 stat=3D0x0 buffer[0]=3D0x00000000 buffer[1]=3D0x00000000 buffer[2]=3D0x00000000 buffer[3]=3D0x00000000 buffer[4]=3D0x00000000 QTD(0xffffffffd667ae00) at 0x034fae00: next=3D0x034faf80<> altnext=3D0x034faf80<> status=3D0x00018d00: toggle=3D0 bytes=3D0x1 ioc=3D1 c_page=3D0x0 cerr=3D3 pid=3D1 stat=3D0x0 buffer[0]=3D0x0350b418 buffer[1]=3D0x00000000 buffer[2]=3D0x00000000 buffer[3]=3D0x00000000 buffer[4]=3D0x00000000 QTD(0xffffffffd667af80) at 0x034faf80: next=3D0x00000001 altnext=3D0x00000001 status=3D0x00000000: toggle=3D0 bytes=3D0x0 ioc=3D0 c_page=3D0x0 cerr=3D0 pid=3D0 stat=3D0x0 buffer[0]=3D0x00000000 buffer[1]=3D0x00000000 buffer[2]=3D0x00000000 buffer[3]=3D0x00000000 buffer[4]=3D0x00000000 ucardman0: on uhub5 ucardman attach: sc =3D 0xffffff0003538000 umass0: =20 on uhub5 umass0: SCSI over Bulk-Only; quirks =3D 0x0000 umass0:0:0:-1: Attached to scbus0 uscanner0: on uhub5 umass1: on uhub4 umass1: SCSI over Bulk-Only; quirks =3D 0x0000 umass1:1:1:-1: Attached to scbus1 ugen0: on uhub4 pcib5: at device 30.0 on pci0 pci9: on pcib5 cbb0: at device 4.0 on pci9 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] fwohci0: <1394 Open Host Controller Interface> mem=20 0xf8205000-0xf82057ff,0xf8200000-0xf8203fff irq 21 at device 4.1 on pci9 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 08:00:46:03:02:91:b4:4d fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x7b7e8000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 0a:00:46:91:b4:4d fwe0: Ethernet address: 0a:00:46:91:b4:4d fwip0: on firewire0 fwip0: Firewire address: 08:00:46:03:02:91:b4:4d @ 0xfffe00000000, S400, = maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=3D0xc000ffc0, gen=3D1, CYCLEMASTER mode pci9: at device 4.2 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port=20 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port=20 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf=20 mem 0xf8644400-0xf86447ff irq 22 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: port not implemented ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: port not implemented ata5: [ITHREAD] ichsmb0: port 0x18e0-0x18ff at=20 device 31.3 on pci0 ichsmb0: can't get IRQ device_attach: ichsmb0 attach returned 6 acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_tz2: on acpi0 acpi_sony0: on acpi0 acpi_sony0: PID 0 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 battery0: on acpi0 acpi_acad0: on acpi0 orm0: at iomem 0xc0000-0xcffff,0xdc000-0xdffff 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: cannot reserve I/O port range sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ums0: on uhub0 ums0: 8 buttons and Z dir. ubt0: on uhub3 ubt0: Interface 0 endpoints: interrupt=3D0x81, bulk-in=3D0x82, bulk-out=3D= 0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=3D0x83, isoc-out=3D0x= 3;=20 wMaxPacketSize=3D49; nframes=3D6, buffer size=3D294 WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) ZFS filesystem version 6 ZFS storage pool version 6 acd0: DVDR at ata0-master UDMA33 ad4: 114473MB at ata2-master SATA150 CIS is too long -- truncating pccard0: Allocation failed for cfe 1 pccard0: Allocation failed for cfe 2 pccard0: Allocation failed for cfe 3 pccard0: (manufacturer=3D0xffffffff, product=3D0xffffffff,= =20 function_type=3D-1) at function 0 pccard0: CIS info: Y-E DATA, External FDD, Controller, 2.00 pcm0: pcm0: GEOM_LABEL: Label for provider acd0 is iso9660/DoerteKopie. GEOM_LABEL: Label for provider ad4s1 is ntfs/Recovery. acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 SMP: AP CPU #1 Launched! cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [1085232 x 2048 byte records] da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da4 at umass-sim1 bus 1 target 0 lun 0 da4: Removable Direct Access SCSI-0 device da4: 40.000MB/s transfers da4: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim0 bus 0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da2 at umass-sim0 bus 0 target 0 lun 2 da2: Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim0 bus 0 target 0 lun 3 da3: Removable Direct Access SCSI-0 device da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from zfs:tank can't evaluate \\_SB_.PCI0.GFX0.LCD_._DCS - AE_NOT_FOUND can't evaluate \\_SB_.PCI0.GFX0.LCD_._DCS - AE_NOT_FOUND wpi0: timeout resetting Tx ring 1 wpi0: timeout resetting Tx ring 3 wpi0: timeout resetting Tx ring 4 WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() WARNING: attempt to net_add_domain(netgraph) after domainfinalize() ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based=20 forwarding disabled, default to deny, logging disabled can't evaluate \\_SB_.PCI0.GFX0.LCD_._DCS - AE_NOT_FOUND sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled can't evaluate \\_SB_.PCI0.GFX0.LCD_._DCS - AE_NOT_FOUND can't evaluate \\_SB_.PCI0.GFX0.LCD_._DCS - AE_NOT_FOUND Status is 0x30000510 cbb0: card inserted: event=3D0x00000000, state=3D30000510 pccard0: chip_socket_enable cbb_pcic_socket_enable: cbb0: cbb_power: 5V pccard0: read_cis cis mem map 0xd9deb000 (resource: 0xf8210000) pccard0: CIS tuple chain: CISTPL_DEVICE type=3Dfuncspec speed=3D100ns 01 02 dc ff CISTPL_VERS_1 15 29 04 01 59 2d 45 20 44 41 54 41 00 45 78 74 65 72 6e 61 6c 20 46 44 44 00 43 6f 6e 74 72 6f 6c 6c 65 72 00 32 2e 30 30 00 ff unhandled CISTPL 14 CISTPL_NO_LINK 14 00 CISTPL_CONFIG 1a 06 01 22 f0 07 0f ff CISTPL_CFTABLE_ENTRY 1b 11 c1 51 19 11 55 4d 5d 06 06 06 a0 20 07 30 ff ff ff CISTPL_CFTABLE_ENTRY 1b 08 02 08 aa 60 c8 03 07 ff CISTPL_CFTABLE_ENTRY 1b 08 03 08 aa 60 c0 03 07 ff CISTPL_CFTABLE_ENTRY 1b 08 04 08 aa 60 a8 03 07 ff CISTPL_CFTABLE_ENTRY 1b 08 05 08 aa 60 a0 03 07 ff CISTPL_CFTABLE_ENTRY 1b 08 06 08 aa 60 88 03 07 ff CISTPL_CFTABLE_ENTRY 1b 08 07 08 aa 60 80 03 07 ff CISTPL_CFTABLE_ENTRY 1b 08 08 08 aa 60 68 03 07 ff unhandled CISTPL 4c 4c 1b 08 09 08 aa 60 60 03 07 ff 1b 08 0a 08 aa 60 48 03 07 ff 1b 08 0b 08 aa 60 40 03 unhandled CISTPL 7 07 ff 1b 08 0c 08 aa 60 28 03 07 ff 1b 08 0d 08 aa 60 20 03 07 ff 1b 08 0e 08 aa 60 08 03 07 ff 1b 08 0f 08 aa 60 00 03 07 ff 1b 08 10 08 aa 60 e8 02 07 ff 1b 08 11 08 aa 60 e0 02 07 ff 1b 08 12 08 aa 60 c8 02 07 ff 1b 08 13 08 aa 60 c0 02 07 ff 1b 08 14 08 aa 60 a8 02 07 ff 1b 08 15 08 aa 60 a0 02 07 ff 1b 08 16 08 aa 60 88 02 07 ff 1b 08 17 08 aa 60 80 02 07 ff 1b 08 18 08 aa 60 68 02 07 ff 1b 08 19 08 aa 60 60 02 07 ff 1b 08 1a 08 aa 60 48 02 07 ff 1b 08 1b 08 aa 60 40 02 07 ff 1b 08 1c 08 aa 60 28 02 07 ff 1b 08 1d 08 aa 60 20 02 07 ff 1b 08 1e 08 aa 60 08 02 07 ff 1b 08 1f 08 aa 60 00 02 07 ff 1b 13 61 18 aa 60 f8 03 07 26 ff 48 4f 53 54 5f 44 4d 41 00 ff 1b 12 22 08 aa 60 70 03 07 ff 48 4f 53 54 5f 44 4d 41 00 ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 CISTPL_NONE 00 unhandled CISTPL 0 TOO MANY CIS_NONE unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 40 40 20 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 unhandled CISTPL 0 CIS is too long -- truncating CISTPL_END ff pccard0: check_cis_quirks pccard0: CIS version PCCARD 2.0 or 2.1 pccard0: CIS info: Y-E DATA, External FDD, Controller, 2.00 pccard0: Manufacturer code 0xffffffff, product 0xffffffff pccard0: function 0: unspecified, ccr addr 7f0 mask f pccard0: function 0, config table entry 1: I/O card; irq mask 40; iomask = 1d, iospace 0-1fffffff; rdybsy_active bvd_active io16 pccard0: function 0, config table entry 2: I/O card; irq mask 40; iomask = a, iospace 3c8-3cf; rdybsy_active bvd_active io8 pccard0: function 0, config table entry 3: I/O card; irq mask 40; iomask = a, iospace 3c0-3c7; rdybsy_active bvd_active io8 pccard0: function 0, config table entry 4: I/O card; irq mask 40; iomask = a, iospace 3a8-3af; rdybsy_active bvd_active io8 pccard0: function 0, config table entry 5: I/O card; irq mask 40; iomask = a, iospace 3a0-3a7; rdybsy_active bvd_active io8 pccard0: function 0, config table entry 6: I/O card; irq mask 40; iomask = a, iospace 388-38f; rdybsy_active bvd_active io8 pccard0: function 0, config table entry 7: I/O card; irq mask 40; iomask = a, iospace 380-387; rdybsy_active bvd_active io8 pccard0: function 0, config table entry 8: I/O card; irq mask 40; iomask = a, iospace 368-36f; rdybsy_active bvd_active io8 pccard0: functions scanning pccard0: Card has 1 functions. pccard_mfc is 0 pccard0: I/O rid 0 start 0 end ffffffffffffffff pccard0: Allocation failed for cfe 1 pccard0: I/O rid 0 start 3c8 end 3cf pccard0: Allocation failed for cfe 2 pccard0: I/O rid 0 start 3c0 end 3c7 pccard0: Allocation failed for cfe 3 pccard0: I/O rid 0 start 3a8 end 3af cbb_pcic_socket_enable: pccard0: ccr_res =3D=3D f8207000-f82073ff, base=3D7f0 pccard0: function 0 CCR at 0 offset 7f0: 44 20 e 0, 0 0 0 0, 0 fdc0: at port 0x3a8-0x3af irq 20 function 0 config 4 on = pccard0 fdc0: does not respond device_attach: fdc0 attach returned 6 file revisions: fdc.c: $FreeBSD: src/sys/dev/fdc/fdc.c,v 1.317.2.1 2008/01/18 09:39:35=20 kib Exp $ fdc_acpi.c: $FreeBSD: src/sys/dev/fdc/fdc_acpi.c,v 1.12 2006/02/21 03:19:24=20 njl Exp $ fdc_isa.c: $FreeBSD: src/sys/dev/fdc/fdc_isa.c,v 1.22 2005/03/15 08:02:47 imp = Exp $ fdc_pccard.c: $FreeBSD: src/sys/dev/fdc/fdc_pccard.c,v 1.13 2005/06/24 14:36:52=20 imp Exp $ fdcvar.h: $FreeBSD: src/sys/dev/fdc/fdcvar.h,v 1.9 2005/01/19 07:46:38 imp Ex= p $ card_if.m: $FreeBSD: src/sys/dev/pccard/card_if.m,v 1.31 2005/09/25 01:39:04=20 imp Exp $ pccard.c: $NetBSD: pcmcia.c,v 1.23 2000/07/28 19:17:02 drochner Exp $ $FreeBSD: src/sys/dev/pccard/pccard.c,v 1.119 2007/06/16 23:33:57=20 imp Exp $ pccard_cis.c: $NetBSD: pcmcia_cis.c,v 1.17 2000/02/10 09:01:52 chopps Exp $ $FreeBSD: src/sys/dev/pccard/pccard_cis.c,v 1.40 2007/02/27=20 17:23:28 jhb Exp $ pccard_cis.h: $FreeBSD: src/sys/dev/pccard/pccard_cis.h,v 1.4 2005/07/13=20 14:59:06 imp Exp $ pccard_cis_quirks.c: $NetBSD: pcmcia_cis_quirks.c,v 1.6 2000/04/12 21:07:55 scw Exp $ $FreeBSD: src/sys/dev/pccard/pccard_cis_quirks.c,v 1.16.2.1=20 2007/10/30 10:17:11 remko Exp $ pccard_device.c: $FreeBSD: src/sys/dev/pccard/pccard_device.c,v 1.3 2005/09/21=20 20:08:24 imp Exp $ pccarddevs: $FreeBSD: src/sys/dev/pccard/pccarddevs,v 1.129.2.1 2007/10/30=20 10:17:11 remko Exp $ $NetBSD: pcmciadevs,v 1.186 2003/09/16 08:26:37 onoe Exp $ $OpenBSD: pcmciadevs,v 1.93 2002/06/21 08:31:10 henning Exp $ pccardreg.h: $NetBSD: pcmciareg.h,v 1.7 1998/10/29 09:45:52 enami Exp $ $FreeBSD: src/sys/dev/pccard/pccardreg.h,v 1.3 2005/01/06 01:43:03 = imp Exp $ pccardvar.h: $NetBSD: pcmciavar.h,v 1.12 2000/02/08 12:51:31 enami Exp $ $FreeBSD: src/sys/dev/pccard/pccardvar.h,v 1.61 2005/09/25=20 01:38:02 imp Exp $ pccardvarp.h: $FreeBSD: src/sys/dev/pccard/pccardvarp.h,v 1.4 2007/05/31=20 19:29:20 piso Exp $ power_if.m: $FreeBSD: src/sys/dev/pccard/power_if.m,v 1.4 2005/01/06 01:43:03=20 imp Exp $ Any hints? --Marcin --------------enig5FBD88E35EF57C5DF23545E0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQCVAwUBSCN/Kz2W2v2wY27ZAQMg+QQAnj3zp3O50mmi8H5d+KaDuc8yOfLVA4pP kL/4MFziHPUsGip8xRzaEMnFG4jQwhZPFR57gPnOjJjMwjyx7wdnl0fpZnl3OogW 4k8wGpxrg0YKXqhtGGrmeviC1aVNZ4GDntsV7FCRRjz+7ypgtSmW7nv63EEjLAmz hnxgihC8K8c= =4xJv -----END PGP SIGNATURE----- --------------enig5FBD88E35EF57C5DF23545E0-- From owner-freebsd-stable@FreeBSD.ORG Fri May 9 03:34:26 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 857F910656EE for ; Fri, 9 May 2008 03:34:18 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from mail27.sea5.speakeasy.net (mail27.sea5.speakeasy.net [69.17.117.31]) by mx1.freebsd.org (Postfix) with ESMTP id 4B5D48FC19 for ; Fri, 9 May 2008 03:34:18 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: (qmail 17492 invoked from network); 9 May 2008 03:07:37 -0000 Received: from mxperim3.sea5.speakeasy.net ([69.17.117.68]) (envelope-sender ) by mail27.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 9 May 2008 03:07:37 -0000 Received: from localhost (localhost [127.0.0.1]) by mxperim3.sea5.speakeasy.net (Postfix) with ESMTP id 221D643C8C for ; Thu, 8 May 2008 20:07:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mxperim3.sea5.speakeasy.net Received: from mxperim3.sea5.speakeasy.net ([127.0.0.1]) by localhost (mxperim3.sea5.speakeasy.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xTNjAcO+eei for ; Thu, 8 May 2008 20:07:37 -0700 (PDT) Received: from w16.stradamotorsports.com (dsl081-163-042.sea1.dsl.speakeasy.net [64.81.163.42]) by mxperim3.sea5.speakeasy.net (Postfix) with ESMTP for ; Thu, 8 May 2008 20:07:37 -0700 (PDT) Message-ID: <4823BFF7.6060106@highperformance.net> Date: Thu, 08 May 2008 20:07:35 -0700 From: "Jason C. Wells" User-Agent: Thunderbird 2.0.0.4pre (X11/20080205) MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Release Schedule 7.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: Fri, 09 May 2008 03:34:28 -0000 What are the hoped for release dates for 7.1? (plus or minus a month) I'm debating on running 7.0 vs 7.1 and timing is a consideration. Regards, Jason From owner-freebsd-stable@FreeBSD.ORG Fri May 9 06:07:28 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 638951065674 for ; Fri, 9 May 2008 06:07:28 +0000 (UTC) (envelope-from paul.koch@statseeker.com) Received: from wally.statseeker.com (wally.statseeker.com [203.39.101.146]) by mx1.freebsd.org (Postfix) with ESMTP id E85258FC1C for ; Fri, 9 May 2008 06:07:27 +0000 (UTC) (envelope-from paul.koch@statseeker.com) Received: from localhost (localhost [127.0.0.1]) by wally.statseeker.com (8.14.2/8.14.2) with ESMTP id m4967QSk078751; Fri, 9 May 2008 16:07:26 +1000 (EST) (envelope-from paul.koch@statseeker.com) X-Virus-Scanned: amavisd-new at statseeker.com Received: from wally.statseeker.com ([127.0.0.1]) by localhost (wally.statseeker.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3HuHg+2zcdNv; Fri, 9 May 2008 16:07:21 +1000 (EST) Received: from speedy.statseeker.com (speedy.statseeker.com [10.1.1.100]) (authenticated bits=0) by wally.statseeker.com (8.14.2/8.14.2) with ESMTP id m4967EaB078747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 May 2008 16:07:16 +1000 (EST) (envelope-from paul.koch@statseeker.com) From: Paul Koch To: Doug Rabson Date: Fri, 9 May 2008 16:07:22 +1000 User-Agent: KMail/1.9.7 References: <200805081812.24692.paul.koch@statseeker.com> <1B6FCF23-413B-452A-B66D-3CCD6257F7BD@rabson.org> In-Reply-To: <1B6FCF23-413B-452A-B66D-3CCD6257F7BD@rabson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805091607.23035.paul.koch@statseeker.com> Cc: freebsd-stable@freebsd.org Subject: Re: flock incorrectly detects deadlock on 7-stable and current X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: paul.koch@statseeker.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2008 06:07:28 -0000 On Thu, 8 May 2008 06:37:00 pm Doug Rabson wrote: > On 8 May 2008, at 09:12, Paul Koch wrote: > > Hi, > > > > We have been trying to track down a problem with one of our apps > > which does a lot of flock(2) calls. flock returns errno 11 > > (Resource deadlock avoided) under certain scenarios. Our app works > > fine on 7-Release, but fails on 7-stable and -current. > > > > The problem appears to be when we have at least three processes > > doing flock() on a file, and one is trying to upgrade a shared lock > > to an exclusive lock but fails with a deadlock avoided. > > > > Attached is a simple flock() test program. > > > > a. Process 1 requests and gets a shared lock > > b. Process 2 requests and blocks for an exclusive lock > > c. Process 3 requests and gets a shared lock > > d. Process 3 requests an upgrade to an exclusive lock but fails > > (errno 11) > > > > If we change 'd' to > > Process 3 requests unlock, then requests exclusive lock, it > > works. > > Could you possibly try this patch and tell me if it helps: > > ==== //depot/user/dfr/lockd/sys/kern/kern_lockf.c#57 - > /tank/projects/ lockd/src/sys/kern/kern_lockf.c ==== > @@ -1370,6 +1370,18 @@ > } > > /* > + * For flock type locks, we must first remove > + * any shared locks that we hold before we sleep > + * waiting for an exclusive lock. > + */ > + if ((lock->lf_flags & F_FLOCK) && > + lock->lf_type == F_WRLCK) { > + lock->lf_type = F_UNLCK; > + lf_activate_lock(state, lock); > + lock->lf_type = F_WRLCK; > + } > + > + /* > * We are blocked. Create edges to each blocking lock, > * checking for deadlock using the owner graph. For > * simplicity, we run deadlock detection for all > @@ -1389,17 +1401,6 @@ > } > > /* > - * For flock type locks, we must first remove > - * any shared locks that we hold before we sleep > - * waiting for an exclusive lock. > - */ > - if ((lock->lf_flags & F_FLOCK) && > - lock->lf_type == F_WRLCK) { > - lock->lf_type = F_UNLCK; > - lf_activate_lock(state, lock); > - lock->lf_type = F_WRLCK; > - } > - /* > * We have added edges to everything that blocks > * us. Sleep until they all go away. > */ Manually applied the patch to stable kern_lockf.c 1.57.2.1. Ran the flock_test program on many of our architectures and it works fine. Have also been testing our app on a single core i386 machine today with no locking problems. Just setup a quad core -stable amd64 build and it also appears to be running fine now. Thanks Paul. From owner-freebsd-stable@FreeBSD.ORG Fri May 9 08:50:31 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E06C1065675 for ; Fri, 9 May 2008 08:50:31 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id 3BA368FC16 for ; Fri, 9 May 2008 08:50:31 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc] (unknown [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id 938ED3F8F; Fri, 9 May 2008 09:50:29 +0100 (BST) Message-Id: <62B7297F-8795-456F-8611-40658DF327FB@rabson.org> From: Doug Rabson To: paul.koch@statseeker.com In-Reply-To: <200805091607.23035.paul.koch@statseeker.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 9 May 2008 09:50:28 +0100 References: <200805081812.24692.paul.koch@statseeker.com> <1B6FCF23-413B-452A-B66D-3CCD6257F7BD@rabson.org> <200805091607.23035.paul.koch@statseeker.com> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-stable@freebsd.org Subject: Re: flock incorrectly detects deadlock on 7-stable and current 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, 09 May 2008 08:50:31 -0000 On 9 May 2008, at 07:07, Paul Koch wrote: > On Thu, 8 May 2008 06:37:00 pm Doug Rabson wrote: >> >> >> Could you possibly try this patch and tell me if it helps: >> ... >> > Manually applied the patch to stable kern_lockf.c 1.57.2.1. Ran the > flock_test program on many of our architectures and it works fine. > > Have also been testing our app on a single core i386 machine today > with > no locking problems. Just setup a quad core -stable amd64 build and > it > also appears to be running fine now. Thanks for that. I'll get the patch committed to current today - it will turn up in 7-stable in a couple of days. From owner-freebsd-stable@FreeBSD.ORG Fri May 9 08:56:51 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF9E4106566C for ; Fri, 9 May 2008 08:56:51 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 486EE8FC0C for ; Fri, 9 May 2008 08:56:45 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by ug-out-1314.google.com with SMTP id q2so312476uge.37 for ; Fri, 09 May 2008 01:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; bh=AQeUERTOSeNci0mB+KN9CRL/uBiS/G9ovTmHXoogtc4=; b=qOvgzTYxgSwHp3rGE7VkJdp6TvDXW+M1sEDQgTiKnDP4ASPSOY4U6WCF+qnEVXhSbwnf7T9ikGAa8QSevHAsSllqGbpW0Tlc5A/X2qJUfB8RM2fCfzkHy26M1h0Uz/HHa4MhJjXWFO2C+uZ68Pk7QIgXr26Tc6bOszz++jZuiqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; b=LaKd208OiHIRkZPsLAarj+88WFk5XcvvdeqD/mXoOWj0oD1+GUXoUl1LitrWKyKPRV+AWnfKA82fOUBgDX8VrS8cmnCGamDF4NgkVglT6bECTYsPhwtdVCFa7t2Bx2JkSM9VZwveuwF40QUpiybkDdQF8N8u/gaCoE1dUHWggWA= Received: by 10.67.116.9 with SMTP id t9mr736887ugm.77.1210323404529; Fri, 09 May 2008 01:56:44 -0700 (PDT) Received: from ?127.0.0.1? ( [217.206.187.80]) by mx.google.com with ESMTPS id q9sm8622283gve.5.2008.05.09.01.56.42 (version=SSLv3 cipher=RC4-MD5); Fri, 09 May 2008 01:56:43 -0700 (PDT) From: Tom Evans To: "Jason C. Wells" In-Reply-To: <4823BFF7.6060106@highperformance.net> References: <4823BFF7.6060106@highperformance.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eh5xzxQ/IXjGGj96bvxw" Date: Fri, 09 May 2008 09:56:41 +0100 Message-Id: <1210323401.75986.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Cc: freebsd-stable Subject: Re: Release Schedule 7.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: Fri, 09 May 2008 08:56:51 -0000 --=-eh5xzxQ/IXjGGj96bvxw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-05-08 at 20:07 -0700, Jason C. Wells wrote: > What are the hoped for release dates for 7.1? (plus or minus a month)=20 > I'm debating on running 7.0 vs 7.1 and timing is a consideration. >=20 > Regards, > Jason Scheduled releases are listed on the release engineering page. http://www.freebsd.org/releng/index.html You might notice there aren't any. RELENG_7 / 7-STABLE is as close as you will get to 7.1 for a long while. Tom --=-eh5xzxQ/IXjGGj96bvxw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkgkEcUACgkQlcRvFfyds/erCwCdFDZ/vP+2quqYBVMPCLuVSoFd UAEAni9LUY15PTAtJu6U8fv6v3cUSOxe =23QJ -----END PGP SIGNATURE----- --=-eh5xzxQ/IXjGGj96bvxw-- From owner-freebsd-stable@FreeBSD.ORG Fri May 9 12:45:15 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4295F1065674 for ; Fri, 9 May 2008 12:45:15 +0000 (UTC) (envelope-from schulra@earlham.edu) Received: from sipala.earlham.edu (sipala.earlham.edu [159.28.1.75]) by mx1.freebsd.org (Postfix) with ESMTP id 05C7B8FC16 for ; Fri, 9 May 2008 12:45:14 +0000 (UTC) (envelope-from schulra@earlham.edu) Received: from tdream.lly.earlham.edu (tdream.lly.earlham.edu [159.28.7.241]) by sipala.earlham.edu (8.13.6/8.13.6) with ESMTP id m49CSvlK017693; Fri, 9 May 2008 08:29:07 -0400 (EDT) Received: from tdream.lly.earlham.edu (tdream.lly.earlham.edu [159.28.7.241]) by tdream.lly.earlham.edu (Postfix) with ESMTP id CDB5C8E275; Fri, 9 May 2008 08:29:38 -0400 (EDT) Date: Fri, 9 May 2008 08:29:38 -0400 (EDT) From: Randy Schultz X-X-Sender: schulra@tdream.lly.earlham.edu To: freebsd-amd64@freebsd.org In-Reply-To: <48236995.4060707@delphij.net> Message-ID: References: <200805071621.m47GLbCD018315@www.freebsd.org> <48221188.3020708@wenks.ch> <48236995.4060707@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD Stable Subject: Re: amd64/123495: 7.0 AMD64 doesn't install on a Dell SC1435 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, 09 May 2008 12:45:15 -0000 On Thu, 8 May 2008, Xin LI spaketh thusly: -}Could you please show your 'pciconf -lv | grep -A3 ata' output? -} -}My 1435 says: -} -}atapci1@pci0:2:1: class=0x01018a card=0x01eb1028 chip=0x02141166 -}rev=0x00 hdr=0x00 -}~ vendor = 'ServerWorks (Was: Reliance Computer Corp)' -}~ class = mass storage -}~ subclass = ATA -}- -- -}atapci0@pci3:14:0: class=0x01018f card=0x01eb1028 chip=0x024b1166 -}rev=0x00 hdr=0x00 -}~ vendor = 'ServerWorks (Was: Reliance Computer Corp)' -}~ class = mass storage -}~ subclass = ATA -} -}But it's an SC1435 with SAS disks I believe, so things may different. -}Also, will it be possible if you find some output from vmstat -i? Certainly. The system is up on 6.3 right now so this is simple. ;> Dude ? pciconf -lv | grep -A3 ata atapci1@pci0:2:1: class=0x01018a card=0x01eb1028 chip=0x02141166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'HT1000 Legacy IDE controller' class = mass storage -- atapci0@pci3:14:0: class=0x01018f card=0x01eb1028 chip=0x024b1166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'BCM5785 (HT1000) PATA/IDE Mode' class = mass storage I had the SAS card in it but I needed to pull it because I needed to put a SCSI card in for the autochanger(testing fbsd with bacula). Here's the vmstat output: Dude ? vmstat -i interrupt total rate irq1: atkbd0 18 0 irq6: atapci0 1543 0 irq9: acpi0 2 0 irq11: ohci0 ohci+ 12 0 irq14: ata0 47 0 irq33: bge0 14935 7 irq38: ahc0 138 0 irq39: ahc1 23 0 cpu0: timer 4127540 1998 Total 4144258 2006 I wasn't aware of the pciconf command. It's kinda cool. Now I'm wondering if I can use it to write the proper data to the configuration register telling it to not be in PATA mode. OTOH, the potential to do improper things seems great so this is a bit scary. I wonder if the dell is feeding bogus data to fbsd 7, or fbsd 7 is misinterpreting what it's getting from the dell? -- Randy (schulra@earlham.edu) 765.983.1283 <*> Love with your heart, think with your head; not the other way around. From owner-freebsd-stable@FreeBSD.ORG Sat May 10 02:53:21 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 271A01065672 for ; Sat, 10 May 2008 02:53:21 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 83ECE8FC14 for ; Sat, 10 May 2008 02:53:19 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from delish.ish.com.au ([203.29.62.201] helo=ish.com.au) by fish.ish.com.au with esmtps (SSLv3:DES-CBC3-SHA:168) (Exim 4.43) id 1JufBs-0002FX-6o; Sat, 10 May 2008 12:52:04 +1000 Received: from [10.29.62.13] ([10.29.62.13] verified) by ish.com.au (CommuniGate Pro SMTP 5.2.1) with ESMTP id 3472907; Sat, 10 May 2008 12:53:16 +1000 Message-Id: <0DB3A235-DF87-4413-90ED-E38BC44CA2B3@ish.com.au> From: Aristedes Maniatis To: John Baldwin In-Reply-To: <200804221334.35001.jhb@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 10 May 2008 12:53:15 +1000 References: <77E81AD6-FBCC-4D30-A5CB-A9B918D4793F@ish.com.au> <200804181314.24974.jhb@freebsd.org> <200804221334.35001.jhb@freebsd.org> X-Mailer: Apple Mail (2.919.2) Cc: bzeeb+freebsd+lor@zabbadoz.net, jeff@freebsd.org, Jurgen Weber , freebsd-stable@freebsd.org, davidxu@freebsd.org Subject: Re: LOR on sleepqueue chain locks, Was: LOR sleepq/scrlock X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2008 02:53:21 -0000 On 23/04/2008, at 3:34 AM, John Baldwin wrote: >>> The >>> real problem at the bottom of the screen though is a real issue. >>> It's a LOR >>> of two different sleepqueue chain locks. The problem is that when >>> setrunnable() encounters a swapped out thread it tries to wakeup >>> proc0, but >>> if proc0 is asleep (which is typical) then its thread lock is a >>> sleep queue >>> chain lock, so waking up a swapped out thread from wakeup() will >>> usually >>> trigger this LOR. >>> >>> I think the best fix is to not have setrunnable() kick proc0 >>> directly. >>> Perhaps setrunnable() should return an int and return true if proc0 >>> needs to >>> be awakened and false otherwise. Then the the sleepq code (b/c only >>> sleeping >>> threads can be swapped out anyway) can return that value from >>> sleepq_resume_thread() and can call kick_proc0() directly once it >>> has dropped >>> all of its own locks. >>> >>> -- >>> John Baldwin >> >> The way you describe it, it almost sounds like this LOR should be >> happening for everyone, all the time. To try and eliminate the >> factors >> which trigger it for us, we tried the following: removed PAE from >> kernel, disabled PF. Neither of these things made any difference and >> the error is fairly quickly reproducible (within a couple of hours >> running various things to load the machine). The one thing we did not >> test yet is removing ZFS from the picture. Note also that this box >> ran >> for years and years on FreeBSD 4.x without a hiccup (non PAE, ipfw >> instead of pf and no ZFS of course). > > There are two things. 1) Most people who run witness (that I know > of) don't > run it on spinlocks because of the overhead, so LORs of spin locks > are less > well-reported than LORs of other locks (mutexes, rwlocks, etc.). 2) > You have > to have enough load on the box to swap out active processes to get > into this > situation. Between those I think that is why this is not more widely > reported. Hi John, Thanks for your efforts so far to track this LOR down. I've been keeping an eye on cvs logs, but haven't seen anything which looks like a patch for this. * is this still outstanding? * or will it be addressed soon? * if not, should I create a PR so that it doesn't get forgotten? * in our case, although we can trigger it quickly with some load, the problem occurs (and causes a complete machine lock) even under < 10% load. Not sure if the combination of PAE/ZFS/SCHED ULE exacerbates that in any way compared to a 'standard' build. Thank you Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-stable@FreeBSD.ORG Sat May 10 15:18:52 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0104D106567D for ; Sat, 10 May 2008 15:18:52 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id A84EF8FC15 for ; Sat, 10 May 2008 15:18:51 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id CBFE91B10EF8; Sat, 10 May 2008 17:18:49 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.4 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 36B5A1B10EF1 for ; Sat, 10 May 2008 17:18:47 +0200 (CEST) Message-ID: <4825BCD6.4080001@moneybookers.com> Date: Sat, 10 May 2008 18:18:46 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.14 (X11/20080503) MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on blah.cmotd.com X-Virus-Status: Clean Subject: /usr/bin/ksu and missing suid bit 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, 10 May 2008 15:18:52 -0000 Greetings, What the reason /usr/bin/ksu to be without setuid bit? Are there any security concerns? I'm asking because the only way to get ksu working is adding by hand the suid bit. For example when you install heimdal from ports it activate the setuid bit on $prefix/bin/su. And my second question - is there a option that I can define in src.conf or make.conf, next time when I build/installworld ksu to have setuid bit ? (in manual I found only knobs for disabling kerberos) -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-stable@FreeBSD.ORG Sat May 10 15:45:36 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D7961065672 for ; Sat, 10 May 2008 15:45:36 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 0839C8FC15 for ; Sat, 10 May 2008 15:45:36 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id m4AFUqXJ082978; Sat, 10 May 2008 08:30:52 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id m4AFUqxF082977; Sat, 10 May 2008 08:30:52 -0700 (PDT) (envelope-from david) Date: Sat, 10 May 2008 08:30:52 -0700 From: David Wolfskill To: Stefan Lambrev Message-ID: <20080510153052.GX66703@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , Stefan Lambrev , FreeBSD Stable References: <4825BCD6.4080001@moneybookers.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3a/Z8KDuKqDOIvAo" Content-Disposition: inline In-Reply-To: <4825BCD6.4080001@moneybookers.com> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Stable Subject: Re: /usr/bin/ksu and missing suid bit 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, 10 May 2008 15:45:36 -0000 --3a/Z8KDuKqDOIvAo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 10, 2008 at 06:18:46PM +0300, Stefan Lambrev wrote: > ... > And my second question - is there a option that I can define in src.conf= =20 > or make.conf, next time when I build/installworld > ksu to have setuid bit ? (in manual I found only knobs for disabling=20 > kerberos) Define ENABLE_SUID_K5SU to be true. Ref. the stanza from /usr/share/examples/etc/make.conf: # Kerberos 5 su (k5su) # If you want to use the k5su utility, define this to have it installed # set-user-ID. #ENABLE_SUID_K5SU=3D Peace, david --=20 David H. Wolfskill david@catwhisker.org I submit that "conspiracy" would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --3a/Z8KDuKqDOIvAo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkglv6oACgkQmprOCmdXAD1PAwCfbSiPiRwJBOoiX32A9GFOZaji sjoAnAwJQOxC9jF3+y+rgTNDoeRavvKH =0Qmg -----END PGP SIGNATURE----- --3a/Z8KDuKqDOIvAo--