From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 00:07:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37A66106566B for ; Sun, 6 Sep 2009 00:07:11 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 6C8018FC13 for ; Sun, 6 Sep 2009 00:07:10 +0000 (UTC) Received: (qmail invoked by alias); 06 Sep 2009 00:07:08 -0000 Received: from 85-127-83-116.dynamic.xdsl-line.inode.at (EHLO taxman.pepperland) [85.127.83.116] by mail.gmx.net (mp047) with SMTP; 06 Sep 2009 02:07:08 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX1+paBtJ+3epvBsiNG/DcbkCSSmm7adXfyZ4AeZzSp +iJIE+9u9N4YRc From: Stefan Ehmann To: Bruce Cran Date: Sun, 6 Sep 2009 02:07:06 +0200 User-Agent: KMail/1.12.1 (FreeBSD/8.0-BETA4; KDE/4.3.1; i386; ; ) References: <200909051806.07692.hselasky@c2i.net> <20090905182929.GB2829@hoeg.nl> <20090905200653.000057c8@unknown> In-Reply-To: <20090905200653.000057c8@unknown> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909060207.06700.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Cc: Ed Schouten , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: ukbd: short freeze when activating LEDs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 00:07:11 -0000 On Saturday 05 September 2009 21:06:53 Bruce Cran wrote: > On Sat, 5 Sep 2009 20:29:29 +0200 > > Ed Schouten wrote: > > * Hans Petter Selasky wrote: > > > On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote: > > > > Whenever I press capslock/numlock, the system shortly (< 0.5 ms) > > > > freezes. > > > > > > It might also be because the USB keyboard driver is using Giant, > > > which can be congested. > > > > For half a second? I experience the same issue. I also have the same > > issue with the Syscons VGA driver when switching windows. Some time > > ago I talked about this with some other people and it may be possible > > it has something to do with SMIs. Not sure... > > Half a millisecond or, as reported in another message, 100us :) > I suspect the OP probably did mean 0.5s, a pause which someone can both > see and hear. > Oops. Of course you're right. For some reason I consistently wrote ms instead of seconds. It's a noticable delay for humans :) From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 03:32:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E07BD1065676 for ; Sun, 6 Sep 2009 03:32:17 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 6D2FB8FC0A for ; Sun, 6 Sep 2009 03:32:17 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n863W6ov020539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Sep 2009 05:32:15 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4AA32D35.5090204@omnilan.de> Date: Sun, 06 Sep 2009 05:32:05 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3297F74ACE23C5429887CBDC" Subject: acd timeouts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 03:32:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3297F74ACE23C5429887CBDC Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, trying to rip audio from my - especially for this purpose reactivated -=20 ATAPI CD-rom results in: acd0: WARNING - READ_CD read data overrun 2352>0 acd0: WARNING - READ_CD read data overrun 2352>0 acd0: WARNING - READ_CD read data overrun 2352>0 acd0: MODE_SELECT_BIG trying to write on read buffer acd0: timeout waiting for ATAPI ready acd0: error issuing ATA PACKET command acd0: timeout waiting for ATAPI ready acd0: error issuing ATA PACKET command System is BETA4, ahci.ko loaded, but this doesn't matter on IDE devices, = right? Any hints? Thanks, -Harry --------------enig3297F74ACE23C5429887CBDC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkqjLTYACgkQLDqVQ9VXb8gTdACdHIR0ZrvI2/okWjN7sK/ORCzI 1g4An344HvINgqdrVCAcMrInl0PtCEpp =RcCc -----END PGP SIGNATURE----- --------------enig3297F74ACE23C5429887CBDC-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 04:43:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9F69106566C for ; Sun, 6 Sep 2009 04:43:49 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 66A348FC15 for ; Sun, 6 Sep 2009 04:43:49 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n864hjwV021975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Sep 2009 06:43:48 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4AA33DF9.6070803@omnilan.de> Date: Sun, 06 Sep 2009 06:43:37 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA18CFC4B944009ECB096143A" Subject: Funding ODD support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 04:43:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA18CFC4B944009ECB096143A Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I'm looking for somebody who has time and knowledge to fix ODD support=20 in FreeBSD. I'm willing to sponsor a decent ammount. My problem is that I can't use FreeBSD for any task in which CD or DVD=20 is involved. What I want is read/write support for any ATAPI/S-ATA ODD regarding=20 ISO9660 and audio. Of course I'd love to have UDF support also, but for=20 the beginning I'd be glad if FreeBSD could boot with an inserted audio=20 CD. This has been a problem for more than two years now, and disabling=20 DMA support for ata devices isn't a satisfying solution. So if you think ypu can fix this and make growisofs and cdrtools working = with ATAPI and SATA devices, please contact me. If we have working ODD support in 8.0-release I'll donate 100 extra bucks= =2E Thanks, -Harry --------------enigA18CFC4B944009ECB096143A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkqjPgEACgkQLDqVQ9VXb8i+/wCeJoDk9acf8Tbzjn7rCQvDswys +cUAnj+w9YZhIa2QHL0KTdV1cEIhaHcI =mq+1 -----END PGP SIGNATURE----- --------------enigA18CFC4B944009ECB096143A-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 09:46:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C320B106568B for ; Sun, 6 Sep 2009 09:46:24 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 7AB938FC0C for ; Sun, 6 Sep 2009 09:46:24 +0000 (UTC) Received: from [89.178.150.29] (port=13036 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkEKD-0008yM-UA for freebsd-current@freebsd.org; Sun, 06 Sep 2009 13:46:21 +0400 Message-ID: <4AA384EC.3060003@lissyara.su> Date: Sun, 06 Sep 2009 13:46:20 +0400 From: Alex Keda User-Agent: Thunderbird 2.0.0.22 (X11/20090728) MIME-Version: 1.0 To: freebsd-current Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Subject: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 09:46:24 -0000 hi! I have fatal trap with today (and yesterday) current. Machine boot, I see: Timecounters tick every 1.000 msec then, it freese ~30 seconds and go to kernel debugger - fatal trap 12 stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 10:40:38 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EAD9106568F for ; Sun, 6 Sep 2009 10:40:38 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1CD8FC14 for ; Sun, 6 Sep 2009 10:40:38 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1MkFAi-0005OD-K0; Sun, 06 Sep 2009 13:40:36 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Martin Wilke In-reply-to: <20090611194557.GC98175@bsdcrew.de> References: <20090611194557.GC98175@bsdcrew.de> Comments: In-reply-to Martin Wilke message dated "Thu, 11 Jun 2009 21:45:57 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 06 Sep 2009 13:40:36 +0300 From: Danny Braniss Message-ID: Cc: ports@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 10:40:38 -0000 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Huhu, > > Yes we life and that's good :-). > Changes: > > - Fix build error when compiling in debug mode on FreeBSD HEAD > - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite timeout. > - Some FreeBSD relate typos > - Enable shared OpenGL service. Completely untested due to lack of > appropriate hardware but it compiles at least > - Add support for shared clipboards. Requires libXt > - FreeBSD: Implement preemption API for guest SMP and enable > it (slightly tested). Add neccessary RTMP* methods in userspace > for the frontends to detect the number of CPUs > - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex > instead of a spinlock to fix the problems users are seeing > (assertions with debugging enabled) while still being able > to run on 100Hz hosts. No problems detected so far and Solaris > doesn't use a spin mutex in this code too so it shouldn't do > any harm (keeping fingers crossed)space for the frontends to > detect the number of CPUs > - Add support for curl > - Add VBoxSharedClipboard > > Ports Changes; > - Force guestadditions version to 2.2.4 > - Removed Qt3 include replacements (already upstream) > - Removed cosmetic X11 include path patch > > Please make SURE, your world and kernel is in sync and you've read > the pkg-messages. Also please unload the kernel module before > you update the port ;-). > > Many thx to all Vbox Devs, All supporters, my nice team! :-) > > http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz > > Happy Testing! > ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no longer available, there is a ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2 then again in ports/emulatores/virtualbox the version is 3.0.51r22226, can someone please explain? danny From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 14:58:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 848C3106566B for ; Sun, 6 Sep 2009 14:58:05 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 3B9048FC16 for ; Sun, 6 Sep 2009 14:58:04 +0000 (UTC) Received: from [89.178.150.29] (port=25645 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkJBr-000PDe-A4 for freebsd-current@freebsd.org; Sun, 06 Sep 2009 18:58:03 +0400 Message-ID: <4AA3CDFA.4040008@lissyara.su> Date: Sun, 06 Sep 2009 18:58:02 +0400 From: Alex Keda User-Agent: Thunderbird 2.0.0.22 (X11/20090728) MIME-Version: 1.0 To: freebsd-current References: <4AA384EC.3060003@lissyara.su> In-Reply-To: <4AA384EC.3060003@lissyara.su> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Subject: Re: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 14:58:05 -0000 Alex Keda пишет: > hi! > I have fatal trap with today (and yesterday) current. > Machine boot, I see: > Timecounters tick every 1.000 msec > then, it freese ~30 seconds and go to kernel debugger - fatal trap 12 > stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d it's amd64. From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 15:11:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 276B1106566B for ; Sun, 6 Sep 2009 15:11:51 +0000 (UTC) (envelope-from aman.jassal@esigetel.fr) Received: from smtp20.orange.fr (smtp20.orange.fr [193.252.22.31]) by mx1.freebsd.org (Postfix) with ESMTP id 416E28FC12 for ; Sun, 6 Sep 2009 15:11:50 +0000 (UTC) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2021.orange.fr (SMTP Server) with ESMTP id E158620000F2 for ; Sun, 6 Sep 2009 17:11:48 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2021.orange.fr (SMTP Server) with ESMTP id C872F20000E1 for ; Sun, 6 Sep 2009 17:11:48 +0200 (CEST) Received: from PCdeKimKas (AMontsouris-153-1-44-56.w90-2.abo.wanadoo.fr [90.2.203.56]) by mwinf2021.orange.fr (SMTP Server) with SMTP id CDE8720000F2 for ; Sun, 6 Sep 2009 17:11:47 +0200 (CEST) X-ME-UUID: 20090906151147843.CDE8720000F2@mwinf2021.orange.fr Message-ID: <9FFF3C23C8EB4ED2A0445B064991E774@PCdeKimKas> From: "Aman Jassal" To: Date: Sun, 6 Sep 2009 17:10:36 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problems with IPSec during kernel compilation with sources from CURRENT 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 15:11:51 -0000 Dear all, I performed an upgrade of my kernel sources this morning using CVSup, = and successfully retrieved all the sources from HEAD (CURRENT 9.0). I then performed a kernel compilation to upgrade it, and since I wanted = to test out IPSec, I added the following lines in my kernel = configuration file : Options IPSEC Options IPSEC_DEBUG But the kernel compilation doesn't go through and I get errors. Here are = the errors I got (it's a bit long) : xform_ah.o(.text+0x13): In function `ah_algorithm_lookup': /usr/src/sys/netipsec/xform_ah.c:116: undefined reference to = `auth_hash_hmac_sha2_512' xform_ah.o(.text+0x26):/usr/src/sys/netipsec/xform_ah.c:120: undefined = reference to `auth_hash_hmac_sha1' xform_ah.o(.text+0x43):/usr/src/sys/netipsec/xform_ah.c:128: undefined = reference to `auth_hash_hmac_sha2_256' xform_ah.o(.text+0x55):/usr/src/sys/netipsec/xform_ah.c:124: undefined = reference to `auth_hash_key_md5' xform_ah.o(.text+0x73):/usr/src/sys/netipsec/xform_ah.c:126: undefined = reference to `auth_hash_key_sha1' xform_ah.o(.text+0x80):/usr/src/sys/netipsec/xform_ah.c:116: undefined = reference to `auth_hash_null' xform_ah.o(.text+0x8f):/usr/src/sys/netipsec/xform_ah.c:118: undefined = reference to `auth_hash_hmac_md5' xform_ah.o(.text+0x96):/usr/src/sys/netipsec/xform_ah.c:122: undefined = reference to `auth_hash_hmac_ripemd_160' xform_ah.o(.text+0x9d):/usr/src/sys/netipsec/xform_ah.c:130: undefined = reference to `auth_hash_hmac_sha2_384' xform_ah.o(.text+0x540): In function `ah_massage_headers': /usr/src/sys/netipsec/xform_ah.c:432: undefined reference to `M_XDATA' xform_ah.o(.text+0x623):/usr/src/sys/netipsec/xform_ah.c:485: undefined = reference to `M_XDATA' xform_ah.o(.text+0x688):/usr/src/sys/netipsec/xform_ah.c:505: undefined = reference to `M_XDATA' xform_ah.o(.text+0x705):/usr/src/sys/netipsec/xform_ah.c:529: undefined = reference to `M_XDATA' xform_ah.o(.text+0x756):/usr/src/sys/netipsec/xform_ah.c:538: undefined = reference to `M_XDATA' xform_ah.o(.text+0x8dc): In function `ah_output_cb': /usr/src/sys/netipsec/xform_ah.c:1146: undefined reference to = `crypto_dispatch' xform_ah.o(.text+0x986):/usr/src/sys/netipsec/xform_ah.c:1172: undefined = reference to `M_XDATA' xform_ah.o(.text+0x996):/usr/src/sys/netipsec/xform_ah.c:1173: undefined = reference to `crypto_freereq' xform_ah.o(.text+0xa49):/usr/src/sys/netipsec/xform_ah.c:1200: undefined = reference to `M_XDATA' xform_ah.o(.text+0xa59):/usr/src/sys/netipsec/xform_ah.c:1201: undefined = reference to `crypto_freereq' xform_ah.o(.text+0xb79): In function `ah_input_cb': /usr/src/sys/netipsec/xform_ah.c:768: undefined reference to = `crypto_dispatch' xform_ah.o(.text+0xbd0):/usr/src/sys/netipsec/xform_ah.c:778: undefined = reference to `crypto_freereq' xform_ah.o(.text+0xd32):/usr/src/sys/netipsec/xform_ah.c:825: undefined = reference to `M_XDATA' xform_ah.o(.text+0xebc):/usr/src/sys/netipsec/xform_ah.c:869: undefined = reference to `M_XDATA' xform_ah.o(.text+0xed0):/usr/src/sys/netipsec/xform_ah.c:871: undefined = reference to `crypto_freereq' xform_ah.o(.text+0x10e7): In function `ah_init': /usr/src/sys/netipsec/xform_ah.c:221: undefined reference to = `crypto_newsession' xform_ah.o(.text+0x1148): In function `ah_zeroize': /usr/src/sys/netipsec/xform_ah.c:238: undefined reference to = `crypto_freesession' xform_ah.o(.text+0x1469): In function `ah_output': /usr/src/sys/netipsec/xform_ah.c:1003: undefined reference to = `crypto_getreq' xform_ah.o(.text+0x14e3):/usr/src/sys/netipsec/xform_ah.c:1024: = undefined reference to `M_XDATA' xform_ah.o(.text+0x1500):/usr/src/sys/netipsec/xform_ah.c:1027: = undefined reference to `crypto_freereq' xform_ah.o(.text+0x1676):/usr/src/sys/netipsec/xform_ah.c:1078: = undefined reference to `M_XDATA' xform_ah.o(.text+0x168c):/usr/src/sys/netipsec/xform_ah.c:1079: = undefined reference to `crypto_freereq' xform_ah.o(.text+0x171f):/usr/src/sys/netipsec/xform_ah.c:1099: = undefined reference to `crypto_dispatch' xform_ah.o(.text+0x1971): In function `ah_input': /usr/src/sys/netipsec/xform_ah.c:608: undefined reference to = `crypto_getreq' xform_ah.o(.text+0x1ab4):/usr/src/sys/netipsec/xform_ah.c:646: undefined = reference to `M_XDATA' xform_ah.o(.text+0x1af8):/usr/src/sys/netipsec/xform_ah.c:652: undefined = reference to `crypto_freereq' xform_ah.o(.text+0x1b93):/usr/src/sys/netipsec/xform_ah.c:676: undefined = reference to `M_XDATA' xform_ah.o(.text+0x1ba9):/usr/src/sys/netipsec/xform_ah.c:677: undefined = reference to `crypto_freereq' xform_ah.o(.text+0x1c4d):/usr/src/sys/netipsec/xform_ah.c:700: undefined = reference to `crypto_dispatch' xform_ah.o(.text+0x1c77):/usr/src/sys/netipsec/xform_ah.c:642: undefined = reference to `M_XDATA' xform_esp.o(.text+0xf): In function `esp_algorithm_lookup': /usr/src/sys/netipsec/xform_esp.c:110: undefined reference to = `enc_xform_blf' xform_esp.o(.text+0x1e):/usr/src/sys/netipsec/xform_esp.c:106: undefined = reference to `enc_xform_3des' xform_esp.o(.text+0x28):/usr/src/sys/netipsec/xform_esp.c:112: undefined = reference to `enc_xform_cast5' xform_esp.o(.text+0x39):/usr/src/sys/netipsec/xform_esp.c:108: undefined = reference to `enc_xform_rijndael128' xform_esp.o(.text+0x53):/usr/src/sys/netipsec/xform_esp.c:104: undefined = reference to `enc_xform_camellia' xform_esp.o(.text+0x67):/usr/src/sys/netipsec/xform_esp.c:104: undefined = reference to `enc_xform_des' xform_esp.o(.text+0x6e):/usr/src/sys/netipsec/xform_esp.c:114: undefined = reference to `enc_xform_skipjack' xform_esp.o(.text+0x75):/usr/src/sys/netipsec/xform_esp.c:116: undefined = reference to `enc_xform_null' xform_esp.o(.text+0x99): In function `esp_attach': /usr/src/sys/netipsec/xform_esp.c:992: undefined reference to = `enc_xform_des' xform_esp.o(.text+0xad):/usr/src/sys/netipsec/xform_esp.c:993: undefined = reference to `enc_xform_3des' xform_esp.o(.text+0xc1):/usr/src/sys/netipsec/xform_esp.c:994: undefined = reference to `enc_xform_rijndael128' xform_esp.o(.text+0xd5):/usr/src/sys/netipsec/xform_esp.c:995: undefined = reference to `enc_xform_blf' xform_esp.o(.text+0xe9):/usr/src/sys/netipsec/xform_esp.c:996: undefined = reference to `enc_xform_cast5' xform_esp.o(.text+0xfd):/usr/src/sys/netipsec/xform_esp.c:997: undefined = reference to `enc_xform_skipjack' xform_esp.o(.text+0x111):/usr/src/sys/netipsec/xform_esp.c:998: = undefined reference to `enc_xform_null' xform_esp.o(.text+0x125):/usr/src/sys/netipsec/xform_esp.c:999: = undefined reference to `enc_xform_camellia' xform_esp.o(.text+0x2bb): In function `esp_input_cb': /usr/src/sys/netipsec/xform_esp.c:502: undefined reference to = `crypto_dispatch' xform_esp.o(.text+0x417):/usr/src/sys/netipsec/xform_esp.c:554: = undefined reference to `M_XDATA' xform_esp.o(.text+0x427):/usr/src/sys/netipsec/xform_esp.c:555: = undefined reference to `crypto_freereq' xform_esp.o(.text+0x762):/usr/src/sys/netipsec/xform_esp.c:639: = undefined reference to `M_XDATA' xform_esp.o(.text+0x776):/usr/src/sys/netipsec/xform_esp.c:641: = undefined reference to `crypto_freereq' xform_esp.o(.text+0x7e0): In function `esp_zeroize': /usr/src/sys/netipsec/xform_esp.c:258: undefined reference to `M_XDATA' xform_esp.o(.text+0x946): In function `esp_init': /usr/src/sys/netipsec/xform_esp.c:198: undefined reference to = `enc_xform_null' xform_esp.o(.text+0x95f):/usr/src/sys/netipsec/xform_esp.c:199: = undefined reference to `M_XDATA' xform_esp.o(.text+0xa2b):/usr/src/sys/netipsec/xform_esp.c:229: = undefined reference to `crypto_newsession' xform_esp.o(.text+0xa4e):/usr/src/sys/netipsec/xform_esp.c:232: = undefined reference to `crypto_newsession' xform_esp.o(.text+0xa9e):/usr/src/sys/netipsec/xform_esp.c:235: = undefined reference to `crypto_newsession' xform_esp.o(.text+0xcb2): In function `esp_output_cb': /usr/src/sys/netipsec/xform_esp.c:920: undefined reference to = `crypto_dispatch' xform_esp.o(.text+0xd5d):/usr/src/sys/netipsec/xform_esp.c:942: = undefined reference to `M_XDATA' xform_esp.o(.text+0xd70):/usr/src/sys/netipsec/xform_esp.c:943: = undefined reference to `crypto_freereq' xform_esp.o(.text+0xe1e):/usr/src/sys/netipsec/xform_esp.c:974: = undefined reference to `M_XDATA' xform_esp.o(.text+0xe31):/usr/src/sys/netipsec/xform_esp.c:975: = undefined reference to `crypto_freereq' xform_esp.o(.text+0x1235): In function `esp_output': /usr/src/sys/netipsec/xform_esp.c:810: undefined reference to = `crypto_getreq' xform_esp.o(.text+0x12ba):/usr/src/sys/netipsec/xform_esp.c:838: = undefined reference to `M_XDATA' xform_esp.o(.text+0x12d4):/usr/src/sys/netipsec/xform_esp.c:841: = undefined reference to `crypto_freereq' xform_esp.o(.text+0x13b0):/usr/src/sys/netipsec/xform_esp.c:874: = undefined reference to `crypto_dispatch' xform_esp.o(.text+0x16af): In function `esp_input': /usr/src/sys/netipsec/xform_esp.c:350: undefined reference to = `crypto_getreq' xform_esp.o(.text+0x1706):/usr/src/sys/netipsec/xform_esp.c:361: = undefined reference to `M_XDATA' xform_esp.o(.text+0x1727):/usr/src/sys/netipsec/xform_esp.c:364: = undefined reference to `M_XDATA' xform_esp.o(.text+0x1746):/usr/src/sys/netipsec/xform_esp.c:367: = undefined reference to `crypto_freereq' xform_esp.o(.text+0x18fe):/usr/src/sys/netipsec/xform_esp.c:430: = undefined reference to `crypto_dispatch' xform_ipcomp.o(.text+0xa): In function `ipcomp_algorithm_lookup': /usr/src/sys/netipsec/xform_ipcomp.c:88: undefined reference to = `comp_algo_deflate' xform_ipcomp.o(.text+0x5a): In function `ipcomp_input': /usr/src/sys/netipsec/xform_ipcomp.c:147: undefined reference to = `crypto_getreq' xform_ipcomp.o(.text+0xad):/usr/src/sys/netipsec/xform_ipcomp.c:155: = undefined reference to `M_XDATA' xform_ipcomp.o(.text+0xcf):/usr/src/sys/netipsec/xform_ipcomp.c:158: = undefined reference to `crypto_freereq' xform_ipcomp.o(.text+0x1a4):/usr/src/sys/netipsec/xform_ipcomp.c:189: = undefined reference to `crypto_dispatch' xform_ipcomp.o(.text+0x1d8): In function `ipcomp_zeroize': /usr/src/sys/netipsec/xform_ipcomp.c:130: undefined reference to = `crypto_freesession' xform_ipcomp.o(.text+0x288): In function `ipcomp_init': /usr/src/sys/netipsec/xform_ipcomp.c:119: undefined reference to = `crypto_newsession' xform_ipcomp.o(.text+0x3f7): In function `ipcomp_output_cb': /usr/src/sys/netipsec/xform_ipcomp.c:521: undefined reference to = `crypto_dispatch' xform_ipcomp.o(.text+0x534):/usr/src/sys/netipsec/xform_ipcomp.c:568: = undefined reference to `M_XDATA' xform_ipcomp.o(.text+0x544):/usr/src/sys/netipsec/xform_ipcomp.c:569: = undefined reference to `crypto_freereq' xform_ipcomp.o(.text+0x5f9):/usr/src/sys/netipsec/xform_ipcomp.c:582: = undefined reference to `M_XDATA' xform_ipcomp.o(.text+0x609):/usr/src/sys/netipsec/xform_ipcomp.c:583: = undefined reference to `crypto_freereq' xform_ipcomp.o(.text+0x733): In function `ipcomp_input_cb': /usr/src/sys/netipsec/xform_ipcomp.c:252: undefined reference to = `crypto_dispatch' xform_ipcomp.o(.text+0x7d3):/usr/src/sys/netipsec/xform_ipcomp.c:273: = undefined reference to `M_XDATA' xform_ipcomp.o(.text+0x7e3):/usr/src/sys/netipsec/xform_ipcomp.c:274: = undefined reference to `crypto_freereq' xform_ipcomp.o(.text+0x9c0):/usr/src/sys/netipsec/xform_ipcomp.c:313: = undefined reference to `M_XDATA' xform_ipcomp.o(.text+0x9d4):/usr/src/sys/netipsec/xform_ipcomp.c:315: = undefined reference to `crypto_freereq' xform_ipcomp.o(.text+0xc81): In function `ipcomp_output': /usr/src/sys/netipsec/xform_ipcomp.c:433: undefined reference to = `crypto_getreq' xform_ipcomp.o(.text+0xcea):/usr/src/sys/netipsec/xform_ipcomp.c:452: = undefined reference to `M_XDATA' xform_ipcomp.o(.text+0xd28):/usr/src/sys/netipsec/xform_ipcomp.c:457: = undefined reference to `crypto_freereq' xform_ipcomp.o(.text+0xda6):/usr/src/sys/netipsec/xform_ipcomp.c:476: = undefined reference to `crypto_dispatch' *** Error code 1 Stop in /usr/obj/usr/src/sys/MYKERNEL. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. # I must have made something silly or forgotten something important, but = all I did was getting my kernel sources up to date via cvsup and = recompiling it (the classic way : "# make buildkernel = KERNCONF=3DMYKERNEL" ; MYKERNEL being my kernel configuration file) ... = Do I have to recompile world too before recompiling the kernel ? Has = someone even encountered this before ? I removed these options from my kernel configuration file for the while = and use the same file as GENERIC, expect that I added SCTP_DEBUG in it. = Compilation was performed successfully and my laptop booted finely on = it. But the fact that IPSec couldn't be compiled startled me a bit. Thanks in advance for your help. Aman Jassal From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 15:35:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 519A5106566B; Sun, 6 Sep 2009 15:35:08 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 185F48FC1B; Sun, 6 Sep 2009 15:35:06 +0000 (UTC) Received: by bwz2 with SMTP id 2so1474243bwz.43 for ; Sun, 06 Sep 2009 08:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=Klx3nG45VAe2cbQeKwp3iMXomK053Tyi7B4UEYcgeD4=; b=bk+LgnHx3bqp0/BbPv/I3YMTW0IR06xWgMpME2SWhr7EuvaAYgidvDKe4izrH/x+Z/ e9ocjMNJ571aP0un/P9sjMEt/KsMzlEJ3gIB3hsAwe9sq8M7HvRUsYxC/CyJNP1mkxUZ 9o9vgtm2+lYPo1Vm7kCHl98upCgYqOJ5q5+ic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=m+4Zg5B3oSHFDhGAKT6RWbntSiImDp3BVpnJbzSohh+M8InQ5oOg+zhMSqblxqnU5k MdUJXFk1IdEIvDcJvWXZzfcJOC0xKIcInk8nnTXSweLHMtqg10wqo11VyFf7l3yGee2y 9bcq2CqqSE9g9o2EV5vNtpemidshQyY/jbgE4= MIME-Version: 1.0 Received: by 10.204.160.144 with SMTP id n16mr11020377bkx.152.1252249928288; Sun, 06 Sep 2009 08:12:08 -0700 (PDT) In-Reply-To: References: <20090611194557.GC98175@bsdcrew.de> From: Odhiambo Washington Date: Sun, 6 Sep 2009 18:11:48 +0300 Message-ID: <991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com> To: Danny Braniss Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 15:35:08 -0000 On Sun, Sep 6, 2009 at 1:40 PM, Danny Braniss wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Huhu, > > > > Yes we life and that's good :-). > > Changes: > > > > - Fix build error when compiling in debug mode on FreeBSD HEAD > > - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite timeout. > > - Some FreeBSD relate typos > > - Enable shared OpenGL service. Completely untested due to lack of > > appropriate hardware but it compiles at least > > - Add support for shared clipboards. Requires libXt > > - FreeBSD: Implement preemption API for guest SMP and enable > > it (slightly tested). Add neccessary RTMP* methods in userspace > > for the frontends to detect the number of CPUs > > - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex > > instead of a spinlock to fix the problems users are seeing > > (assertions with debugging enabled) while still being able > > to run on 100Hz hosts. No problems detected so far and Solaris > > doesn't use a spin mutex in this code too so it shouldn't do > > any harm (keeping fingers crossed)space for the frontends to > > detect the number of CPUs > > - Add support for curl > > - Add VBoxSharedClipboard > > > > Ports Changes; > > - Force guestadditions version to 2.2.4 > > - Removed Qt3 include replacements (already upstream) > > - Removed cosmetic X11 include path patch > > > > Please make SURE, your world and kernel is in sync and you've read > > the pkg-messages. Also please unload the kernel module before > > you update the port ;-). > > > > Many thx to all Vbox Devs, All supporters, my nice team! :-) > > > > http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz > > > > Happy Testing! > > > ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no > longer available, there is a > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2 > then again in ports/emulatores/virtualbox the version is 3.0.51r22226, > > can someone please explain? > > And on my FreeBSD 7.2-STABLE, compiling virtualbox fails as follows: kBuild: Linking VBoxREM64 kBuild: Installing VBoxREM64 => /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBox REM64.so kmk[2]: Leaving directory `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' kmk[1]: Leaving directory `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' kBuild: Pass - Programs kmk[1]: Entering directory `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' kmk[2]: Entering directory `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' kBuild: Compiling tstAPI - /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/src/VBox/Main/testcase/tstAPI.cpp kBuild: Linking tstAPI /usr/local/lib/libssl.so.5: undefined reference to `d2i_X509_EXTENSIONS' /usr/local/lib/libssl.so.5: undefined reference to `ENGINE_get_ssl_client_cert_function' /usr/local/lib/libssl.so.5: undefined reference to `HMAC_CTX_set_flags' /usr/local/lib/libssl.so.5: undefined reference to `i2d_X509_EXTENSIONS' /usr/local/lib/libssl.so.5: undefined reference to `ENGINE_load_ssl_client_cert' /usr/local/lib/libssl.so.5: undefined reference to `pqueue_size' /usr/local/lib/libssl.so.5: undefined reference to `EVP_idea_cbc' kmk[2]: *** [/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/obj/tstAPI/tstAPI] Error 1 The failing command: @g++ '-Wl,-rpath,/usr/local/lib/virtualbox' -m32 -o /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r 22226/out/freebsd.x86/release/obj/tstAPI/tstAPI /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/ release/obj/tstAPI/tstAPI.o -L/usr/lib -L/usr/X11R6/lib -L/usr/local/lib /usr/ports/emulators/virtualbox/work/virtualbo x-3.0.51r22226/out/freebsd.x86/release/bin/VBoxRT.so /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freeb sd.x86/release/lib/VBoxCOM.a /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBoxX PCOM.so kmk[2]: Leaving directory `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' kmk[1]: *** [pass_binaries_this] Error 2 kmk[1]: Leaving directory `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' kmk: *** [pass_binaries_order] Error 2 *** Error code 2 Stop in /usr/ports/emulators/virtualbox. I hope someone can advise on what is needed. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "If you have nothing good to say about someone, just shut up!." -- Lucky Dube From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 15:56:53 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE4EA1065695 for ; Sun, 6 Sep 2009 15:56:52 +0000 (UTC) (envelope-from aman.jassal@esigetel.fr) Received: from smtp20.orange.fr (smtp20.orange.fr [80.12.242.26]) by mx1.freebsd.org (Postfix) with ESMTP id E2CF38FC15 for ; Sun, 6 Sep 2009 15:56:51 +0000 (UTC) Received: from smtp20.orange.fr (mwinf2008 [172.22.130.36]) by mwinf2015.orange.fr (SMTP Server) with ESMTP id 04DFB1C0694E for ; Sun, 6 Sep 2009 16:53:14 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2008.orange.fr (SMTP Server) with ESMTP id 3C7FC1C00082 for ; Sun, 6 Sep 2009 16:53:12 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2008.orange.fr (SMTP Server) with ESMTP id 256101C00084 for ; Sun, 6 Sep 2009 16:53:12 +0200 (CEST) Received: from PCdeKimKas (AMontsouris-153-1-44-56.w90-2.abo.wanadoo.fr [90.2.203.56]) by mwinf2008.orange.fr (SMTP Server) with SMTP id 3C4D61C00082 for ; Sun, 6 Sep 2009 16:53:11 +0200 (CEST) X-ME-UUID: 20090906145311247.3C4D61C00082@mwinf2008.orange.fr Message-ID: From: "Aman Jassal" To: Date: Sun, 6 Sep 2009 16:52:00 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Problems with IPSec during kernel compilation with sources from CURRENT 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 15:56:53 -0000 Dear all, I performed an upgrade of my kernel sources this morning using CVSup, = and successfully retrieved all the sources from HEAD (CURRENT 9.0). I then performed a kernel compilation to upgrade it, and since I wanted = to test out IPSec, I added the following lines in my kernel = configuration file : Options IPSEC Options IPSEC_DEBUG But the kernel compilation doesn't go through and I get errors. Here are = the errors I got (it's a bit long) : xform_ah.o(.text+0x13): In function `ah_algorithm_lookup': /usr/src/sys/netipsec/xform_ah.c:116: undefined reference to = `auth_hash_hmac_sha2_512' xform_ah.o(.text+0x26):/usr/src/sys/netipsec/xform_ah.c:120: undefined = reference to `auth_hash_hmac_sha1' xform_ah.o(.text+0x43):/usr/src/sys/netipsec/xform_ah.c:128: undefined = reference to `auth_hash_hmac_sha2_256' xform_ah.o(.text+0x55):/usr/src/sys/netipsec/xform_ah.c:124: undefined = reference to `auth_hash_key_md5' xform_ah.o(.text+0x73):/usr/src/sys/netipsec/xform_ah.c:126: undefined = reference to `auth_hash_key_sha1' xform_ah.o(.text+0x80):/usr/src/sys/netipsec/xform_ah.c:116: undefined = reference to `auth_hash_null' xform_ah.o(.text+0x8f):/usr/src/sys/netipsec/xform_ah.c:118: undefined = reference to `auth_hash_hmac_md5' xform_ah.o(.text+0x96):/usr/src/sys/netipsec/xform_ah.c:122: undefined = reference to `auth_hash_hmac_ripemd_160' xform_ah.o(.text+0x9d):/usr/src/sys/netipsec/xform_ah.c:130: undefined = reference to `auth_hash_hmac_sha2_384' xform_ah.o(.text+0x540): In function `ah_massage_headers': /usr/src/sys/netipsec/xform_ah.c:432: undefined reference to `M_XDATA' xform_ah.o(.text+0x623):/usr/src/sys/netipsec/xform_ah.c:485: undefined = reference to `M_XDATA' xform_ah.o(.text+0x688):/usr/src/sys/netipsec/xform_ah.c:505: undefined = reference to `M_XDATA' xform_ah.o(.text+0x705):/usr/src/sys/netipsec/xform_ah.c:529: undefined = reference to `M_XDATA' xform_ah.o(.text+0x756):/usr/src/sys/netipsec/xform_ah.c:538: undefined = reference to `M_XDATA' xform_ah.o(.text+0x8dc): In function `ah_output_cb': /usr/src/sys/netipsec/xform_ah.c:1146: undefined reference to = `crypto_dispatch' xform_ah.o(.text+0x986):/usr/src/sys/netipsec/xform_ah.c:1172: undefined = reference to `M_XDATA' xform_ah.o(.text+0x996):/usr/src/sys/netipsec/xform_ah.c:1173: undefined = reference to `crypto_freereq' xform_ah.o(.text+0xa49):/usr/src/sys/netipsec/xform_ah.c:1200: undefined = reference to `M_XDATA' xform_ah.o(.text+0xa59):/usr/src/sys/netipsec/xform_ah.c:1201: undefined = reference to `crypto_freereq' xform_ah.o(.text+0xb79): In function `ah_input_cb': /usr/src/sys/netipsec/xform_ah.c:768: undefined reference to = `crypto_dispatch' xform_ah.o(.text+0xbd0):/usr/src/sys/netipsec/xform_ah.c:778: undefined = reference to `crypto_freereq' xform_ah.o(.text+0xd32):/usr/src/sys/netipsec/xform_ah.c:825: undefined = reference to `M_XDATA' xform_ah.o(.text+0xebc):/usr/src/sys/netipsec/xform_ah.c:869: undefined = reference to `M_XDATA' xform_ah.o(.text+0xed0):/usr/src/sys/netipsec/xform_ah.c:871: undefined = reference to `crypto_freereq' xform_ah.o(.text+0x10e7): In function `ah_init': /usr/src/sys/netipsec/xform_ah.c:221: undefined reference to = `crypto_newsession' xform_ah.o(.text+0x1148): In function `ah_zeroize': /usr/src/sys/netipsec/xform_ah.c:238: undefined reference to = `crypto_freesession' xform_ah.o(.text+0x1469): In function `ah_output': /usr/src/sys/netipsec/xform_ah.c:1003: undefined reference to = `crypto_getreq' xform_ah.o(.text+0x14e3):/usr/src/sys/netipsec/xform_ah.c:1024: = undefined reference to `M_XDATA' xform_ah.o(.text+0x1500):/usr/src/sys/netipsec/xform_ah.c:1027: = undefined reference to `crypto_freereq' xform_ah.o(.text+0x1676):/usr/src/sys/netipsec/xform_ah.c:1078: = undefined reference to `M_XDATA' xform_ah.o(.text+0x168c):/usr/src/sys/netipsec/xform_ah.c:1079: = undefined reference to `crypto_freereq' xform_ah.o(.text+0x171f):/usr/src/sys/netipsec/xform_ah.c:1099: = undefined reference to `crypto_dispatch' xform_ah.o(.text+0x1971): In function `ah_input': /usr/src/sys/netipsec/xform_ah.c:608: undefined reference to = `crypto_getreq' xform_ah.o(.text+0x1ab4):/usr/src/sys/netipsec/xform_ah.c:646: undefined = reference to `M_XDATA' xform_ah.o(.text+0x1af8):/usr/src/sys/netipsec/xform_ah.c:652: undefined = reference to `crypto_freereq' xform_ah.o(.text+0x1b93):/usr/src/sys/netipsec/xform_ah.c:676: undefined = reference to `M_XDATA' xform_ah.o(.text+0x1ba9):/usr/src/sys/netipsec/xform_ah.c:677: undefined = reference to `crypto_freereq' xform_ah.o(.text+0x1c4d):/usr/src/sys/netipsec/xform_ah.c:700: undefined = reference to `crypto_dispatch' xform_ah.o(.text+0x1c77):/usr/src/sys/netipsec/xform_ah.c:642: undefined = reference to `M_XDATA' xform_esp.o(.text+0xf): In function `esp_algorithm_lookup': /usr/src/sys/netipsec/xform_esp.c:110: undefined reference to = `enc_xform_blf' xform_esp.o(.text+0x1e):/usr/src/sys/netipsec/xform_esp.c:106: undefined = reference to `enc_xform_3des' xform_esp.o(.text+0x28):/usr/src/sys/netipsec/xform_esp.c:112: undefined = reference to `enc_xform_cast5' xform_esp.o(.text+0x39):/usr/src/sys/netipsec/xform_esp.c:108: undefined = reference to `enc_xform_rijndael128' xform_esp.o(.text+0x53):/usr/src/sys/netipsec/xform_esp.c:104: undefined = reference to `enc_xform_camellia' xform_esp.o(.text+0x67):/usr/src/sys/netipsec/xform_esp.c:104: undefined = reference to `enc_xform_des' xform_esp.o(.text+0x6e):/usr/src/sys/netipsec/xform_esp.c:114: undefined = reference to `enc_xform_skipjack' xform_esp.o(.text+0x75):/usr/src/sys/netipsec/xform_esp.c:116: undefined = reference to `enc_xform_null' xform_esp.o(.text+0x99): In function `esp_attach': /usr/src/sys/netipsec/xform_esp.c:992: undefined reference to = `enc_xform_des' xform_esp.o(.text+0xad):/usr/src/sys/netipsec/xform_esp.c:993: undefined = reference to `enc_xform_3des' xform_esp.o(.text+0xc1):/usr/src/sys/netipsec/xform_esp.c:994: undefined = reference to `enc_xform_rijndael128' xform_esp.o(.text+0xd5):/usr/src/sys/netipsec/xform_esp.c:995: undefined = reference to `enc_xform_blf' xform_esp.o(.text+0xe9):/usr/src/sys/netipsec/xform_esp.c:996: undefined = reference to `enc_xform_cast5' xform_esp.o(.text+0xfd):/usr/src/sys/netipsec/xform_esp.c:997: undefined = reference to `enc_xform_skipjack' xform_esp.o(.text+0x111):/usr/src/sys/netipsec/xform_esp.c:998: = undefined reference to `enc_xform_null' xform_esp.o(.text+0x125):/usr/src/sys/netipsec/xform_esp.c:999: = undefined reference to `enc_xform_camellia' xform_esp.o(.text+0x2bb): In function `esp_input_cb': /usr/src/sys/netipsec/xform_esp.c:502: undefined reference to = `crypto_dispatch' xform_esp.o(.text+0x417):/usr/src/sys/netipsec/xform_esp.c:554: = undefined reference to `M_XDATA' xform_esp.o(.text+0x427):/usr/src/sys/netipsec/xform_esp.c:555: = undefined reference to `crypto_freereq' xform_esp.o(.text+0x762):/usr/src/sys/netipsec/xform_esp.c:639: = undefined reference to `M_XDATA' xform_esp.o(.text+0x776):/usr/src/sys/netipsec/xform_esp.c:641: = undefined reference to `crypto_freereq' xform_esp.o(.text+0x7e0): In function `esp_zeroize': /usr/src/sys/netipsec/xform_esp.c:258: undefined reference to `M_XDATA' xform_esp.o(.text+0x946): In function `esp_init': /usr/src/sys/netipsec/xform_esp.c:198: undefined reference to = `enc_xform_null' xform_esp.o(.text+0x95f):/usr/src/sys/netipsec/xform_esp.c:199: = undefined reference to `M_XDATA' xform_esp.o(.text+0xa2b):/usr/src/sys/netipsec/xform_esp.c:229: = undefined reference to `crypto_newsession' xform_esp.o(.text+0xa4e):/usr/src/sys/netipsec/xform_esp.c:232: = undefined reference to `crypto_newsession' xform_esp.o(.text+0xa9e):/usr/src/sys/netipsec/xform_esp.c:235: = undefined reference to `crypto_newsession' xform_esp.o(.text+0xcb2): In function `esp_output_cb': /usr/src/sys/netipsec/xform_esp.c:920: undefined reference to = `crypto_dispatch' xform_esp.o(.text+0xd5d):/usr/src/sys/netipsec/xform_esp.c:942: = undefined reference to `M_XDATA' xform_esp.o(.text+0xd70):/usr/src/sys/netipsec/xform_esp.c:943: = undefined reference to `crypto_freereq' xform_esp.o(.text+0xe1e):/usr/src/sys/netipsec/xform_esp.c:974: = undefined reference to `M_XDATA' xform_esp.o(.text+0xe31):/usr/src/sys/netipsec/xform_esp.c:975: = undefined reference to `crypto_freereq' xform_esp.o(.text+0x1235): In function `esp_output': /usr/src/sys/netipsec/xform_esp.c:810: undefined reference to = `crypto_getreq' xform_esp.o(.text+0x12ba):/usr/src/sys/netipsec/xform_esp.c:838: = undefined reference to `M_XDATA' xform_esp.o(.text+0x12d4):/usr/src/sys/netipsec/xform_esp.c:841: = undefined reference to `crypto_freereq' xform_esp.o(.text+0x13b0):/usr/src/sys/netipsec/xform_esp.c:874: = undefined reference to `crypto_dispatch' xform_esp.o(.text+0x16af): In function `esp_input': /usr/src/sys/netipsec/xform_esp.c:350: undefined reference to = `crypto_getreq' xform_esp.o(.text+0x1706):/usr/src/sys/netipsec/xform_esp.c:361: = undefined reference to `M_XDATA' xform_esp.o(.text+0x1727):/usr/src/sys/netipsec/xform_esp.c:364: = undefined reference to `M_XDATA' xform_esp.o(.text+0x1746):/usr/src/sys/netipsec/xform_esp.c:367: = undefined reference to `crypto_freereq' xform_esp.o(.text+0x18fe):/usr/src/sys/netipsec/xform_esp.c:430: = undefined reference to `crypto_dispatch' xform_ipcomp.o(.text+0xa): In function `ipcomp_algorithm_lookup': /usr/src/sys/netipsec/xform_ipcomp.c:88: undefined reference to = `comp_algo_deflate' xform_ipcomp.o(.text+0x5a): In function `ipcomp_input': /usr/src/sys/netipsec/xform_ipcomp.c:147: undefined reference to = `crypto_getreq' xform_ipcomp.o(.text+0xad):/usr/src/sys/netipsec/xform_ipcomp.c:155: = undefined reference to `M_XDATA' xform_ipcomp.o(.text+0xcf):/usr/src/sys/netipsec/xform_ipcomp.c:158: = undefined reference to `crypto_freereq' xform_ipcomp.o(.text+0x1a4):/usr/src/sys/netipsec/xform_ipcomp.c:189: = undefined reference to `crypto_dispatch' xform_ipcomp.o(.text+0x1d8): In function `ipcomp_zeroize': /usr/src/sys/netipsec/xform_ipcomp.c:130: undefined reference to = `crypto_freesession' xform_ipcomp.o(.text+0x288): In function `ipcomp_init': /usr/src/sys/netipsec/xform_ipcomp.c:119: undefined reference to = `crypto_newsession' xform_ipcomp.o(.text+0x3f7): In function `ipcomp_output_cb': /usr/src/sys/netipsec/xform_ipcomp.c:521: undefined reference to = `crypto_dispatch' xform_ipcomp.o(.text+0x534):/usr/src/sys/netipsec/xform_ipcomp.c:568: = undefined reference to `M_XDATA' xform_ipcomp.o(.text+0x544):/usr/src/sys/netipsec/xform_ipcomp.c:569: = undefined reference to `crypto_freereq' xform_ipcomp.o(.text+0x5f9):/usr/src/sys/netipsec/xform_ipcomp.c:582: = undefined reference to `M_XDATA' xform_ipcomp.o(.text+0x609):/usr/src/sys/netipsec/xform_ipcomp.c:583: = undefined reference to `crypto_freereq' xform_ipcomp.o(.text+0x733): In function `ipcomp_input_cb': /usr/src/sys/netipsec/xform_ipcomp.c:252: undefined reference to = `crypto_dispatch' xform_ipcomp.o(.text+0x7d3):/usr/src/sys/netipsec/xform_ipcomp.c:273: = undefined reference to `M_XDATA' xform_ipcomp.o(.text+0x7e3):/usr/src/sys/netipsec/xform_ipcomp.c:274: = undefined reference to `crypto_freereq' xform_ipcomp.o(.text+0x9c0):/usr/src/sys/netipsec/xform_ipcomp.c:313: = undefined reference to `M_XDATA' xform_ipcomp.o(.text+0x9d4):/usr/src/sys/netipsec/xform_ipcomp.c:315: = undefined reference to `crypto_freereq' xform_ipcomp.o(.text+0xc81): In function `ipcomp_output': /usr/src/sys/netipsec/xform_ipcomp.c:433: undefined reference to = `crypto_getreq' xform_ipcomp.o(.text+0xcea):/usr/src/sys/netipsec/xform_ipcomp.c:452: = undefined reference to `M_XDATA' xform_ipcomp.o(.text+0xd28):/usr/src/sys/netipsec/xform_ipcomp.c:457: = undefined reference to `crypto_freereq' xform_ipcomp.o(.text+0xda6):/usr/src/sys/netipsec/xform_ipcomp.c:476: = undefined reference to `crypto_dispatch' *** Error code 1 Stop in /usr/obj/usr/src/sys/MYKERNEL. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. # I must have made something silly or forgotten something important, but = all I did was getting my kernel sources up to date via cvsup and = recompiling it (the classic way : "# make buildkernel = KERNCONF=3DMYKERNEL" ; MYKERNEL being my kernel configuration file) ... = Do I have to recompile world too before recompiling the kernel ? Has = someone even encountered this before ? I removed these options from my kernel configuration file for the while = and use the same file as GENERIC, expect that I added SCTP_DEBUG in it. = Compilation was performed successfully and my laptop booted finely on = it. But the fact that IPSec couldn't be compiled startled me a bit. Thanks in advance for your help. Aman Jassal From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 16:25:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB6D7106566B; Sun, 6 Sep 2009 16:25:49 +0000 (UTC) (envelope-from miwi@bsdcrew.de) Received: from bsdcrew.de (duro.unixfreunde.de [85.214.90.4]) by mx1.freebsd.org (Postfix) with ESMTP id 077638FC16; Sun, 6 Sep 2009 16:25:48 +0000 (UTC) Received: by bsdcrew.de (Postfix, from userid 1001) id 4CF1C4AF52; Sun, 6 Sep 2009 18:25:45 +0200 (CEST) Date: Sun, 6 Sep 2009 18:25:45 +0200 From: Martin Wilke To: Odhiambo Washington Message-ID: <20090906162544.GA39448@bsdcrew.de> References: <20090611194557.GC98175@bsdcrew.de> <991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 16:25:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Sep 06, 2009 at 06:11:48PM +0300, Odhiambo Washington wrote: > On Sun, Sep 6, 2009 at 1:40 PM, Danny Braniss wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Huhu, > > > > > > Yes we life and that's good :-). > > > Changes: > > > > > > - Fix build error when compiling in debug mode on FreeBSD HEAD > > > - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite timeout. > > > - Some FreeBSD relate typos > > > - Enable shared OpenGL service. Completely untested due to lack of > > > appropriate hardware but it compiles at least > > > - Add support for shared clipboards. Requires libXt > > > - FreeBSD: Implement preemption API for guest SMP and enable > > > it (slightly tested). Add neccessary RTMP* methods in userspace > > > for the frontends to detect the number of CPUs > > > - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex > > > instead of a spinlock to fix the problems users are seeing > > > (assertions with debugging enabled) while still being able > > > to run on 100Hz hosts. No problems detected so far and Solaris > > > doesn't use a spin mutex in this code too so it shouldn't do > > > any harm (keeping fingers crossed)space for the frontends to > > > detect the number of CPUs > > > - Add support for curl > > > - Add VBoxSharedClipboard > > > > > > Ports Changes; > > > - Force guestadditions version to 2.2.4 > > > - Removed Qt3 include replacements (already upstream) > > > - Removed cosmetic X11 include path patch > > > > > > Please make SURE, your world and kernel is in sync and you've read > > > the pkg-messages. Also please unload the kernel module before > > > you update the port ;-). > > > > > > Many thx to all Vbox Devs, All supporters, my nice team! :-) > > > > > > http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz > > > > > > Happy Testing! > > > > > ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no > > longer available, there is a > > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2 > > then again in ports/emulatores/virtualbox the version is 3.0.51r22226, > > > > can someone please explain? > > > > > > > And on my FreeBSD 7.2-STABLE, compiling virtualbox fails as follows: > > > > kBuild: Linking VBoxREM64 > kBuild: Installing VBoxREM64 => > /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBox > REM64.so > kmk[2]: Leaving directory > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' > kmk[1]: Leaving directory > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' > kBuild: Pass - Programs > kmk[1]: Entering directory > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' > kmk[2]: Entering directory > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' > kBuild: Compiling tstAPI - > /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/src/VBox/Main/testcase/tstAPI.cpp > kBuild: Linking tstAPI > /usr/local/lib/libssl.so.5: undefined reference to `d2i_X509_EXTENSIONS' > /usr/local/lib/libssl.so.5: undefined reference to > `ENGINE_get_ssl_client_cert_function' > /usr/local/lib/libssl.so.5: undefined reference to `HMAC_CTX_set_flags' > /usr/local/lib/libssl.so.5: undefined reference to `i2d_X509_EXTENSIONS' > /usr/local/lib/libssl.so.5: undefined reference to > `ENGINE_load_ssl_client_cert' > /usr/local/lib/libssl.so.5: undefined reference to `pqueue_size' > /usr/local/lib/libssl.so.5: undefined reference to `EVP_idea_cbc' > kmk[2]: *** > [/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/obj/tstAPI/tstAPI] > Error 1 > The failing command: > @g++ '-Wl,-rpath,/usr/local/lib/virtualbox' -m32 -o > /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r > 22226/out/freebsd.x86/release/obj/tstAPI/tstAPI > /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/ > release/obj/tstAPI/tstAPI.o -L/usr/lib -L/usr/X11R6/lib > -L/usr/local/lib > /usr/ports/emulators/virtualbox/work/virtualbo > x-3.0.51r22226/out/freebsd.x86/release/bin/VBoxRT.so > /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freeb > sd.x86/release/lib/VBoxCOM.a > /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBoxX > PCOM.so > kmk[2]: Leaving directory > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' > kmk[1]: *** [pass_binaries_this] Error 2 > kmk[1]: Leaving directory > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' > kmk: *** [pass_binaries_order] Error 2 > *** Error code 2 > > Stop in /usr/ports/emulators/virtualbox. > > > I hope someone can advise on what is needed. > deinstall openssl from ports and try again :) > > -- > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254733744121/+254722743223 > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > "If you have nothing good to say about someone, just shut up!." > -- Lucky Dube - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqj4ogACgkQdLJIhLHm/OlShwCeJRqpqaBYbehqpKKfugxWD0PD OdEAmQFSfdfWNXvO/vTRLj5vxIsD5EwP =gbCY -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 16:29:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CD46106566C for ; Sun, 6 Sep 2009 16:29:32 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id D02438FC20 for ; Sun, 6 Sep 2009 16:29:31 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n86GPp9l055756; Sun, 6 Sep 2009 12:25:51 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200909061625.n86GPp9l055756@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 06 Sep 2009 12:29:33 -0400 To: "Aman Jassal" , From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: Problems with IPSec during kernel compilation with sources from CURRENT 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 16:29:32 -0000 At 10:52 AM 9/6/2009, Aman Jassal wrote: >I then performed a kernel compilation to upgrade it, and since I >wanted to test out IPSec, I added the following lines in my kernel >configuration file : > >Options IPSEC >Options IPSEC_DEBUG Hi, You need to add device crypto to the kernel as well ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 16:45:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8FB01065670 for ; Sun, 6 Sep 2009 16:45:52 +0000 (UTC) (envelope-from aman.jassal@esigetel.fr) Received: from smtp20.orange.fr (smtp20.orange.fr [80.12.242.26]) by mx1.freebsd.org (Postfix) with ESMTP id 52D508FC1E for ; Sun, 6 Sep 2009 16:45:52 +0000 (UTC) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2013.orange.fr (SMTP Server) with ESMTP id 147CF20000AE; Sun, 6 Sep 2009 18:45:51 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2013.orange.fr (SMTP Server) with ESMTP id F37A22000059; Sun, 6 Sep 2009 18:45:50 +0200 (CEST) Received: from PCdeKimKas (AMontsouris-153-1-44-56.w90-2.abo.wanadoo.fr [90.2.203.56]) by mwinf2013.orange.fr (SMTP Server) with SMTP id AAAE620000AE; Sun, 6 Sep 2009 18:45:50 +0200 (CEST) X-ME-UUID: 20090906164550699.AAAE620000AE@mwinf2013.orange.fr Message-ID: From: "Aman Jassal" To: , "Mike Tancsa" References: <200909061625.n86GPp9l055756@lava.sentex.ca> In-Reply-To: <200909061625.n86GPp9l055756@lava.sentex.ca> Date: Sun, 6 Sep 2009 18:44:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Cc: Subject: Re: Problems with IPSec during kernel compilation with sources from CURRENT 9.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 16:45:52 -0000 Hello Mike, Oh ok... I knew I was missing something really obvious but I just couldn't put my finger on it >_<. Thank you for enlightning me :) Aman Jassal ----- Original Message ----- From: "Mike Tancsa" To: "Aman Jassal" ; Sent: Sunday, September 06, 2009 6:29 PM Subject: Re: Problems with IPSec during kernel compilation with sources from CURRENT 9.0 > At 10:52 AM 9/6/2009, Aman Jassal wrote: >>I then performed a kernel compilation to upgrade it, and since I wanted to >>test out IPSec, I added the following lines in my kernel configuration >>file : >> >>Options IPSEC >>Options IPSEC_DEBUG > > Hi, > You need to add > > device crypto > > to the kernel as well > > ---Mike > > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 18:50:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9B19106566C; Sun, 6 Sep 2009 18:50:45 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id 9A14B8FC12; Sun, 6 Sep 2009 18:50:44 +0000 (UTC) Received: by fxm6 with SMTP id 6so1557298fxm.43 for ; Sun, 06 Sep 2009 11:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=mndJOjH626+B8/55Hv93Skr/kC47kU9QJueOhGuUpTs=; b=q7DtWwZ6uY6JQbHbySOjug3TjABUPVPHDCmNuy1CY8PJTdcSpLy5xePK8wzuyZXizs jz3Pu+29sOUEgLV6CJrHofaGO8wJsBhIvNXZztPqm3xXi93xmRxoqpCDKttshf6XyAKW 0HzQlmfzQLSoAxuLOXLvVSes5Rp2bmNQ6mAVw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=NRJeEznWmpWc60Nv+lhCA7Kb7LKqGYg2KJDPIkg/KFkG3LfQVMBnLuyK8VAI7IZ6Xy JY9XJZL2Qo6wKIrmAwOdQU6a0WhRsp+4wJ505/wvYtrwhlQY1L2ATQ1s7119OnU7bCH/ rlmnGMDTR1N2a8qIKR3SCWIJoODamCd0hLpYw= MIME-Version: 1.0 Received: by 10.204.13.198 with SMTP id d6mr11310721bka.188.1252263043245; Sun, 06 Sep 2009 11:50:43 -0700 (PDT) In-Reply-To: <20090906162544.GA39448@bsdcrew.de> References: <20090611194557.GC98175@bsdcrew.de> <991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com> <20090906162544.GA39448@bsdcrew.de> From: Odhiambo Washington Date: Sun, 6 Sep 2009 21:50:23 +0300 Message-ID: <991123400909061150h56dc6e07uf8d8e721f6c923bf@mail.gmail.com> To: Martin Wilke Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 18:50:45 -0000 On Sun, Sep 6, 2009 at 7:25 PM, Martin Wilke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sun, Sep 06, 2009 at 06:11:48PM +0300, Odhiambo Washington wrote: > > On Sun, Sep 6, 2009 at 1:40 PM, Danny Braniss > wrote: > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > Huhu, > > > > > > > > Yes we life and that's good :-). > > > > Changes: > > > > > > > > - Fix build error when compiling in debug mode on FreeBSD HEAD > > > > - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite > timeout. > > > > - Some FreeBSD relate typos > > > > - Enable shared OpenGL service. Completely untested due to lack of > > > > appropriate hardware but it compiles at least > > > > - Add support for shared clipboards. Requires libXt > > > > - FreeBSD: Implement preemption API for guest SMP and enable > > > > it (slightly tested). Add neccessary RTMP* methods in userspace > > > > for the frontends to detect the number of CPUs > > > > - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex > > > > instead of a spinlock to fix the problems users are seeing > > > > (assertions with debugging enabled) while still being able > > > > to run on 100Hz hosts. No problems detected so far and Solaris > > > > doesn't use a spin mutex in this code too so it shouldn't do > > > > any harm (keeping fingers crossed)space for the frontends to > > > > detect the number of CPUs > > > > - Add support for curl > > > > - Add VBoxSharedClipboard > > > > > > > > Ports Changes; > > > > - Force guestadditions version to 2.2.4 > > > > - Removed Qt3 include replacements (already upstream) > > > > - Removed cosmetic X11 include path patch > > > > > > > > Please make SURE, your world and kernel is in sync and you've read > > > > the pkg-messages. Also please unload the kernel module before > > > > you update the port ;-). > > > > > > > > Many thx to all Vbox Devs, All supporters, my nice team! :-) > > > > > > > > http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz > > > > > > > > > Happy Testing! > > > > > > > ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no > > > longer available, there is a > > > > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2 > > > then again in ports/emulatores/virtualbox the version is 3.0.51r22226, > > > > > > can someone please explain? > > > > > > > > > > > > And on my FreeBSD 7.2-STABLE, compiling virtualbox fails as follows: > > > > > > > > kBuild: Linking VBoxREM64 > > kBuild: Installing VBoxREM64 => > > > /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBox > > REM64.so > > kmk[2]: Leaving directory > > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' > > kmk[1]: Leaving directory > > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' > > kBuild: Pass - Programs > > kmk[1]: Entering directory > > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' > > kmk[2]: Entering directory > > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' > > kBuild: Compiling tstAPI - > > > /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/src/VBox/Main/testcase/tstAPI.cpp > > kBuild: Linking tstAPI > > /usr/local/lib/libssl.so.5: undefined reference to `d2i_X509_EXTENSIONS' > > /usr/local/lib/libssl.so.5: undefined reference to > > `ENGINE_get_ssl_client_cert_function' > > /usr/local/lib/libssl.so.5: undefined reference to `HMAC_CTX_set_flags' > > /usr/local/lib/libssl.so.5: undefined reference to `i2d_X509_EXTENSIONS' > > /usr/local/lib/libssl.so.5: undefined reference to > > `ENGINE_load_ssl_client_cert' > > /usr/local/lib/libssl.so.5: undefined reference to `pqueue_size' > > /usr/local/lib/libssl.so.5: undefined reference to `EVP_idea_cbc' > > kmk[2]: *** > > > [/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/obj/tstAPI/tstAPI] > > Error 1 > > The failing command: > > @g++ '-Wl,-rpath,/usr/local/lib/virtualbox' -m32 -o > > /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r > > 22226/out/freebsd.x86/release/obj/tstAPI/tstAPI > > > /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/ > > release/obj/tstAPI/tstAPI.o -L/usr/lib -L/usr/X11R6/lib > > -L/usr/local/lib > > /usr/ports/emulators/virtualbox/work/virtualbo > > x-3.0.51r22226/out/freebsd.x86/release/bin/VBoxRT.so > > /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freeb > > sd.x86/release/lib/VBoxCOM.a > > > /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBoxX > > PCOM.so > > kmk[2]: Leaving directory > > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' > > kmk[1]: *** [pass_binaries_this] Error 2 > > kmk[1]: Leaving directory > > `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' > > kmk: *** [pass_binaries_order] Error 2 > > *** Error code 2 > > > > Stop in /usr/ports/emulators/virtualbox. > > > > > > I hope someone can advise on what is needed. > > > > deinstall openssl from ports and try again :) > > I remember we had this suggestion before, and either you (or someone else) was going to look into the use of openssl from the ports:-) Looks like I will have to recompile most apps that have linked against openssl, no? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "If you have nothing good to say about someone, just shut up!." -- Lucky Dube From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 19:32:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D509D1065679; Sun, 6 Sep 2009 19:32:00 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from kennaway-macbookpro.config (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0AC678FC21; Sun, 6 Sep 2009 19:31:58 +0000 (UTC) Message-ID: <4AA40E30.50109@FreeBSD.org> Date: Sun, 06 Sep 2009 20:32:00 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Pawel Jakub Dawidek , Kip Macy , FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: panic: sx_xlock() of destroyed sx @ /zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 19:32:01 -0000 9.0 doing I/O to a zfs: panic: sx_xlock() of destroyed sx @ /zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535 db> wh Tracing pid 14 tid 100047 td 0xffffff000357c720 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b _sx_xlock() at _sx_xlock+0xe9 zfs_range_unlock() at zfs_range_unlock+0x38 zfs_get_data() at zfs_get_data+0xd7 zil_commit() at zil_commit+0x532 zfs_sync() at zfs_sync+0xa6 sync_fsync() at sync_fsync+0x13a VOP_FSYNC_APV() at VOP_FSYNC_APV+0xb7 sync_vnode() at sync_vnode+0x157 sched_sync() at sched_sync+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8125da0d30, rbp = 0 --- This was essentially just doing make world + cvs update + tar creation in a loop and failed after about a week. Kris From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 19:43:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05CEE106566C for ; Sun, 6 Sep 2009 19:43:22 +0000 (UTC) (envelope-from ziggi@yandex.ru) Received: from forward15.yandex.ru (forward15.yandex.ru [95.108.130.119]) by mx1.freebsd.org (Postfix) with ESMTP id 8B8BB8FC17 for ; Sun, 6 Sep 2009 19:43:21 +0000 (UTC) Received: from smtp11.yandex.ru (smtp11.yandex.ru [95.108.130.67]) by forward15.yandex.ru (Yandex) with ESMTP id 99093C01FA for ; Sun, 6 Sep 2009 23:31:36 +0400 (MSD) Received: from eee.home (46-232-55-95.baltnet.ru [95.55.232.46]) by smtp11.yandex.ru (Yandex) with ESMTPA id 04B2D673007D for ; Sun, 6 Sep 2009 23:31:35 +0400 (MSD) Message-ID: <4AA40E17.5010906@yandex.ru> Date: Sun, 06 Sep 2009 22:31:35 +0300 From: Borodin Oleg User-Agent: Thunderbird 2.0.0.22 (X11/20090806) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1252265496 X-Yandex-Spam: 1 X-Yandex-Front: smtp11.yandex.ru Subject: wpa_supplicant not found AP without SSID in beacon packet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 19:43:22 -0000 Hi! wpa_supplicant "not found" AP without SSID in beacon packets. With same device and configuration, but FreeBSD7.2 - work without problems. uname: FreeBSD flashbsd.home 8.0-BETA3 FreeBSD 8.0-BETA3 #4 r196775: Thu Sep 3 13:12:37 EEST 2009 ziggi@eee.home:/usr/obj/usr/src/sys/EEE04 i386 wireless device: ath0: mem 0xfbef0000-0xfbefffff irq 18 at device 0.0 on pci1 ath0@pci0:1:0:0: class=0x020000 card=0x10261a3b chip=0x001c168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5006 family 802.11abg Wireless NIC' class = network subclass = ethernet Access point - Cisco 877w, IOS 12.4T8 ----------- Variant 1. SSID not send in beacon packets from Cisco access point - Cisco conf fragment : ! dot11 mbssid ! dot11 ssid WNET1 vlan 1 authentication open. authentication key-management wpa wpa-psk ascii 7 10682F4857474B2D2A ! dot11 ssid WNET2 vlan 2 authentication open. authentication key-management wpa wpa-psk ascii 7 15342D5D567A72020E ! dot11 ssid WNET3 vlan 3 authentication open. authentication key-management wpa wpa-psk ascii 7 0220220A595656076A ! Result FreeBSD8Beta3 wpa_suplicant & wlandebug: Starting AP scan (broadcast SSID) wlan0: ieee80211_ioctl_scanreq: flags 0x52 duration 0x7fffffff mindwell 0 maxdwe ll 0 nssid 0 wlan0: ieee80211_check_scan: active scan, append, nojoin, once wlan0: sta_pick_bss: no scan candidate wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0 maxdwell 0 , desired mode auto, append, nojoin, once wlan0: scan set 1g, 6g, 11g, 7g, 13g, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 12g, 14b dwel l min 20ms max 200ms wlan0: scan_task: chan 3g -> 1g [active, dwell min 20ms max 200ms] wlan0: send probe req on channel 1 bssid ff:ff:ff:ff:ff:ff ssid "" wlan0: received beacon from 00:23:5e:75:f7:c0 rssi 45 wlan0: [00:23:5e:75:f7:c0] discard unhandled information element, id 133, len 30 <-------- ???? wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3 wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 44 wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id 133, len 30 wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3 wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 46 wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id 133, len 30 wlan0: [00:23:5e:75:f7:c2] discard beacon frame, for off-channel 3 wlan0: scan_task: chan 1g -> 6g [active, dwell min 20ms max 200ms] wlan0: send probe req on channel 6 bssid ff:ff:ff:ff:ff:ff ssid "" wlan0: scan_task: chan 6g -> 11g [active, dwell min 20ms max 200ms] wlan0: send probe req on channel 11 bssid ff:ff:ff:ff:ff:ff ssid "" wlan0: scan_task: chan 11g -> 7g [active, dwell min 20ms max 200ms] wlan0: send probe req on channel 7 bssid ff:ff:ff:ff:ff:ff ssid "" wlan0: scan_task: chan 7g -> 13g [passive, dwell min 20ms max 200ms] EAPOL: disable timer tick wlan0: scan_task: chan 13g -> 2g [active, dwell min 20ms max 200ms] wlan0: send probe req on channel 2 bssid ff:ff:ff:ff:ff:ff ssid "" wlan0: received beacon from 00:23:5e:75:f7:c1 rssi 56 wlan0: [00:23:5e:75:f7:c1] discard unhandled information element, id 133, len 30 ... [00:23:5e:75:f7:c1] new beacon on chan 3 (bss chan 3) 0x00 rssi 55 [00:23:5e:75:f7:c1] caps 0x431 bintval 100 erp 0x100 wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 53 wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id 133, len 30 [00:23:5e:75:f7:c2] new beacon on chan 3 (bss chan 3) 0x00 rssi 53 [00:23:5e:75:f7:c2] caps 0x431 bintval 100 erp 0x100 wlan0: scan_task: chan 3g -> 4g [active, dwell min 20ms max 200ms] wlan0: send probe req on channel 4 bssid ff:ff:ff:ff:ff:ff ssid "" wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 52 wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id 133, len 30 ... Scan results: 3 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch Try to find non-WPA AP 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch No suitable AP found. <--------------------- Setting scan request: 5 sec 0 usec ---------------- 2 On _any_ SSID in beacon packet: dot11 ssid WNET1 vlan 1 authentication open authentication key-management wpa mbssid guest-mode <--------------------------- On SSID sending wpa-psk ascii 7 10682F4857474B2D2A ! dot11 ssid WNET2 vlan 2 authentication open authentication key-management wpa wpa-psk ascii 7 15342D5D567A72020E ! dot11 ssid WNET3 vlan 3 authentication open authentication key-management wpa wpa-psk ascii 7 0220220A595656076A ! Result wpa_supplicant: Received 0 bytes of scan results (3 BSSes) Scan results: 3 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 2: 00:23:5e:75:f7:c0 ssid='WNET1' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 selected based on WPA IE selected WPA AP 00:23:5e:75:f7:c0 ssid='WNET1' <---------------------------------------- Trying to associate with 00:23:5e:75:f7:c0 (SSID='WNET1' freq=2422 MHz) Cancelling scan request /etc/wpa_upplicant.conf: # $Id$ ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel #eapol_version=1 #ap_scan=1 fast_reauth=1 network={ ssid="WNET1" # scan_ssid=1 proto=RSN WPA key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP psk=8c23bb58a1a94b3b56b90d8f7422a29b18f495b517f33fc6728ff2a3ad4aae1f } #EOF -- Best regards, Borodin Oleg Kaliningrad,Russia ziggi@inbox.ru From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 19:46:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5537C106566C for ; Sun, 6 Sep 2009 19:46:05 +0000 (UTC) (envelope-from ziggi@yandex.ru) Received: from forward11.yandex.ru (forward11.yandex.ru [95.108.130.93]) by mx1.freebsd.org (Postfix) with ESMTP id D99C28FC13 for ; Sun, 6 Sep 2009 19:46:04 +0000 (UTC) Received: from smtp12.yandex.ru (smtp12.yandex.ru [95.108.131.191]) by forward11.yandex.ru (Yandex) with ESMTP id 60C5DF48152 for ; Sun, 6 Sep 2009 23:40:22 +0400 (MSD) Received: from eee.home (46-232-55-95.baltnet.ru [95.55.232.46]) by smtp12.yandex.ru (Yandex) with ESMTPA id C62D44CC003C for ; Sun, 6 Sep 2009 23:40:21 +0400 (MSD) Message-ID: <4AA41025.5080908@yandex.ru> Date: Sun, 06 Sep 2009 22:40:21 +0300 From: Borodin Oleg User-Agent: Thunderbird 2.0.0.22 (X11/20090806) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1252266022 X-Yandex-Spam: 1 X-Yandex-Front: smtp12.yandex.ru Subject: wpa_supplicant not found AP without SSID in beacon packet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 19:46:05 -0000 Hi! wpa_supplicant "not found" AP without SSID in beacon packets. With same device and configuration, but FreeBSD7.2 - work without problems. uname: FreeBSD flashbsd.home 8.0-BETA3 FreeBSD 8.0-BETA3 #4 r196775: Thu Sep 3 13:12:37 EEST 2009 ziggi@eee.home:/usr/obj/usr/src/sys/EEE04 i386 wireless device: ath0: mem 0xfbef0000-0xfbefffff irq 18 at device 0.0 on pci1 ath0@pci0:1:0:0: class=0x020000 card=0x10261a3b chip=0x001c168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5006 family 802.11abg Wireless NIC' class = network subclass = ethernet Access point - Cisco 877w, IOS 12.4T8 ----------- Variant 1. SSID not send in beacon packets from Cisco access point - Cisco conf fragment : ! dot11 mbssid ! dot11 ssid WNET1 vlan 1 authentication open. authentication key-management wpa wpa-psk ascii 7 10682F4857474B2D2A ! dot11 ssid WNET2 vlan 2 authentication open. authentication key-management wpa wpa-psk ascii 7 15342D5D567A72020E ! dot11 ssid WNET3 vlan 3 authentication open. authentication key-management wpa wpa-psk ascii 7 0220220A595656076A ! Result FreeBSD8Beta3 wpa_suplicant & wlandebug: Starting AP scan (broadcast SSID) wlan0: ieee80211_ioctl_scanreq: flags 0x52 duration 0x7fffffff mindwell 0 maxdwe ll 0 nssid 0 wlan0: ieee80211_check_scan: active scan, append, nojoin, once wlan0: sta_pick_bss: no scan candidate wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0 maxdwell 0 , desired mode auto, append, nojoin, once wlan0: scan set 1g, 6g, 11g, 7g, 13g, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 12g, 14b dwel l min 20ms max 200ms wlan0: scan_task: chan 3g -> 1g [active, dwell min 20ms max 200ms] wlan0: send probe req on channel 1 bssid ff:ff:ff:ff:ff:ff ssid "" wlan0: received beacon from 00:23:5e:75:f7:c0 rssi 45 wlan0: [00:23:5e:75:f7:c0] discard unhandled information element, id 133, len 30 <-------- ???? wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3 wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 44 wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id 133, len 30 wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3 wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 46 wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id 133, len 30 wlan0: [00:23:5e:75:f7:c2] discard beacon frame, for off-channel 3 wlan0: scan_task: chan 1g -> 6g [active, dwell min 20ms max 200ms] wlan0: send probe req on channel 6 bssid ff:ff:ff:ff:ff:ff ssid "" wlan0: scan_task: chan 6g -> 11g [active, dwell min 20ms max 200ms] wlan0: send probe req on channel 11 bssid ff:ff:ff:ff:ff:ff ssid "" wlan0: scan_task: chan 11g -> 7g [active, dwell min 20ms max 200ms] wlan0: send probe req on channel 7 bssid ff:ff:ff:ff:ff:ff ssid "" wlan0: scan_task: chan 7g -> 13g [passive, dwell min 20ms max 200ms] EAPOL: disable timer tick wlan0: scan_task: chan 13g -> 2g [active, dwell min 20ms max 200ms] wlan0: send probe req on channel 2 bssid ff:ff:ff:ff:ff:ff ssid "" wlan0: received beacon from 00:23:5e:75:f7:c1 rssi 56 wlan0: [00:23:5e:75:f7:c1] discard unhandled information element, id 133, len 30 ... [00:23:5e:75:f7:c1] new beacon on chan 3 (bss chan 3) 0x00 rssi 55 [00:23:5e:75:f7:c1] caps 0x431 bintval 100 erp 0x100 wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 53 wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id 133, len 30 [00:23:5e:75:f7:c2] new beacon on chan 3 (bss chan 3) 0x00 rssi 53 [00:23:5e:75:f7:c2] caps 0x431 bintval 100 erp 0x100 wlan0: scan_task: chan 3g -> 4g [active, dwell min 20ms max 200ms] wlan0: send probe req on channel 4 bssid ff:ff:ff:ff:ff:ff ssid "" wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 52 wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id 133, len 30 ... Scan results: 3 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch Try to find non-WPA AP 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch No suitable AP found. <--------------------- Setting scan request: 5 sec 0 usec ---------------- 2 On _any_ SSID in beacon packet: dot11 ssid WNET1 vlan 1 authentication open authentication key-management wpa mbssid guest-mode <--------------------------- On SSID sending wpa-psk ascii 7 10682F4857474B2D2A ! dot11 ssid WNET2 vlan 2 authentication open authentication key-management wpa wpa-psk ascii 7 15342D5D567A72020E ! dot11 ssid WNET3 vlan 3 authentication open authentication key-management wpa wpa-psk ascii 7 0220220A595656076A ! Result wpa_supplicant: Received 0 bytes of scan results (3 BSSes) Scan results: 3 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 skip - SSID mismatch 2: 00:23:5e:75:f7:c0 ssid='WNET1' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 selected based on WPA IE selected WPA AP 00:23:5e:75:f7:c0 ssid='WNET1' <---------------------------------------- Trying to associate with 00:23:5e:75:f7:c0 (SSID='WNET1' freq=2422 MHz) Cancelling scan request /etc/wpa_upplicant.conf: # $Id$ ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel #eapol_version=1 #ap_scan=1 fast_reauth=1 network={ ssid="WNET1" # scan_ssid=1 proto=RSN WPA key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP psk=8c23bb58a1a94b3b56b90d8f7422a29b18f495b517f33fc6728ff2a3ad4aae1f } #EOF -- Best regards, Borodin Oleg Kaliningrad,Russia ziggi@inbox.ru From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 20:08:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A31E21065676 for ; Sun, 6 Sep 2009 20:08:56 +0000 (UTC) (envelope-from oliver@namp.de) Received: from grisu.qmail-ldap.de (grisu.qmail-ldap.de [78.46.218.233]) by mx1.freebsd.org (Postfix) with ESMTP id 0EA998FC1B for ; Sun, 6 Sep 2009 20:08:55 +0000 (UTC) Received: (qmail 41747 invoked from network); 6 Sep 2009 19:46:02 -0000 Received: from unknown (HELO mail.kuehlbox.de) (oliver@namp.de@[78.46.218.233]) (envelope-sender ) by grisu.qmail-ldap.de (qmail-ldap-1.03) with SMTP for ; 6 Sep 2009 19:46:02 -0000 Received: from: grisu.qmail-ldap.de ([78.46.218.233]) by HSF smtp proxy MIME-Version: 1.0 X-Priority: Normal X-Mailer: AtMail 1.03 Message-ID: <60533.1252266359@namp.de> To: X-Origin: 88.217.58.8 X-Atmail-Account: oliver@namp.de Date: Sun, 6 Sep 2009 21:45:59 +0200 From: Oliver Fakler X-Mailman-Approved-At: Sun, 06 Sep 2009 22:05:43 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: boot from raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: oliver@namp.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 20:08:56 -0000 =20 Hi all, i installed a 8.0 beta 3 amd64 based testsystem. i tried with a root on a raidz, but i have a problem after the first reboot, there is a error message: can't load kernel I found something that boot root from raidz is not supported, but maybe there is a solution?? Hope some can help me Greets Oliver From owner-freebsd-current@FreeBSD.ORG Sun Sep 6 23:53:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39704106568D for ; Sun, 6 Sep 2009 23:53:02 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 013088FC13 for ; Sun, 6 Sep 2009 23:53:01 +0000 (UTC) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n86Nqpox056580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Sep 2009 16:52:52 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4AA44B53.8060702@errno.com> Date: Sun, 06 Sep 2009 16:52:51 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Borodin Oleg References: <4AA41025.5080908@yandex.ru> In-Reply-To: <4AA41025.5080908@yandex.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant not found AP without SSID in beacon packet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 23:53:02 -0000 Borodin Oleg wrote: > > Hi! > > wpa_supplicant "not found" AP without SSID in beacon packets. With same > device and configuration, but FreeBSD7.2 - work without problems. > > uname: > FreeBSD flashbsd.home 8.0-BETA3 FreeBSD 8.0-BETA3 #4 r196775: Thu Sep 3 > 13:12:37 EEST 2009 > ziggi@eee.home:/usr/obj/usr/src/sys/EEE04 i386 > > wireless device: > ath0: mem 0xfbef0000-0xfbefffff irq 18 at device 0.0 > on pci1 > ath0@pci0:1:0:0: class=0x020000 card=0x10261a3b chip=0x001c168c > rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR5006 family 802.11abg Wireless NIC' > class = network > subclass = ethernet > > Access point - Cisco 877w, IOS 12.4T8 > > ----------- Variant 1. SSID not send in beacon packets from Cisco access > point - > Cisco conf fragment : > ! > dot11 mbssid > ! > dot11 ssid WNET1 > vlan 1 > authentication open. > authentication key-management wpa > wpa-psk ascii 7 10682F4857474B2D2A > ! > dot11 ssid WNET2 > vlan 2 > authentication open. > authentication key-management wpa > wpa-psk ascii 7 15342D5D567A72020E > ! > dot11 ssid WNET3 > vlan 3 > authentication open. > authentication key-management wpa > wpa-psk ascii 7 0220220A595656076A > ! > > Result FreeBSD8Beta3 wpa_suplicant & wlandebug: > > Starting AP scan (broadcast SSID) > wlan0: ieee80211_ioctl_scanreq: flags 0x52 duration 0x7fffffff mindwell > 0 maxdwe > ll 0 nssid 0 > wlan0: ieee80211_check_scan: active scan, append, nojoin, once > wlan0: sta_pick_bss: no scan candidate > wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0 > maxdwell 0 > , desired mode auto, append, nojoin, once > wlan0: scan set 1g, 6g, 11g, 7g, 13g, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 12g, > 14b dwel > l min 20ms max 200ms > wlan0: scan_task: chan 3g -> 1g [active, dwell min 20ms max 200ms] > wlan0: send probe req on channel 1 bssid ff:ff:ff:ff:ff:ff ssid "" > wlan0: received beacon from 00:23:5e:75:f7:c0 rssi 45 > wlan0: [00:23:5e:75:f7:c0] discard unhandled information element, id > 133, len 30 <-------- ???? > > wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3 > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 44 > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id > 133, len 30 > > wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3 > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 46 > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id > 133, len 30 > > wlan0: [00:23:5e:75:f7:c2] discard beacon frame, for off-channel 3 > wlan0: scan_task: chan 1g -> 6g [active, dwell min 20ms max 200ms] > wlan0: send probe req on channel 6 bssid ff:ff:ff:ff:ff:ff ssid "" > wlan0: scan_task: chan 6g -> 11g [active, dwell min 20ms max 200ms] > wlan0: send probe req on channel 11 bssid ff:ff:ff:ff:ff:ff ssid "" > wlan0: scan_task: chan 11g -> 7g [active, dwell min 20ms max 200ms] > wlan0: send probe req on channel 7 bssid ff:ff:ff:ff:ff:ff ssid "" > wlan0: scan_task: chan 7g -> 13g [passive, dwell min 20ms max 200ms] > EAPOL: disable timer tick > wlan0: scan_task: chan 13g -> 2g [active, dwell min 20ms max 200ms] > wlan0: send probe req on channel 2 bssid ff:ff:ff:ff:ff:ff ssid "" > wlan0: received beacon from 00:23:5e:75:f7:c1 rssi 56 > wlan0: [00:23:5e:75:f7:c1] discard unhandled information element, id > 133, len 30 > ... > [00:23:5e:75:f7:c1] new beacon on chan 3 (bss chan 3) 0x00 rssi 55 > [00:23:5e:75:f7:c1] caps 0x431 bintval 100 erp 0x100 > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 53 > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id > 133, len 30 > > [00:23:5e:75:f7:c2] new beacon on chan 3 (bss chan 3) 0x00 rssi 53 > [00:23:5e:75:f7:c2] caps 0x431 bintval 100 erp 0x100 > wlan0: scan_task: chan 3g -> 4g [active, dwell min 20ms max 200ms] > wlan0: send probe req on channel 4 bssid ff:ff:ff:ff:ff:ff ssid "" > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 52 > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id > 133, len 30 > ... > Scan results: 3 > CTRL-EVENT-SCAN-RESULTS > Selecting BSS from priority group 0 > Try to find WPA-enabled AP > 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > Try to find non-WPA AP > 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > No suitable AP found. <--------------------- > Setting scan request: 5 sec 0 usec > > ---------------- 2 On _any_ SSID in beacon packet: > > dot11 ssid WNET1 > vlan 1 > authentication open > authentication key-management wpa > mbssid guest-mode <--------------------------- On SSID sending > wpa-psk ascii 7 10682F4857474B2D2A > ! > dot11 ssid WNET2 > vlan 2 > authentication open > authentication key-management wpa > wpa-psk ascii 7 15342D5D567A72020E > ! > dot11 ssid WNET3 > vlan 3 > authentication open > authentication key-management wpa > wpa-psk ascii 7 0220220A595656076A > ! > > Result wpa_supplicant: > > Received 0 bytes of scan results (3 BSSes) > Scan results: 3 > CTRL-EVENT-SCAN-RESULTS > Selecting BSS from priority group 0 > Try to find WPA-enabled AP > 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > 2: 00:23:5e:75:f7:c0 ssid='WNET1' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > selected based on WPA IE > selected WPA AP 00:23:5e:75:f7:c0 ssid='WNET1' > <---------------------------------------- > Trying to associate with 00:23:5e:75:f7:c0 (SSID='WNET1' freq=2422 MHz) > Cancelling scan request > > > > /etc/wpa_upplicant.conf: > # $Id$ > ctrl_interface=/var/run/wpa_supplicant > ctrl_interface_group=wheel > #eapol_version=1 > #ap_scan=1 > fast_reauth=1 > network={ > ssid="WNET1" > # scan_ssid=1 > proto=RSN WPA > key_mgmt=WPA-PSK > pairwise=CCMP TKIP > group=CCMP TKIP > psk=8c23bb58a1a94b3b56b90d8f7422a29b18f495b517f33fc6728ff2a3ad4aae1f > } > #EOF You seem to have disabled scan_ssid in your wpa_supplicant.conf file. It appears this causes wpa_supplicant to not supply the ssid when scanning so the net80211 layer never sends directed ProbeRequest frames and then ap does not respond. Try enabling scan_ssid for WNET1 and verify the directed probe request frames are sent. Sam From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 05:41:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89507106566C; Mon, 7 Sep 2009 05:41:38 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 30D608FC1C; Mon, 7 Sep 2009 05:41:37 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1MkWyt-000Eoi-1c; Mon, 07 Sep 2009 08:41:35 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Martin Wilke In-reply-to: <20090906162544.GA39448@bsdcrew.de> References: <20090611194557.GC98175@bsdcrew.de> <991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com> <20090906162544.GA39448@bsdcrew.de> Comments: In-reply-to Martin Wilke message dated "Sun, 06 Sep 2009 18:25:45 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Sep 2009 08:41:34 +0300 From: Danny Braniss Message-ID: Cc: ports@freebsd.org, Odhiambo Washington , freebsd-current@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 05:41:38 -0000 [...] > > > > > > > ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no > > > longer available, there is a > > > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2 > > > then again in ports/emulatores/virtualbox the version is 3.0.51r22226, > > > > > > can someone please explain? hi, the above was my question, which was totally ignored, not nice. I will try and refrase it: the call for testing is for a version (2.2.51r20457) which is not available, while the ports is 3.0.51r22226, so while I managed to compile it, it complains that COM is not running, all this under 8BETA-3, both under 32 and 64 bit. thnaks, danny From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 10:40:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3ACE8106566B for ; Mon, 7 Sep 2009 10:40:08 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mx01.netsrc.de (mx01.netsrc.de [89.107.71.100]) by mx1.freebsd.org (Postfix) with ESMTP id BE3C58FC16 for ; Mon, 7 Sep 2009 10:40:07 +0000 (UTC) Received: from [10.22.2.189] (unknown [212.185.121.50]) by mx01.netsrc.de (Postfix) with ESMTP id 40F64192FD9; Mon, 7 Sep 2009 12:40:06 +0200 (CEST) From: Bernhard Schmidt To: oliver@namp.de In-Reply-To: <27537.1252314818@namp.de> X-Priority: Normal References: <27537.1252314818@namp.de> Message-Id: <168D71B8-F31B-43A8-9110-9C273EA8F97A@techwires.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Sep 2009 12:40:05 +0200 X-Mailer: Apple Mail (2.936) Cc: freebsd-current@freebsd.org Subject: Re: boot from raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 10:40:08 -0000 Am 07.09.2009 um 11:13 schrieb Oliver Fakler: > > BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; } > > On Mon 07/09/09 10:07 , Bernhard Schmidt =20 > wrote: > > > Am 06.09.2009 um 21:45 schrieb Oliver Fakler: > > > > > > > Hi all, > > > > i installed a 8.0 beta 3 amd64 based testsystem. > > > > i tried with a root on a raidz, but i have a problem after the first > > reboot, there is a error message: > > > > can't load kernel > > I found something that boot root from raidz is not supported, but > > maybe there is a solution?? > > Hope some can help me > > > There are patches from Doug Rabson which add support for booting from > raidz/raidz2. > > = http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html=20= > " = target=3D"_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-Decem= ber/005498.html Seems that patch made it already into the tree (r192194). > > > I tried it, but after a make obj && make depend the make failed with =20= > different errors like undeclared and has no member named. > > I used patch raidzboot-14052009.diff started patching from /usr/src/=20= > sys/ , i'm not sure if this was the right way. > > I'm also not sure if the way of installation was the right one, =20 > here's the way i go: > > > gpart create -s GPT da0 > gpart add -b 34 -s 128 -t freebsd-boot da0 > gpart add -b 162 -s 5242880 -t freebsd-swap da0 > gpart add -b 5243042 -s 11534141 -t freebsd-zfs da0 > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da0 > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da1 > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da2 > Can you try zfsboot instead of gptzfsboot? = http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.ht= ml=20 at the end of the mail. > > > kldload /mnt2/boot/kernel/opensolaris.ko > kldload /mnt2/boot/kernel/zfs.ko > > zpool create tank raidz da0p3 da1p1 d2p1 > > zfs create tank/tmp > zfs create tank/usr > zfs create tank/var > > cd /dist/8.0-BETA3/base > export DESTDIR=3D/tank > ./install.sh > You are about to extract the base distribution into /tank - are you =20= > SURE > you want to do this over your installed system (y/n)? y > cd ../kernels > ./install.sh generic > cd /tank/boot > cp -Rp GENERIC/* kernel/ > > cd /dist/8.0-BETA3/src > ./install.sh all > Extracting sources into /usr/src... > Extracting source component: base > Extracting source component: bin > Extracting source component: cddl > Extracting source component: contrib > Extracting source component: crypto > Extracting source component: etc > Extracting source component: games > Extracting source component: gnu > Extracting source component: include > Extracting source component: krb5 > Extracting source component: lib > Extracting source component: libexec > Extracting source component: release > Extracting source component: rescue > Extracting source component: sbin > Extracting source component: secure > Extracting source component: share > Extracting source component: sys > Extracting source component: tools > Extracting source component: ubin > Extracting source component: usbin > Done extracting sources. > Done extracting sources. > cd ../manpages > ./install.sh > > echo 'zfs_enable=3D"YES"' > /tank/etc/rc.conf > echo 'LOADER_ZFS_SUPPORT=3D"YES"' > /tank/etc/src.conf > echo 'zfs_load=3D"YES"' > /tank/boot/loader.conf > echo 'vfs.root.mountfrom=3D"zfs:tank"' >> /tank/boot/loader.conf > echo =B4/dev/da0p2 none swap sw 0 0=B4>> /tank/etc/fstab > > mkdir /boot/zfs > zpool export tank && zpool import tank > cp /boot/zfs/zpool.cache /tank/boot/zfs/ > > chroot /tank > mount -t devfs devfs /dev > unset DESTDIR > cd /usr/src/sys/boot/ > make obj > make depend > make > cd i386/loader > make install > umount /dev > touch /etc/fstab > exit > > export LD_LIBRARY_PATH=3D/mnt2/lib > zfs set mountpoint=3Dlegacy tank > zfs set mountpoint=3D/tmp tank/tmp > zfs set mountpoint=3D/var tank/var > zfs set mountpoint=3D/usr tank/usr > zpool set bootfs=3Dtank tank > Seems correct at first glance. -- Bernhard= From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 12:34:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C6201065694 for ; Mon, 7 Sep 2009 12:34:26 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id C84568FC17 for ; Mon, 7 Sep 2009 12:34:25 +0000 (UTC) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 2F34F198E; Mon, 7 Sep 2009 14:34:24 +0200 (CEST) Date: Mon, 7 Sep 2009 14:34:24 +0200 From: Guido Falsi To: Bernhard Schmidt Message-ID: <20090907123423.GB57582@megatron.madpilot.net> References: <27537.1252314818@namp.de> <168D71B8-F31B-43A8-9110-9C273EA8F97A@techwires.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <168D71B8-F31B-43A8-9110-9C273EA8F97A@techwires.net> X-Operating-System: FreeBSD 8.0-BETA3 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, oliver@namp.de Subject: Re: boot from raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 12:34:26 -0000 On Mon, Sep 07, 2009 at 12:40:05PM +0200, Bernhard Schmidt wrote: > > > >echo 'zfs_enable="YES"' > /tank/etc/rc.conf > >echo 'LOADER_ZFS_SUPPORT="YES"' > /tank/etc/src.conf > >echo 'zfs_load="YES"' > /tank/boot/loader.conf > >echo 'vfs.root.mountfrom="zfs:tank"' >> /tank/boot/loader.conf [...] > > > Seems correct at first glance. two things come to my mind: are we sure the loader you have installed(the ones from the distribution CD I think) was compiled with LOADER_ZFS_SUPPORT="YES" set? I don't think this is the case. Usually I have to compile one on another machine(or just grab the one from a similar machine) and overwrite the distribution one. Another thing I notice; have you populated /boot/zfs/zpool.cache ?? -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 12:58:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4E51106568D for ; Mon, 7 Sep 2009 12:58:11 +0000 (UTC) (envelope-from reuf_m@hotmail.com) Received: from blu0-omc2-s30.blu0.hotmail.com (blu0-omc2-s30.blu0.hotmail.com [65.55.111.105]) by mx1.freebsd.org (Postfix) with ESMTP id 6CDFC8FC19 for ; Mon, 7 Sep 2009 12:58:11 +0000 (UTC) Received: from BLU0-SMTP5 ([65.55.111.71]) by blu0-omc2-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 05:46:10 -0700 X-Originating-IP: [212.41.203.145] X-Originating-Email: [reuf_m@hotmail.com] Message-ID: Received: from reuf.1000ordi.net ([212.41.203.145]) by BLU0-SMTP5.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 05:46:09 -0700 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-current@freebsd.org Date: Mon, 07 Sep 2009 14:46:08 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mustabasic Reuf" User-Agent: Opera Mail/10.00 (FreeBSD) X-OriginalArrivalTime: 07 Sep 2009 12:46:09.0798 (UTC) FILETIME=[2CA58260:01CA2FB9] Subject: FreeBSD-8.0BETA[1,2,3,4] hang at boot on iMac X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 12:58:11 -0000 Hi all ! I tried with all BETAs, the resulat is the same (see screenshot : http://i30.tinypic.com/mkhflh.jpg ) iMac is last generation (iMac 9, apr. 2009), 7.2 worked flawlessly. If any additional info is required (ACPI debug output, dmesg...) just make a sign. From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 13:32:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B3FB106566C for ; Mon, 7 Sep 2009 13:32:38 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swipnet.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED6A8FC08 for ; Mon, 7 Sep 2009 13:32:37 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=I4HlZVeg-C8A:10 a=p7f755yT8wqfGVF+fg83Lg==:17 a=IIUwIn6DAAAA:20 a=21t2AlwLnmc2vdOEMJ4A:9 a=g3eAjJ9GgZJQILjLCgmUcQ2cDdMA:4 Received: from [212.4.54.130] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1133886234; Mon, 07 Sep 2009 15:32:36 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 7 Sep 2009 15:33:00 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: In-Reply-To: X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909071533.02121.hselasky@c2i.net> Cc: Mustabasic Reuf Subject: Re: FreeBSD-8.0BETA[1,2,3,4] hang at boot on iMac X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 13:32:38 -0000 On Monday 07 September 2009 16:46:08 Mustabasic Reuf wrote: > Hi all ! > > I tried with all BETAs, the resulat is the same > (see screenshot : http://i30.tinypic.com/mkhflh.jpg ) > > iMac is last generation (iMac 9, apr. 2009), 7.2 worked flawlessly. > > If any additional info is required (ACPI debug output, dmesg...) just make > a sign. Hi, This is likely a known issue related to some recent PAT changes which makes the CPU microcode hang when enabling ACPI. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 14:10:16 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0922106566C for ; Mon, 7 Sep 2009 14:10:16 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 49A438FC14 for ; Mon, 7 Sep 2009 14:10:15 +0000 (UTC) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id n87EADq0020450; Mon, 7 Sep 2009 15:10:13 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Mkev7-0001Sq-9q; Mon, 07 Sep 2009 15:10:13 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n87EAC42066625; Mon, 7 Sep 2009 15:10:12 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n87EACeU066624; Mon, 7 Sep 2009 15:10:12 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Alex Keda In-Reply-To: <4AA384EC.3060003@lissyara.su> References: <4AA384EC.3060003@lissyara.su> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 07 Sep 2009 15:10:12 +0100 Message-Id: <1252332612.55883.10.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-current Subject: Re: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 14:10:16 -0000 On Sun, 2009-09-06 at 13:46 +0400, Alex Keda wrote: > hi! > I have fatal trap with today (and yesterday) current. > Machine boot, I see: > Timecounters tick every 1.000 msec > then, it freese ~30 seconds and go to kernel debugger - fatal trap 12 > stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d At the debugger prompt, can you give the "bt" command, and show us what the output is please? Gavin From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 14:44:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F30D91065679; Mon, 7 Sep 2009 14:44:29 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailD.acsu.buffalo.edu (localmailD.acsu.buffalo.edu [128.205.5.208]) by mx1.freebsd.org (Postfix) with ESMTP id C5D778FC08; Mon, 7 Sep 2009 14:44:29 +0000 (UTC) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6F2CB618C3; Mon, 7 Sep 2009 10:26:43 -0400 (EDT) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailD.acsu.buffalo.edu (Postfix) with ESMTP id C3CBBC1896; Mon, 7 Sep 2009 10:26:41 -0400 (EDT) Received: from mweb2.acsu.buffalo.edu (mweb2.acsu.buffalo.edu [128.205.5.239]) by localmailD.acsu.buffalo.edu (Prefixe) with ESMTP id BC463C1895; Mon, 7 Sep 2009 10:26:41 -0400 (EDT) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) by mweb2.acsu.buffalo.edu (Postfix) with ESMTP id A566A207B4; Mon, 7 Sep 2009 10:26:41 -0400 (EDT) From: Ken Smith To: freebsd-current , freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-xmSWkBgDt4b8l14MH12L" Date: Mon, 07 Sep 2009 10:26:38 -0400 Message-Id: <1252333598.56240.23.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: Subject: 8.0-BETA4 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 14:44:30 -0000 --=-xmSWkBgDt4b8l14MH12L Content-Type: text/plain Content-Transfer-Encoding: quoted-printable The fourth and most likely final BETA build for the FreeBSD 8.0 release cycle is now available. We expect the next test build to be the first if the Release Candidates, RC1. Since BETA3 many bugs that were identified from testing done so far were addressed. Some of the bigger issues were an mbuf leak along with work done in the general IPv6, jail, and usb subsystems. Issues in other areas have been addressed as well. Due to the issues identified in this early phase of testing the schedule for release has been pushed back. The current target for the release itself is September 29th, with two RC builds between now and then. Details about the current target schedule along with much more detail about the current status of the release is available here: http://wiki.freebsd.org/8.0TODO If you notice problems you can report them through the normal Gnats PR system or on the freebsd-current mailing list. I do cross-post announcements to freebsd-stable because this particular release is "about to become a stable branch" but when it comes to watching for issues related to the release most of the developers pay more attention to the freebsd-current list. ISO images for all supported architectures are available on the FTP sites, (sparc64 was uploaded a short time ago and may not be available on some sites yet) and a "memory stick" image is available for amd64/i386 architectures. For amd64/i386 architectures the cdrom and memstick images include the documentation packages this time but no other packages. The DVD image includes a first rough pass at what packages will be available but the list will certainly change between now and release. None of the other images include packages. If you are using csup/cvsup methods to update an older system the branch tag to use is RELENG_8. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, or 8.0-BETA3 can upgrade as follows: =20 # freebsd-update upgrade -r 8.0-BETA4 =20 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. Systems running 8.0-BETA3 may print the warning INDEX-OLD.all: Invalid arguments when downloading updates; this warning is a harmless bug (fixed in 8.0-BETA4) and can be safely ignored. # freebsd-update install =20 The system must be rebooted with the newly installed kernel before continui= ng. =20 # shutdown -r now =20 After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install =20 At this point, users of systems being upgraded from FreeBSD 7.x will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. See: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html for mode details. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install =20 Finally, reboot into 8.0-BETA4: =20 # shutdown -r now MD5/SHA256 checksums for the image files: MD5 (8.0-BETA4-amd64-bootonly.iso) =3D 4215023f0492e959be3c643fef44d448 MD5 (8.0-BETA4-amd64-disc1.iso) =3D f767d33bbaa0af665e33992c1f43cc39 MD5 (8.0-BETA4-amd64-dvd1.iso) =3D ac66ea49d75908607c0fe984f88b7a50 MD5 (8.0-BETA4-amd64-livefs.iso) =3D ead1d6a75cce81a24d3d3b8f0cbc8faf MD5 (8.0-BETA4-amd64-memstick.img) =3D 69629e60befe708b4373871af23d61a3 MD5 (8.0-BETA4-i386-bootonly.iso) =3D db2e16a1a807d124a693743ca7a75992 MD5 (8.0-BETA4-i386-disc1.iso) =3D 30508ce737aa29d0fe2baf2f450ddc83 MD5 (8.0-BETA4-i386-dvd1.iso) =3D 307b28a35bcfbb547ce3afbbad051e89 MD5 (8.0-BETA4-i386-livefs.iso) =3D d65f152bfbd62ea5e3c2e1858bbb89ee MD5 (8.0-BETA4-i386-memstick.img) =3D 5d262034175abd24b27ec7110ebd88a7 MD5 (8.0-BETA4-ia64-bootonly.iso) =3D 5147bd2c2dba2a72ec7f36eb8af0ccb6 MD5 (8.0-BETA4-ia64-disc1.iso) =3D 4da8a10c19c6642175a13aacf5fbf996 MD5 (8.0-BETA4-ia64-disc2.iso) =3D 895fca6034ecec7afb99878dbc93ded9 MD5 (8.0-BETA4-ia64-disc3.iso) =3D 49e440ad63251033bc154b35a48b379e MD5 (8.0-BETA4-ia64-dvd1.iso) =3D 52350dd2bd330fa58271819cb82c5e79 MD5 (8.0-BETA4-ia64-livefs.iso) =3D 93018d3777f360780272188a4473dda5 MD5 (8.0-BETA4-pc98-bootonly.iso) =3D 3c1340312e19f5a14c46fbce001fbafa MD5 (8.0-BETA4-pc98-disc1.iso) =3D 495674329c64d6d60b0d41f0922ac20a MD5 (8.0-BETA4-pc98-livefs.iso) =3D ede97f44cbf9c0205ca0b50b0b7900b9 MD5 (8.0-BETA4-powerpc-bootonly.iso) =3D 71deda0e81c1bfa1c232e85aec7b5852 MD5 (8.0-BETA4-powerpc-disc1.iso) =3D cb437fe6c588035492d30a4c9a4ec7f9 MD5 (8.0-BETA4-powerpc-disc2.iso) =3D 2c59a9fcf633c64fe9462967bbd14a93 MD5 (8.0-BETA4-powerpc-disc3.iso) =3D fb2d9d5a59518d30c28c8454bdf66ed4 MD5 (8.0-BETA4-sparc64-bootonly.iso) =3D e2cc9393e0b596acdb36a8b07fbc480e MD5 (8.0-BETA4-sparc64-disc1.iso) =3D 706f2e57ff1502ccaac37dd4571d898a MD5 (8.0-BETA4-sparc64-dvd1.iso) =3D 9ac3509c8731874ae20009f170daf0e7 SHA256 (8.0-BETA4-amd64-bootonly.iso) =3D 3b4a1b964f64e68609f8010e43145c7a7= 57c352e62b2b8128dff3947f08c330b SHA256 (8.0-BETA4-amd64-disc1.iso) =3D e42cb6a4d46fcc924615949fe9da4217f9c8= 24e4c30fb6371787e28d5ec50ff8 SHA256 (8.0-BETA4-amd64-dvd1.iso) =3D 61bb39599c2b2b76de0643d677702683c4274= 901dbaaa3944b3a419402046dcf SHA256 (8.0-BETA4-amd64-livefs.iso) =3D f6b9fc2bfe74bb7bc730fa6786af09e4cca= 8d92a812ee1968283dff3eb6adc48 SHA256 (8.0-BETA4-amd64-memstick.img) =3D a930e419bed019114ddcf5833b3af1950= f4ef32444bb02b1b84e84d91c754bda SHA256 (8.0-BETA4-i386-bootonly.iso) =3D c2adde76995cbc25ac16afb2c4cb46686d= f54435f64e98ae4701908f024a0102 SHA256 (8.0-BETA4-i386-disc1.iso) =3D 0bbee2a9ffd4c00070cae001652037c8b1945= 02dfc1a35c3ac0da1172c26bfdd SHA256 (8.0-BETA4-i386-dvd1.iso) =3D 4dcd81040e977ff2f6c30aae04497416c2aec9= eb8d4a5ac0dab6f2cd965bfaee SHA256 (8.0-BETA4-i386-livefs.iso) =3D fac4c8c08698c30801f4555d5127c8bb5d78= 6d6bebe164fd27e66bea737526bf SHA256 (8.0-BETA4-i386-memstick.img) =3D 4a39d259b18f8d900a7bfc1878ed6ac4fd= a82812e13999da0265976eb1ba15e8 SHA256 (8.0-BETA4-ia64-bootonly.iso) =3D 5688b9c8bf13337835b2dce2fa7d6fb0ea= 17d397e927ef770d097a6728c8db23 SHA256 (8.0-BETA4-ia64-disc1.iso) =3D 33ddac157f6529bb31388d8c4ffdfb4824c98= 9c0c0d843ecec071eb67ea36786 SHA256 (8.0-BETA4-ia64-disc2.iso) =3D ae71fd5d8d29666fa15689ddd8ffd45e3b6d3= 54af9e1cb96b5a62280b452cbe5 SHA256 (8.0-BETA4-ia64-disc3.iso) =3D 330b43e5f81887de948257db46ed407a5c5a9= 4c09e6d41155159e0617c0be53e SHA256 (8.0-BETA4-ia64-dvd1.iso) =3D 4324c3c08d625b92942424a1c6e14085593ee6= 2237ddd4f2eac2f35d7fb0f27b SHA256 (8.0-BETA4-ia64-livefs.iso) =3D 860cad096ef74efa534bae3642dff5ec545e= d47faa21a6cd65b197b12827885d SHA256 (8.0-BETA4-pc98-bootonly.iso) =3D 0ce882dd48863f2f4180cbdf5f17ff595d= 7942bf7ac84029adef27a65b1b5481 SHA256 (8.0-BETA4-pc98-disc1.iso) =3D 4815a84ef0e834d3d57f7420c1f25ff93d0e3= b698cc6eecee8b587f9896edd01 SHA256 (8.0-BETA4-pc98-livefs.iso) =3D cb6ea4a931551c2220c739d66f05c120926a= 7c2650373fc72770a25ea5e10a3d SHA256 (8.0-BETA4-powerpc-bootonly.iso) =3D 6f97a8c061065661996e6efdad45bbb= aaafc2e8f80717fa845b2bc3ae14d7212 SHA256 (8.0-BETA4-powerpc-disc1.iso) =3D 9b1fb4af1a9a53e5723fdfd897d8a57a4e= 815ada22637285b7360d24f512290c SHA256 (8.0-BETA4-powerpc-disc2.iso) =3D 8e82ccaca6673cb3177870748ffdcb891f= b16904eacd98822cca31f9888656ae SHA256 (8.0-BETA4-powerpc-disc3.iso) =3D 651561d9021d5c68f266f21d6df31c87fe= c1368a428492274177810ea1333c3c SHA256 (8.0-BETA4-sparc64-bootonly.iso) =3D 35dd8a303df41cb7ca744c37aee104e= 18f441967a14a3c9eb36bc4bcaf78c01b SHA256 (8.0-BETA4-sparc64-disc1.iso) =3D 1d5ab4e67225a8640c9200424a140fff00= 3203ab5edb855172d7030130974529 SHA256 (8.0-BETA4-sparc64-dvd1.iso) =3D 59ab2cca0fa637e9ef5007117f1005570c1= 02cf4665009c6021992dd1b8bd77b --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-xmSWkBgDt4b8l14MH12L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkqlGBEACgkQ/G14VSmup/Y1vgCeIFUkql2Jfe7bInSy4pGVWmNu 8rEAn26p3YY/0nTBUMFZmnZlG2Th/VA9 =S6S0 -----END PGP SIGNATURE----- --=-xmSWkBgDt4b8l14MH12L-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 09:09:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3096A1065676 for ; Mon, 7 Sep 2009 09:09:54 +0000 (UTC) (envelope-from oliver@namp.de) Received: from grisu.qmail-ldap.de (grisu.qmail-ldap.de [78.46.218.233]) by mx1.freebsd.org (Postfix) with ESMTP id 7731E8FC17 for ; Mon, 7 Sep 2009 09:09:52 +0000 (UTC) Received: (qmail 56300 invoked from network); 7 Sep 2009 09:13:41 -0000 Received: from unknown (HELO mail.kuehlbox.de) (oliver@namp.de@[78.46.218.233]) (envelope-sender ) by grisu.qmail-ldap.de (qmail-ldap-1.03) with SMTP for ; 7 Sep 2009 09:13:41 -0000 Received: from: grisu.qmail-ldap.de ([78.46.218.233]) by HSF smtp proxy MIME-Version: 1.0 X-Priority: Normal X-Mailer: AtMail 1.03 Message-ID: <27537.1252314818@namp.de> To: "Bernhard Schmidt" X-Origin: 195.180.14.14 X-Atmail-Account: oliver@namp.de Date: Mon, 7 Sep 2009 11:13:38 +0200 From: Oliver Fakler X-Mailman-Approved-At: Mon, 07 Sep 2009 14:51:15 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: boot from raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: oliver@namp.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 09:09:54 -0000 On Mon 07/09/09 10:07 , Bernhard Schmidt wrote: Am 06.09.2009 um 21:45 schrieb Oliver Fakler: > > > Hi all, > > i installed a 8.0 beta 3 amd64 based testsystem. > > i tried with a root on a raidz, but i have a problem after the first > reboot, there is a error message: > > can't load kernel > I found something that boot root from raidz is not supported, but > maybe there is a solution?? > Hope some can help me There are patches from Doug Rabson which add support for booting from =20 raidz/raidz2. http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html [1]" target=3D"_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-Decemb= er/005498.html -- Bernhard I tried it, but after a make obj && make depend the make failed with different errors like undeclared and has no member named. I used patch raidzboot-14052009.diff started patching from /usr/src/sys/ , i'm not sure if this was the right way. I'm also not sure if the way of installation was the right one, here's the way i go: gpart create -s GPT da0 gpart add -b 34 -s 128 -t freebsd-boot da0 gpart add -b 162 -s 5242880 -t freebsd-swap da0 gpart add -b 5243042 -s 11534141 -t freebsd-zfs da0 gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da0 gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da1 gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da2 kldload /mnt2/boot/kernel/opensolaris.ko kldload /mnt2/boot/kernel/zfs.ko zpool create tank raidz da0p3 da1p1 d2p1 zfs create tank/tmp zfs create tank/usr zfs create tank/var cd /dist/8.0-BETA3/base export DESTDIR=3D/tank =2E/install.sh You are about to extract the base distribution into /tank - are you SURE you want to do this over your installed system (y/n)? y cd ../kernels =2E/install.sh generic cd /tank/boot cp -Rp GENERIC/* kernel/ cd /dist/8.0-BETA3/src =2E/install.sh all Extracting sources into /usr/src... Extracting source component: base Extracting source component: bin Extracting source component: cddl Extracting source component: contrib Extracting source component: crypto Extracting source component: etc Extracting source component: games Extracting source component: gnu Extracting source component: include Extracting source component: krb5 Extracting source component: lib Extracting source component: libexec Extracting source component: release Extracting source component: rescue Extracting source component: sbin Extracting source component: secure Extracting source component: share Extracting source component: sys Extracting source component: tools Extracting source component: ubin Extracting source component: usbin Done extracting sources. Done extracting sources. cd ../manpages =2E/install.sh echo 'zfs_enable=3D"YES"' > /tank/etc/rc.conf echo 'LOADER_ZFS_SUPPORT=3D"YES"' > /tank/etc/src.conf echo 'zfs_load=3D"YES"' > /tank/boot/loader.conf echo 'vfs.root.mountfrom=3D"zfs:tank"' >> /tank/boot/loader.conf echo ´/dev/da0p2 none swap sw 0 0´>> /tank/etc/fstab mkdir /boot/zfs zpool export tank && zpool import tank cp /boot/zfs/zpool.cache /tank/boot/zfs/ chroot /tank mount -t devfs devfs /dev unset DESTDIR cd /usr/src/sys/boot/ make obj make depend make cd i386/loader make install umount /dev touch /etc/fstab exit export LD_LIBRARY_PATH=3D/mnt2/lib zfs set mountpoint=3Dlegacy tank zfs set mountpoint=3D/tmp tank/tmp zfs set mountpoint=3D/var tank/var zfs set mountpoint=3D/usr tank/usr zpool set bootfs=3Dtank tank Cheers Oliver Links: ------ [1] http://mail.kuehlbox.de/parse.php?redirect=3D Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A1AE1065679 for ; Mon, 7 Sep 2009 14:22:41 +0000 (UTC) (envelope-from oliver@namp.de) Received: from grisu.qmail-ldap.de (grisu.qmail-ldap.de [78.46.218.233]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5948FC1E for ; Mon, 7 Sep 2009 14:22:39 +0000 (UTC) Received: (qmail 63711 invoked from network); 7 Sep 2009 14:26:30 -0000 Received: from unknown (HELO mail.kuehlbox.de) (oliver@namp.de@[78.46.218.233]) (envelope-sender ) by grisu.qmail-ldap.de (qmail-ldap-1.03) with SMTP for ; 7 Sep 2009 14:26:30 -0000 Received: from: grisu.qmail-ldap.de ([78.46.218.233]) by HSF smtp proxy MIME-Version: 1.0 X-Priority: Normal X-Mailer: AtMail 1.03 Message-ID: <36922.1252333586@namp.de> To: "Guido Falsi" , "Bernhard Schmidt" X-Origin: 195.180.14.14 X-Atmail-Account: oliver@namp.de Date: Mon, 7 Sep 2009 16:26:26 +0200 From: Oliver Fakler X-Mailman-Approved-At: Mon, 07 Sep 2009 14:51:57 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, oliver@namp.de Subject: Re: boot from raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: oliver@namp.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 14:22:41 -0000 On Mon 07/09/09 15:34 , Guido Falsi wrote:On Mon, Sep 07, 2009 at 12:40:05PM +0200, Bernhard Schmidt wrote: > > > >echo 'zfs_enable=3D"YES"' > /tank/etc/rc.conf > >echo 'LOADER_ZFS_SUPPORT=3D"YES"' > /tank/etc/src.conf > >echo 'zfs_load=3D"YES"' > /tank/boot/loader.conf > >echo 'vfs.root.mountfrom=3D"zfs:tank"' >> /tank/boot/loader.conf [...] >=20 >=20 > Seems correct at first glance. two things come to my mind: are we sure the loader you have installed(the ones from the distribution CD I think) was compiled with LOADER_ZFS_SUPPORT=3D"YES" set? I don't think this is the case. Usually I have to compile one on another machine(or just grab the one from a similar machine) and overwrite the distribution one. Another thing I notice; have you populated /boot/zfs/zpool.cache ?? --=20 Guido Falsi=20 i testet it with loader_zfs_support=3Dyes in make.conf and i copied the zpool.cache to/tank/boot/zfs the same howto works wirh a single zfs pool, so i don't think that the problem is located in zpool.cache Cheers Oliver From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 14:29:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3146B1065696 for ; Mon, 7 Sep 2009 14:29:15 +0000 (UTC) (envelope-from oliver@namp.de) Received: from grisu.qmail-ldap.de (grisu.qmail-ldap.de [78.46.218.233]) by mx1.freebsd.org (Postfix) with ESMTP id 337F38FC12 for ; Mon, 7 Sep 2009 14:29:13 +0000 (UTC) Received: (qmail 63882 invoked from network); 7 Sep 2009 14:33:04 -0000 Received: from unknown (HELO mail.kuehlbox.de) (oliver@namp.de@[78.46.218.233]) (envelope-sender ) by grisu.qmail-ldap.de (qmail-ldap-1.03) with SMTP for ; 7 Sep 2009 14:33:02 -0000 Received: from: grisu.qmail-ldap.de ([78.46.218.233]) by HSF smtp proxy MIME-Version: 1.0 X-Priority: Normal X-Mailer: AtMail 1.03 Message-ID: <19600.1252333979@namp.de> To: "Bernhard Schmidt" X-Origin: 195.180.14.14 X-Atmail-Account: oliver@namp.de Date: Mon, 7 Sep 2009 16:32:59 +0200 From: Oliver Fakler X-Mailman-Approved-At: Mon, 07 Sep 2009 14:52:44 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: boot from raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: oliver@namp.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 14:29:15 -0000 On Mon 07/09/09 13:40 , Bernhard Schmidt wrote: Am 07.09.2009 um 11:13 schrieb Oliver Fakler: > > BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; } > > On Mon 07/09/09 10:07 , Bernhard Schmidt =20 > wrote: > > > Am 06.09.2009 um 21:45 schrieb Oliver Fakler: > > > > > > > Hi all, > > > > i installed a 8.0 beta 3 amd64 based testsystem. > > > > i tried with a root on a raidz, but i have a problem after the first > > reboot, there is a error message: > > > > can't load kernel > > I found something that boot root from raidz is not supported, but > > maybe there is a solution?? > > Hope some can help me > > > There are patches from Doug Rabson which add support for booting from > raidz/raidz2. > > http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html [2]" target=3D"_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-Decemb= er/005498.html > " target=3D"_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-Decemb= er/005498.html [3]" target=3D"_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-Decemb= er/005498.html Seems that patch made it already into the tree (r192194). > > > I tried it, but after a make obj && make depend the make failed with =20 > different errors like undeclared and has no member named. > > I used patch raidzboot-14052009.diff started patching from /usr/src/=20 > sys/ , i'm not sure if this was the right way. > > I'm also not sure if the way of installation was the right one, =20 > here's the way i go: > > > gpart create -s GPT da0 > gpart add -b 34 -s 128 -t freebsd-boot da0 > gpart add -b 162 -s 5242880 -t freebsd-swap da0 > gpart add -b 5243042 -s 11534141 -t freebsd-zfs da0 > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da0 > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da1 > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 da2 > Can you try zfsboot instead of gptzfsboot? http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.htm= l [4]" target=3D"_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/20= 09-05/msg00689.html at the end of the mail. > > > kldload /mnt2/boot/kernel/opensolaris.ko > kldload /mnt2/boot/kernel/zfs.ko > > zpool create tank raidz da0p3 da1p1 d2p1 > > zfs create tank/tmp > zfs create tank/usr > zfs create tank/var > > cd /dist/8.0-BETA3/base > export DESTDIR=3D/tank > ./install.sh > You are about to extract the base distribution into /tank - are you =20 > SURE > you want to do this over your installed system (y/n)? y > cd ../kernels > ./install.sh generic > cd /tank/boot > cp -Rp GENERIC/* kernel/ > > cd /dist/8.0-BETA3/src > ./install.sh all > Extracting sources into /usr/src... > Extracting source component: base > Extracting source component: bin > Extracting source component: cddl > Extracting source component: contrib > Extracting source component: crypto > Extracting source component: etc > Extracting source component: games > Extracting source component: gnu > Extracting source component: include > Extracting source component: krb5 > Extracting source component: lib > Extracting source component: libexec > Extracting source component: release > Extracting source component: rescue > Extracting source component: sbin > Extracting source component: secure > Extracting source component: share > Extracting source component: sys > Extracting source component: tools > Extracting source component: ubin > Extracting source component: usbin > Done extracting sources. > Done extracting sources. > cd ../manpages > ./install.sh > > echo 'zfs_enable=3D"YES"' > /tank/etc/rc.conf > echo 'LOADER_ZFS_SUPPORT=3D"YES"' > /tank/etc/src.conf > echo 'zfs_load=3D"YES"' > /tank/boot/loader.conf > echo 'vfs.root.mountfrom=3D"zfs:tank"' >> /tank/boot/loader.conf > echo ´/dev/da0p2 none swap sw 0 0´>> /tank/etc/fstab > > mkdir /boot/zfs > zpool export tank && zpool import tank > cp /boot/zfs/zpool.cache /tank/boot/zfs/ > > chroot /tank > mount -t devfs devfs /dev > unset DESTDIR > cd /usr/src/sys/boot/ > make obj > make depend > make > cd i386/loader > make install > umount /dev > touch /etc/fstab > exit > > export LD_LIBRARY_PATH=3D/mnt2/lib > zfs set mountpoint=3Dlegacy tank > zfs set mountpoint=3D/tmp tank/tmp > zfs set mountpoint=3D/var tank/var > zfs set mountpoint=3D/usr tank/usr > zpool set bootfs=3Dtank tank > Seems correct at first glance. -- Bernhard testet with zfsboot instead of gptzfsboot but it was not successfull :-( Links: ------ [2] http://mail.kuehlbox.de/parse.php?redirect=3D Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 353D310656B0 for ; Mon, 7 Sep 2009 14:56:06 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id B86118FC30 for ; Mon, 7 Sep 2009 14:56:05 +0000 (UTC) Received: by bwz2 with SMTP id 2so402961bwz.43 for ; Mon, 07 Sep 2009 07:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Jw7atPiHGa/EkFVq3HLzMDKmZU8E9eMPnEYmTMmmdbc=; b=JBCC78a9+NU9on6qorl21AVmAoQsJb5+0tyfg+1m0WF9ey6Dg3sqgVIQBRsaKlC22A kqsk56UOTmGv0aHaID48LwbBFyq+J5p5kIPxAi9+wHn6+pRCFMyA92Gea+ZT07qE1nLD lsXusJtRogejGZbertYipSNKHat2dtZMHTXEA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wSWY30Obf7z6ptrZfYcwqxI7D3fDe/+en+huqUrK8sRhYlvcugGXziDPDB/zCY2yY9 jUy3C17w3a40hYwlMTJ9tFo9bEEmB7mZmUhWOOPpCAMJa632grEp4hdOQ9jewXOafKsX XQOX+mBpvCEGwhm3UU5LhamtlA/EqSUmDveLw= MIME-Version: 1.0 Received: by 10.239.142.148 with SMTP id g20mr1385188hba.34.1252333958091; Mon, 07 Sep 2009 07:32:38 -0700 (PDT) In-Reply-To: <4AA33DF9.6070803@omnilan.de> References: <4AA33DF9.6070803@omnilan.de> Date: Mon, 7 Sep 2009 11:32:38 -0300 Message-ID: From: "Carlos A. M. dos Santos" To: Harald Schmalzbauer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Funding ODD support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 14:56:06 -0000 On Sun, Sep 6, 2009 at 1:43 AM, Harald Schmalzbauer wrote: > Hello, > > I'm looking for somebody who has time and knowledge to fix ODD support in > FreeBSD. [...] I'm not sure if such work should be funded by a separate bounty or by the FreeBSD foundation. Anyway, I would happily donate some money for improvements on the CD/DVD writing support. I'd like to see either an improved version of burncd or some new tool provided by the base system. -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 15:36:16 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4DA51065679 for ; Mon, 7 Sep 2009 15:36:16 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 99F5D8FC23 for ; Mon, 7 Sep 2009 15:36:16 +0000 (UTC) Received: from [89.178.146.164] (port=32743 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkgGM-00052G-6e; Mon, 07 Sep 2009 19:36:14 +0400 Message-ID: <4AA5286D.7040400@lissyara.su> Date: Mon, 07 Sep 2009 19:36:13 +0400 From: Alex Keda User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Gavin Atkinson References: <4AA384EC.3060003@lissyara.su> <1252332612.55883.10.camel@buffy.york.ac.uk> In-Reply-To: <1252332612.55883.10.camel@buffy.york.ac.uk> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-current Subject: Re: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 15:36:17 -0000 Gavin Atkinson ïèøåò: > On Sun, 2009-09-06 at 13:46 +0400, Alex Keda wrote: >> hi! >> I have fatal trap with today (and yesterday) current. >> Machine boot, I see: >> Timecounters tick every 1.000 msec >> then, it freese ~30 seconds and go to kernel debugger - fatal trap 12 >> stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d > > At the debugger prompt, can you give the "bt" command, and show us what > the output is please? It: >> stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d from bt, last string. or need all output? From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 15:51:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C82D71065676; Mon, 7 Sep 2009 15:51:06 +0000 (UTC) (envelope-from nick-lists@netability.ie) Received: from mail.acquirer.com (mail.acquirer.com [87.198.142.193]) by mx1.freebsd.org (Postfix) with ESMTP id DCAE98FC14; Mon, 7 Sep 2009 15:51:05 +0000 (UTC) X-Envelope-To: freebsd-current@freebsd.org Received: from cupcake.internal.acquirer.com (cupcake.internal.acquirer.com [10.228.100.105]) (authenticated bits=0) by mail.acquirer.com (8.14.3/8.14.3) with ESMTP id n87FoxFa062046 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 7 Sep 2009 16:51:00 +0100 (IST) (envelope-from nick-lists@netability.ie) Message-ID: <4AA52BE4.3070708@netability.ie> Date: Mon, 07 Sep 2009 16:51:00 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: John Baldwin References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im> <200909011002.59592.jhb@freebsd.org> In-Reply-To: <200909011002.59592.jhb@freebsd.org> Content-Type: multipart/mixed; boundary="------------030305060200070003090704" X-Spam-Status: No, score=-1.8 required=5.0 tests=ALL_TRUSTED,BAYES_00, SARE_BAYES_5x8, SARE_BAYES_6x8, SARE_BAYES_7x8 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muffin.acquirer.com Cc: freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 15:51:06 -0000 This is a multi-part message in MIME format. --------------030305060200070003090704 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 01/09/2009 15:02, John Baldwin wrote: > Hmm, so an idea I had just now.. can you grab a dump of the PCI config space > for the disk controller in the MCFG vs non-MCFG cases? That is, find the > device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and then > run this command under both configurations and save the output: > > pciconf -r pci0:0:30:0 0:0xfc Ok, got this working on the beta4 livefs. If hw.pci.mcfg=0, then all disks are detected correctly. I've attached the pciconf output for each case. Nick --------------030305060200070003090704 Content-Type: text/plain; name="mcfg=0^0:0:5:0.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mcfg=0^0:0:5:0.txt" MDM3ZjEwZGUgMDBiMDAwMDcgMDEwMTg1YTMgMDA4MDAwMDAKMDAwMGRkODEgMDAwMGRkMDEg MDAwMGRjMDEgMDAwMGRiODEgCjAwMDBkYjAxIGZjZWJkMDAwIDAwMDAwMDAwIDE3MTQxMDNj CjAwMDAwMDAwIDAwMDAwMDQ0IDAwMDAwMDAwIDAxMDMwMTE1IAoxNzE0MTAzYyAwMDAyYjAw MSAwMDAwMDAwMCAwMDAwMDAwMAo4MDA4NjgwZiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAw MCAKMDAwMDAwMDAgMDAwMDBjNDEgNDIwNjBmMDAgMDAwMDAwMDAKNDBjNDc4MmMgMDAwMDEw MDEgMDAwMDEwMDEgMDAyMDAwMjAgCmMwMDAwMDAwIDAyZGY4ODAwIGIwMDgwMDAwIDAyZGU4 YzAwCjkwMDgwMDAwIDAwMDAwMDAwIDEwMDYwMDA2IDAxMDEwMzdmIAoxODAwMGExMiAwMDAw MDAwMCAwMDAwMDAwMCAwMjAwMzEzMwowMDg0Y2MwNSAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw MDAwMCAKMDAwMDAwMDAgMDAwMDAwMDAgMDAwYTAwMGEgYTgwMjAwMDgKMDMwMjAwMGEgMDAw MDAwNDIgMDAwMDAwMDAgZTAwMDQ4MmEgCjAzMDIwMDBhIDAwMDAwMDQyIDAwMDAwMDAwIGU3 ZjAwMDBmCjAwMDAwMDAwIDAwMDAwMDAwIDAwMGMwMDEwIDAwMDAwMDAwIAo= --------------030305060200070003090704 Content-Type: text/plain; name="mcfg=0^0:0:5:1.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mcfg=0^0:0:5:1.txt" MDM3ZjEwZGUgMDBiMDAwMDcgMDEwMTg1YTMgMDA4MDAwMDAKMDAwMGRhODEgMDAwMGRhMDEg MDAwMGQ5ODEgMDAwMGQ5MDEgCjAwMDBkODgxIGZjZWJjMDAwIDAwMDAwMDAwIDE3MTQxMDNj CjAwMDAwMDAwIDAwMDAwMDQ0IDAwMDAwMDAwIDAxMDMwMjE2IAoxNzE0MTAzYyAwMDAyYjAw MSAwMDAwMDAwMCAwMDAwMDAwMAo4MDA4NjgwZiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAw MCAKMDAwMDAwMDAgMDAwMDBjNDEgNDIwNjBmMDAgMDAwMDAwMDAKNDBjNDc4MmMgMDAwMDEw MDEgMDAwMDEwMDEgMDAyMDAwMjAgCmMwMDAwMDAwIDAyZGY4ODAwIGIwMDgwMDAwIDAyZGY5 MDAwCjkwMDgwMDAwIDAwMDAwMDAwIDEwMDYwMDA2IDAxMDEwMzdmIAoxODAwMGExMiAwMDAw MDAwMCAwMDAwMDAwMCAwMjAwMzEzMwowMDg0Y2MwNSAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw MDAwMCAKMDAwMDAwMDAgMDAwMDAwMDAgMDAwYTAwMGEgYTgwMjAwMDgKMDMwMjAwMGEgMDAw MDAwNDIgMDAwMDAwMDAgZTdkMDAwMDEgCjAzMDIwMDBhIDAwMDAwMDQyIDAwMDAwMDAwIGUw MDAwMDBmCjAwMDAwMDAwIDAwMDAwMDAwIDAwMGMwMDEwIDAwMDAwMDAwIAo= --------------030305060200070003090704 Content-Type: text/plain; name="mcfg=0^0:0:5:2.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mcfg=0^0:0:5:2.txt" MDM3ZjEwZGUgMDBiMDAwMDcgMDEwMTg1YTMgMDA4MDAwMDAKMDAwMGQ4MDEgMDAwMGQ3ODEg MDAwMGQ3MDEgMDAwMGQ2ODEgCjAwMDBkNjAxIGZjZWJiMDAwIDAwMDAwMDAwIDE3MTQxMDNj CjAwMDAwMDAwIDAwMDAwMDQ0IDAwMDAwMDAwIDAxMDMwMzE3IAoxNzE0MTAzYyAwMDAyYjAw MSAwMDAwMDAwMCAwMDAwMDAwMAo4MDA4NjgwZiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAw MCAKMDAwMDAwMDAgMDAwMDBjNDEgNDIwNjBmMDAgMDAwMDAwMDAKNDBjNDc4MmMgMDAwMDEw MDEgMDAwMDEwMDEgMDAyMDAwMjAgCmMwMDAwMDAwIDAyZTViODAwIGIwMDgwMDAwIDBkMDRm MDAwCjgwMDgwMDAwIDAwMDAwMDAwIDEwMDYwMDA2IDAxMDEwMzdmIAoxNzAwMGExMiAwMDAw MDAwMCAwMDAwMDAwMCAwMjAwMzEzMwowMDg0Y2MwNSAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw MDAwMCAKMDAwMDAwMDAgMDAwMDAwMDAgMDAwYTAwMGEgYTgwMjAwMDgKMDMwMjAwMGEgMDAw MDAwNDIgMDAwMDAwMDAgODEwMDEwMDAgCjAzMDIwMDBhIDAwMDAwMDQyIDAwMDAwMDAwIDg3 ZjAwMDAxCjAwMDAwMDAwIDAwMDAwMDAwIDAwMGMwMDEwIDAwMDAwMDAwIAo= --------------030305060200070003090704 Content-Type: text/plain; name="mcfg=1^0:0:5:0.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mcfg=1^0:0:5:0.txt" MDM3ZjEwZGUgMDBiMDAwMDcgMDEwMTg1YTMgMDA4MDAwMDAKMDAwMGRkODEgMDAwMGRkMDEg MDAwMGRjMDEgMDAwMGRiODEgCjAwMDBkYjAxIGZjZWJkMDAwIDAwMDAwMDAwIDE3MTQxMDNj CjAwMDAwMDAwIDAwMDAwMDQ0IDAwMDAwMDAwIDAxMDMwMTE1IAoxNzE0MTAzYyAwMDAyYjAw MSAwMDAwMDAwMCAwMDAwMDAwMAo4MDA4NjgwZiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAw MCAKMDAwMDAwMDAgMDAwMDBjNDEgNDIwNjBmMDAgMDAwMDAwMDAKNDBjNDc4MmMgMDAwMDEw MDEgMDAwMDEwMDEgMDAyMDAwMjAgCmMwMDAwMDAwIDc4YjY5ODAwIDAwMDgwMDAwIDc4NzYy MDAwCjAwMDgwMDAwIDAwMDAwMDAwIDEwMDYwMDA2IDAxMDEwMzdmIAoxODAwMGExMiAwMDAw MDAwMCAwMDAwMDAwMCAwMjAwMzEzMwowMDg0Y2MwNSAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw MDAwMCAKMDAwMDAwMDAgMDAwMDAwMDAgMDAwYTAwMGEgYTgwMjAwMDgKMDMwMjAwMGEgMDAw MDAwNDIgMDAwMDAwMDAgZTAwMDQ4MmEgCjAzMDIwMDBhIDAwMDAwMDQyIDAwMDAwMDAwIGU3 ZjAwMDBmCjAwMDAwMDAwIDAwMDAwMDAwIDAwMGMwMDEwIDAwMDAwMDAwIAo= --------------030305060200070003090704 Content-Type: text/plain; name="mcfg=1^0:0:5:1.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mcfg=1^0:0:5:1.txt" MDM3ZjEwZGUgMDBiMDAwMDcgMDEwMTg1YTMgMDA4MDAwMDAKMDAwMGRhODEgMDAwMGRhMDEg MDAwMGQ5ODEgMDAwMGQ5MDEgCjAwMDBkODgxIGZjZWJjMDAwIDAwMDAwMDAwIDE3MTQxMDNj CjAwMDAwMDAwIDAwMDAwMDQ0IDAwMDAwMDAwIDAxMDMwMjE2IAoxNzE0MTAzYyAwMDAyYjAw MSAwMDAwMDAwMCAwMDAwMDAwMAo4MDA4NjgwZiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAw MCAKMDAwMDAwMDAgMDAwMDBjNDEgNDIwNjBmMDAgMDAwMDAwMDAKNDBjNDc4MmMgMDAwMDEw MDEgMDAwMDEwMDEgMDAyMDAwMjAgCmMwMDAwMDAwIDAyZGU4YzAwIGIwMDgwMDAwIDAyZGU4 ODAwCjkwMDgwMDAwIDAwMDAwMDAwIDEwMDYwMDA2IDAxMDEwMzdmIAoxODAwMGExMiAwMDAw MDAwMCAwMDAwMDAwMCAwMjAwMzEzMwowMDg0Y2MwNSAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw MDAwMCAKMDAwMDAwMDAgMDAwMDAwMDAgMDAwYTAwMGEgYTgwMjAwMDgKMDMwMjAwMGEgMDAw MDAwNDIgMDAwMDAwMDAgZTdkMDAwMDEgCjAzMDIwMDBhIDAwMDAwMDQyIDAwMDAwMDAwIGUw MDAwMDBmCjAwMDAwMDAwIDAwMDAwMDAwIDAwMGMwMDEwIDAwMDAwMDAwIAo= --------------030305060200070003090704 Content-Type: text/plain; name="mcfg=1^0:0:5:2.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mcfg=1^0:0:5:2.txt" MDM3ZjEwZGUgMDBiMDAwMDcgMDEwMTg1YTMgMDA4MDAwMDAKMDAwMGQ4MDEgMDAwMGQ3ODEg MDAwMGQ3MDEgMDAwMGQ2ODEgCjAwMDBkNjAxIGZjZWJiMDAwIDAwMDAwMDAwIDE3MTQxMDNj CjAwMDAwMDAwIDAwMDAwMDQ0IDAwMDAwMDAwIDAxMDMwMzE3IAoxNzE0MTAzYyAwMDAyYjAw MSAwMDAwMDAwMCAwMDAwMDAwMAo4MDA4NjgwZiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAw MCAKMDAwMDAwMDAgMDAwMDBjNDEgNDIwNjBmMDAgMDAwMDAwMDAKNDBjNDc4MmMgMDAwMDEw MDEgMDAwMDEwMDEgMDAyMDAwMjAgCmMwMDAwMDAwIDAyZTZiNDAwIGIwMDgwMDAwIGNmZWQw ODAwCjgwMDgwMDAwIDAwMDAwMDAwIDEwMDYwMDA2IDAxMDEwMzdmIAoxNzAwMGExMiAwMDAw MDAwMCAwMDAwMDAwMCAwMjAwMzEzMwowMDg0Y2MwNSAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw MDAwMCAKMDAwMDAwMDAgMDAwMDAwMDAgMDAwYTAwMGEgYTgwMjAwMDgKMDMwMjAwMGEgMDAw MDAwNDIgMDAwMDAwMDAgODEwMDEwMDAgCjAzMDIwMDBhIDAwMDAwMDQyIDAwMDAwMDAwIDg3 ZjAwMDAxCjAwMDAwMDAwIDAwMDAwMDAwIDAwMGMwMDEwIDAwMDAwMDAwIAo= --------------030305060200070003090704 Content-Type: text/plain; name="pciconf.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pciconf.txt" bm9uZTBAcGNpMDowOjA6MDoJY2xhc3M9MHgwNTAwMDAgY2FyZD0weDE3MTQxMDNjIGNoaXA9 MHgwMzY5MTBkZSByZXY9MHhhMiBoZHI9MHgwMAogICAgY2xhc3MgICAgICA9IG1lbW9yeQog ICAgc3ViY2xhc3MgICA9IFJBTQppc2FiMEBwY2kwOjA6MTowOgljbGFzcz0weDA2MDEwMCBj YXJkPTB4MTcxNDEwM2MgY2hpcD0weDAzNjAxMGRlIHJldj0weGEzIGhkcj0weDAwCiAgICBj bGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLUlTQQpub25lMUBwY2kw OjA6MToxOgljbGFzcz0weDBjMDUwMCBjYXJkPTB4MTcxNDEwM2MgY2hpcD0weDAzNjgxMGRl IHJldj0weGEzIGhkcj0weDAwCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3Vi Y2xhc3MgICA9IFNNQnVzCm9oY2kwQHBjaTA6MDoyOjA6CWNsYXNzPTB4MGMwMzEwIGNhcmQ9 MHgxNzE0MTAzYyBjaGlwPTB4MDM2YzEwZGUgcmV2PTB4YTEgaGRyPTB4MDAKICAgIGNsYXNz ICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCmVoY2kwQHBjaTA6MDoy OjE6CWNsYXNzPTB4MGMwMzIwIGNhcmQ9MHgxNzE0MTAzYyBjaGlwPTB4MDM2ZDEwZGUgcmV2 PTB4YTIgaGRyPTB4MDAKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFz cyAgID0gVVNCCmF0YXBjaTBAcGNpMDowOjU6MDoJY2xhc3M9MHgwMTAxODUgY2FyZD0weDE3 MTQxMDNjIGNoaXA9MHgwMzdmMTBkZSByZXY9MHhhMyBoZHI9MHgwMAogICAgY2xhc3MgICAg ICA9IG1hc3Mgc3RvcmFnZQogICAgc3ViY2xhc3MgICA9IEFUQQphdGFwY2kxQHBjaTA6MDo1 OjE6CWNsYXNzPTB4MDEwMTg1IGNhcmQ9MHgxNzE0MTAzYyBjaGlwPTB4MDM3ZjEwZGUgcmV2 PTB4YTMgaGRyPTB4MDAKICAgIGNsYXNzICAgICAgPSBtYXNzIHN0b3JhZ2UKICAgIHN1YmNs YXNzICAgPSBBVEEKYXRhcGNpMkBwY2kwOjA6NToyOgljbGFzcz0weDAxMDE4NSBjYXJkPTB4 MTcxNDEwM2MgY2hpcD0weDAzN2YxMGRlIHJldj0weGEzIGhkcj0weDAwCiAgICBjbGFzcyAg ICAgID0gbWFzcyBzdG9yYWdlCiAgICBzdWJjbGFzcyAgID0gQVRBCnBjaWIxQHBjaTA6MDo2 OjA6CWNsYXNzPTB4MDYwNDAxIGNhcmQ9MHgxNzE0MTAzYyBjaGlwPTB4MDM3MDEwZGUgcmV2 PTB4YTIgaGRyPTB4MDEKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAg PSBQQ0ktUENJCnBjaWIyQHBjaTA6MDoxMDowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4MDAw MDEwZGUgY2hpcD0weDAzNzYxMGRlIHJldj0weGEzIGhkcj0weDAxCiAgICBjbGFzcyAgICAg ID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQpwY2liM0BwY2kwOjA6MTE6MDoJ Y2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAxMGRlIGNoaXA9MHgwMzc0MTBkZSByZXY9MHhh MyBoZHI9MHgwMQogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IFBD SS1QQ0kKcGNpYjRAcGNpMDowOjEyOjA6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAwMTBk ZSBjaGlwPTB4MDM3NDEwZGUgcmV2PTB4YTMgaGRyPTB4MDEKICAgIGNsYXNzICAgICAgPSBi cmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCnBjaWI1QHBjaTA6MDoxMzowOgljbGFz cz0weDA2MDQwMCBjYXJkPTB4MDAwMDEwZGUgY2hpcD0weDAzNzgxMGRlIHJldj0weGEzIGhk cj0weDAxCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBD SQpwY2liNkBwY2kwOjA6MTQ6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAxMGRlIGNo aXA9MHgwMzc1MTBkZSByZXY9MHhhMyBoZHI9MHgwMQogICAgY2xhc3MgICAgICA9IGJyaWRn ZQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kKcGNpYjdAcGNpMDowOjE1OjA6CWNsYXNzPTB4 MDYwNDAwIGNhcmQ9MHgwMDAwMTBkZSBjaGlwPTB4MDM3NzEwZGUgcmV2PTB4YTMgaGRyPTB4 MDEKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCmhv c3RiMEBwY2kwOjA6MjQ6MDoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9 MHgxMjAwMTAyMiByZXY9MHgwMCBoZHI9MHgwMAogICAgY2xhc3MgICAgICA9IGJyaWRnZQog ICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCmhvc3RiMUBwY2kwOjA6MjQ6MToJY2xhc3M9MHgw NjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMjAxMTAyMiByZXY9MHgwMCBoZHI9MHgw MAogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCmhv c3RiMkBwY2kwOjA6MjQ6MjoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9 MHgxMjAyMTAyMiByZXY9MHgwMCBoZHI9MHgwMAogICAgY2xhc3MgICAgICA9IGJyaWRnZQog ICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCmhvc3RiM0BwY2kwOjA6MjQ6MzoJY2xhc3M9MHgw NjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMjAzMTAyMiByZXY9MHgwMCBoZHI9MHgw MAogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCmhv c3RiNEBwY2kwOjA6MjQ6NDoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9 MHgxMjA0MTAyMiByZXY9MHgwMCBoZHI9MHgwMAogICAgY2xhc3MgICAgICA9IGJyaWRnZQog ICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCmVtMEBwY2kwOjQ6MDowOgljbGFzcz0weDAyMDAw MCBjYXJkPTB4NzA0YTEwM2MgY2hpcD0weDEwYjk4MDg2IHJldj0weDA2IGhkcj0weDAwCiAg ICBjbGFzcyAgICAgID0gbmV0d29yawogICAgc3ViY2xhc3MgICA9IGV0aGVybmV0CnZnYXBj aTBAcGNpMDoxNjowOjA6CWNsYXNzPTB4MDMwMDAwIGNhcmQ9MHgzMWZhMTAzYyBjaGlwPTB4 MDUyMjEwMmIgcmV2PTB4MDIgaGRyPTB4MDAKICAgIGNsYXNzICAgICAgPSBkaXNwbGF5CiAg ICBzdWJjbGFzcyAgID0gVkdBCmJnZTBAcGNpMDoxNzowOjA6CWNsYXNzPTB4MDIwMDAwIGNh cmQ9MHg3MDUxMTAzYyBjaGlwPTB4MTY1YTE0ZTQgcmV2PTB4MDAgaGRyPTB4MDAKICAgIGNs YXNzICAgICAgPSBuZXR3b3JrCiAgICBzdWJjbGFzcyAgID0gZXRoZXJuZXQK --------------030305060200070003090704-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 16:17:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FAFA1065694 for ; Mon, 7 Sep 2009 16:17:26 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swip.net [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id C6E278FC16 for ; Mon, 7 Sep 2009 16:17:25 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=g63cz5HrQV0A:10 a=p7f755yT8wqfGVF+fg83Lg==:17 a=6I5d2MoRAAAA:8 a=Or1GXRdfQq73bd2UORcA:9 a=zguSwz8KT74Iq7jfqDAA:7 a=yFCDaFPYiJRxnWD8kdoRm6gx3QsA:4 a=0ZIji_GGu4YA:10 Received: from [212.4.54.130] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 563806024; Mon, 07 Sep 2009 18:17:23 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 7 Sep 2009 18:17:41 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <15577E21-9A9B-45CA-BC56-D1AB1FF6A5A9@lassitu.de> <200909012357.42238.hselasky@c2i.net> In-Reply-To: X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909071817.43090.hselasky@c2i.net> Cc: Stefan Bethke Subject: Re: Elsa MicroLink 56k USB is not picked up by umodem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 16:17:26 -0000 On Saturday 05 September 2009 22:20:55 Stefan Bethke wrote: > Stefan Bethke Your quirk has been committed: http://perforce.freebsd.org/chv.cgi?CH=168284 --HPS From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 16:20:25 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1FBD1065693 for ; Mon, 7 Sep 2009 16:20:25 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 594638FC1B for ; Mon, 7 Sep 2009 16:20:25 +0000 (UTC) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id n87GKK2s015004; Mon, 7 Sep 2009 17:20:20 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Mkgx2-0004Jx-GF; Mon, 07 Sep 2009 17:20:20 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n87GKKn6072090; Mon, 7 Sep 2009 17:20:20 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n87GKKQZ072085; Mon, 7 Sep 2009 17:20:20 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Alex Keda In-Reply-To: <4AA5286D.7040400@lissyara.su> References: <4AA384EC.3060003@lissyara.su> <1252332612.55883.10.camel@buffy.york.ac.uk> <4AA5286D.7040400@lissyara.su> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Date: Mon, 07 Sep 2009 17:20:19 +0100 Message-Id: <1252340419.55883.26.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-current Subject: Re: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 16:20:25 -0000 On Mon, 2009-09-07 at 19:36 +0400, Alex Keda wrote: > Gavin Atkinson =D0=C9=DB=C5=D4: > > On Sun, 2009-09-06 at 13:46 +0400, Alex Keda wrote: > >> hi! > >> I have fatal trap with today (and yesterday) current. > >> Machine boot, I see: > >> Timecounters tick every 1.000 msec > >> then, it freese ~30 seconds and go to kernel debugger - fatal trap 12 > >> stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d > >=20 > > At the debugger prompt, can you give the "bt" command, and show us what > > the output is please? > It: > >> stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d > from bt, last string. > or need all output? All output, please. Gavin From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 16:23:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D93B106566C for ; Mon, 7 Sep 2009 16:23:35 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id 8A4368FC13 for ; Mon, 7 Sep 2009 16:23:34 +0000 (UTC) Received: from demophon.fletchermoorland.co.uk (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.3/8.14.3) with ESMTP id n87GNR5M036109; Mon, 7 Sep 2009 17:23:28 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4AA5415E.3070203@fletchermoorland.co.uk> Date: Mon, 07 Sep 2009 17:22:38 +0000 From: Paul Wootton User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: oliver@namp.de References: <19600.1252333979@namp.de> In-Reply-To: <19600.1252333979@namp.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.64 on 192.168.0.1 X-Spam-Status: No, score=-4.4 required=10.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hydra.fletchermoorland.co.uk Cc: Bernhard Schmidt , freebsd-current@freebsd.org Subject: Re: boot from raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 16:23:35 -0000 Oliver Fakler wrote: > On Mon 07/09/09 13:40 , Bernhard Schmidt wrote: > Am 07.09.2009 um 11:13 schrieb Oliver Fakler: > > > > BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; } > > > > On Mon 07/09/09 10:07 , Bernhard Schmidt > > wrote: > > > > > > Am 06.09.2009 um 21:45 schrieb Oliver Fakler: > > > > > > > > > > > Hi all, > > > > > > i installed a 8.0 beta 3 amd64 based testsystem. > > > > > > i tried with a root on a raidz, but i have a problem after the > first > > > reboot, there is a error message: > > > > > > can't load kernel > > > I found something that boot root from raidz is not supported, > but > > > maybe there is a solution?? > > > Hope some can help me > > > > > > There are patches from Doug Rabson which add support for booting > from > > raidz/raidz2. > > > > > http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html > [2]" > target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html > > > " > target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html > [3]" > target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html > Seems that patch made it already into the tree (r192194). > > > > > > I tried it, but after a make obj && make depend the make failed > with > > different errors like undeclared and has no member named. > > > > I used patch raidzboot-14052009.diff started patching from > /usr/src/ > > sys/ , i'm not sure if this was the right way. > > > > I'm also not sure if the way of installation was the right one, > > here's the way i go: > > > > > > gpart create -s GPT da0 > > gpart add -b 34 -s 128 -t freebsd-boot da0 > > gpart add -b 162 -s 5242880 -t freebsd-swap da0 > > gpart add -b 5243042 -s 11534141 -t freebsd-zfs da0 > > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 > da0 > > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 > da1 > > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 > da2 > > > Can you try zfsboot instead of gptzfsboot? > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html > [4]" > target="_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html > > at the end of the mail. > > > > > > kldload /mnt2/boot/kernel/opensolaris.ko > > kldload /mnt2/boot/kernel/zfs.ko > > > > zpool create tank raidz da0p3 da1p1 d2p1 > > > > zfs create tank/tmp > > zfs create tank/usr > > zfs create tank/var > > > > cd /dist/8.0-BETA3/base > > export DESTDIR=/tank > > ./install.sh > > You are about to extract the base distribution into /tank - are > you > > SURE > > you want to do this over your installed system (y/n)? y > > cd ../kernels > > ./install.sh generic > > cd /tank/boot > > cp -Rp GENERIC/* kernel/ > > > > cd /dist/8.0-BETA3/src > > ./install.sh all > > Extracting sources into /usr/src... > > Extracting source component: base > > Extracting source component: bin > > Extracting source component: cddl > > Extracting source component: contrib > > Extracting source component: crypto > > Extracting source component: etc > > Extracting source component: games > > Extracting source component: gnu > > Extracting source component: include > > Extracting source component: krb5 > > Extracting source component: lib > > Extracting source component: libexec > > Extracting source component: release > > Extracting source component: rescue > > Extracting source component: sbin > > Extracting source component: secure > > Extracting source component: share > > Extracting source component: sys > > Extracting source component: tools > > Extracting source component: ubin > > Extracting source component: usbin > > Done extracting sources. > > Done extracting sources. > > cd ../manpages > > ./install.sh > > > > echo 'zfs_enable="YES"' > /tank/etc/rc.conf > > echo 'LOADER_ZFS_SUPPORT="YES"' > /tank/etc/src.conf > > echo 'zfs_load="YES"' > /tank/boot/loader.conf > > echo 'vfs.root.mountfrom="zfs:tank"' >> /tank/boot/loader.conf > > echo ´/dev/da0p2 none swap sw 0 0´>> /tank/etc/fstab > > > > mkdir /boot/zfs > > zpool export tank && zpool import tank > > cp /boot/zfs/zpool.cache /tank/boot/zfs/ > > > > chroot /tank > > mount -t devfs devfs /dev > > unset DESTDIR > > cd /usr/src/sys/boot/ > > make obj > > make depend > > make > > cd i386/loader > > make install > > umount /dev > > touch /etc/fstab > > exit > > > > export LD_LIBRARY_PATH=/mnt2/lib > > zfs set mountpoint=legacy tank > > zfs set mountpoint=/tmp tank/tmp > > zfs set mountpoint=/var tank/var > > zfs set mountpoint=/usr tank/usr > > zpool set bootfs=tank tank > > > Seems correct at first glance. > -- > Bernhard > testet with zfsboot instead of gptzfsboot but it was not successfull > :-( > > Links: > ------ > [2] http://mail.kuehlbox.de/parse.php?redirect= [3] http://mail.kuehlbox.de/parse.php?redirect= [4] http://mail.kuehlbox.de/parse.php?redirect= _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org I have a fully running GPT ZFS RaidZ setup using what was at the time 8-HEAD I cant remember the exact steps I took, but one thing I have different is I have a root filesystem within my zpool [paul@demophon /usr/home/paul]$ gpart show => 34 976773101 ada1 GPT (466G) 34 256 1 freebsd-boot (128K) 290 8388608 2 freebsd-swap (4.0G) 8388898 147912557 3 freebsd-zfs (71G) 156301455 820471680 - free - (391G) => 34 488394988 ada2 GPT (233G) 34 256 1 freebsd-boot (128K) 290 8388608 2 freebsd-swap (4.0G) 8388898 147912557 3 freebsd-zfs (71G) 156301455 332093567 - free - (158G) => 34 156301421 ada3 GPT (75G) 34 256 1 freebsd-boot (128K) 290 8388608 2 freebsd-swap (4.0G) 8388898 147912557 3 freebsd-zfs (71G) [paul@demophon /usr/home/paul]$ zpool status pool: zboot state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zboot ONLINE 0 0 0 ada1p3 ONLINE 0 0 0 ada2p3 ONLINE 0 0 0 ada3p3 ONLINE 0 0 0 errors: No known data errors [paul@demophon /usr/home/paul]$ zfs list NAME USED AVAIL REFER MOUNTPOINT zboot 33.5G 175G 18K none zboot/root 12.4G 175G 12.2G none zboot/tmp 82.9M 175G 82.6M none zboot/usr 20.8G 175G 16.5G none zboot/var 216M 175G 123M none Im also using fstabs to mount my ZFS filesystems [paul@demophon /usr/home/paul]$ more /etc/fstab # Device Mountpoint FStype Options Dump Pass# zboot/root / zfs rw 0 0 zboot/usr /usr zfs rw 0 0 zboot/var /var zfs rw 0 0 zboot/tmp /tmp zfs rw,noatime 0 0 proc /proc procfs rw 0 0 I remember speak to someone a while back, and I *think* we came to the conclusion that using the zpool as your root will not work correctly and you should really create a root filesystem inside the zpool Lets me know how this works out for you Paul ----------------------------------------------------------------------------------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 16:39:43 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2262106566C; Mon, 7 Sep 2009 16:39:43 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 559B88FC19; Mon, 7 Sep 2009 16:39:42 +0000 (UTC) Received: from [89.178.146.164] (port=10605 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkhFl-000Jc9-J2; Mon, 07 Sep 2009 20:39:41 +0400 Message-ID: <4AA5374C.1090509@lissyara.su> Date: Mon, 07 Sep 2009 20:39:40 +0400 From: Alex Keda User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Gavin Atkinson References: <4AA384EC.3060003@lissyara.su> <1252332612.55883.10.camel@buffy.york.ac.uk> <4AA5286D.7040400@lissyara.su> <1252340419.55883.26.camel@buffy.york.ac.uk> In-Reply-To: <1252340419.55883.26.camel@buffy.york.ac.uk> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-current Subject: Re: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 16:39:43 -0000 Gavin Atkinson ÐÉÛÅÔ: > On Mon, 2009-09-07 at 19:36 +0400, Alex Keda wrote: >> Gavin Atkinson ÐÉÛÅÔ: >>> On Sun, 2009-09-06 at 13:46 +0400, Alex Keda wrote: >>>> hi! >>>> I have fatal trap with today (and yesterday) current. >>>> Machine boot, I see: >>>> Timecounters tick every 1.000 msec >>>> then, it freese ~30 seconds and go to kernel debugger - fatal trap 12 >>>> stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d >>> At the debugger prompt, can you give the "bt" command, and show us what >>> the output is please? >> It: >> >> stopped at _mtx_lock_spin_failed+0x2f: movl 0x78(%r12),%r8d >> from bt, last string. >> or need all output? > > All output, please. it boot OK without options if_bwi_load="YES" in /boot/loader.conf FreeBSD HP.lissyara.su 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r196869: Sat Sep 5 23:27:07 MSD 2009 lissyara@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 > > Gavin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 17:21:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C08E3106566B for ; Mon, 7 Sep 2009 17:21:50 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) Received: from www.heimat.gr.jp (unknown [IPv6:2001:3e0:a84::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8431B8FC15 for ; Mon, 7 Sep 2009 17:21:50 +0000 (UTC) Received: from ra333.heimat.gr.jp.kankyo-u.ac.jp (ra333.heimat.gr.jp [IPv6:2001:3e0:a84:0:200:4cff:fe17:573c]) by www.heimat.gr.jp (8.14.3/8.14.3) with ESMTP id n87HLdja066624 for ; Tue, 8 Sep 2009 02:21:40 +0900 (JST) (envelope-from nakaji@kankyo-u.ac.jp) From: NAKAJI Hiroyuki To: freebsd-current@freebsd.org References: <20090829182437.GV37252@cicely7.cicely.de> Date: Tue, 08 Sep 2009 02:21:39 +0900 In-Reply-To: <20090829182437.GV37252@cicely7.cicely.de> (Bernd Walter's message of "Sat, 29 Aug 2009 20:24:37 +0200") Message-ID: <86ljkqk6vw.fsf@ra333.heimat.gr.jp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-6.1 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on www.heimat.gr.jp Subject: Re: ELF interpreter /libexec/ld-elf.so.1 not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 17:21:50 -0000 I hit the same error on RELENG_7/amd64 with another 32bit binary. Some new feature MFCed? >>>>> In <20090829182437.GV37252@cicely7.cicely.de> >>>>> Bernd Walter wrote: > I've recently updated one of my amd64 machines. > Now I notice that (at least some) 32bit binaries won't run anymore. -- NAKAJI Hiroyuki From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 17:31:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C39EC106568B for ; Mon, 7 Sep 2009 17:31:46 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3958FC0A for ; Mon, 7 Sep 2009 17:31:45 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n87HVh1v070002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Sep 2009 19:31:43 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n87HVfe7095841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Sep 2009 19:31:41 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n87HVf91016349; Mon, 7 Sep 2009 19:31:41 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n87HVdMI016348; Mon, 7 Sep 2009 19:31:39 +0200 (CEST) (envelope-from ticso) Date: Mon, 7 Sep 2009 19:31:39 +0200 From: Bernd Walter To: NAKAJI Hiroyuki Message-ID: <20090907173139.GG15218@cicely7.cicely.de> References: <20090829182437.GV37252@cicely7.cicely.de> <86ljkqk6vw.fsf@ra333.heimat.gr.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86ljkqk6vw.fsf@ra333.heimat.gr.jp> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.020, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-current@freebsd.org Subject: Re: ELF interpreter /libexec/ld-elf.so.1 not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 17:31:46 -0000 On Tue, Sep 08, 2009 at 02:21:39AM +0900, NAKAJI Hiroyuki wrote: > I hit the same error on RELENG_7/amd64 with another 32bit binary. > Some new feature MFCed? Bjoern A. Zeeb send me a patch, which at least worked with my binary. Don't know if it was commmited. > >>>>> In <20090829182437.GV37252@cicely7.cicely.de> > >>>>> Bernd Walter wrote: > > I've recently updated one of my amd64 machines. > > Now I notice that (at least some) 32bit binaries won't run anymore. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 17:48:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E97E106568D for ; Mon, 7 Sep 2009 17:48:32 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id B6FD98FC12 for ; Mon, 7 Sep 2009 17:48:31 +0000 (UTC) Received: by ewy4 with SMTP id 4so1029370ewy.36 for ; Mon, 07 Sep 2009 10:48:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.85.133 with SMTP id u5mr1555441wee.91.1252345709137; Mon, 07 Sep 2009 10:48:29 -0700 (PDT) In-Reply-To: <50e4b96fb035ba5eaf5e30fbf12bf9f2.squirrel@webmail.itac.at> References: <20090611194557.GC98175@bsdcrew.de> <991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com> <20090906162544.GA39448@bsdcrew.de> <50e4b96fb035ba5eaf5e30fbf12bf9f2.squirrel@webmail.itac.at> Date: Mon, 7 Sep 2009 19:48:29 +0200 Message-ID: <367b2c980909071048j79b28babwcc9d59488d1de3ef@mail.gmail.com> From: Olivier Smedts To: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Martin Wilke , freebsd-emulation@freebsd.org, ports@freebsd.org, Odhiambo Washington , freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 17:48:32 -0000 2009/9/7 Bernhard Fr=F6hlich : > On Mon, September 7, 2009 7:41 am, Danny Braniss wrote: >> >> [...] >>> > > > >>> > > ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is >>> no >>> > > longer available, there is a >>> > > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51= r20457.tar.bz2 >>> > > then again in ports/emulatores/virtualbox the version is >>> 3.0.51r22226, >>> > > >>> > > can someone please explain? >> >> hi, the above was my question, which was totally ignored, not nice. >> I will try and refrase it: >> the call for testing is for a version (2.2.51r20457) which is not >> available, while >> the ports is 3.0.51r22226, so while I managed to compile it, it complain= s >> that COM >> is not running, all this under 8BETA-3, both under 32 and 64 bit. > > I'll try to be nice but it is still unclear to me what you want. The file > is available on all 4 master sites that are listed in the ports Makefile. > > The virtualbox port is still in heavy development so it is strongly > recommended that you use the latest version that is in the ports. If that > also does not work you could give our svn version a try but be careful > with it because it can break in strange ways or destroy your virtual > machines. > > svn co > http://svn.bluelife.at/projects/packages/blueports/emulators/virtualbox/ Wow... the SVN version works great for me with VT extensions ! I just tried a 64 bits 2 processors guest :) Thanks ! > > -- > Bernhard Fr=F6hlich > http://www.bluelife.at/ > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > --=20 Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 18:05:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26D051065679 for ; Mon, 7 Sep 2009 18:05:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id D4D268FC19 for ; Mon, 7 Sep 2009 18:05:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id AD12041C64A; Mon, 7 Sep 2009 20:05:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id JZV7lfIACxJ1; Mon, 7 Sep 2009 20:05:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id E11B041C65E; Mon, 7 Sep 2009 20:05:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id A717D4448E6; Mon, 7 Sep 2009 18:00:20 +0000 (UTC) Date: Mon, 7 Sep 2009 18:00:20 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: ticso@cicely.de In-Reply-To: <20090907173139.GG15218@cicely7.cicely.de> Message-ID: <20090907175855.W68375@maildrop.int.zabbadoz.net> References: <20090829182437.GV37252@cicely7.cicely.de> <86ljkqk6vw.fsf@ra333.heimat.gr.jp> <20090907173139.GG15218@cicely7.cicely.de> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, NAKAJI Hiroyuki Subject: Re: ELF interpreter /libexec/ld-elf.so.1 not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 18:05:09 -0000 On Mon, 7 Sep 2009, Bernd Walter wrote: Hi, > On Tue, Sep 08, 2009 at 02:21:39AM +0900, NAKAJI Hiroyuki wrote: >> I hit the same error on RELENG_7/amd64 with another 32bit binary. >> Some new feature MFCed? > > Bjoern A. Zeeb send me a patch, which at least worked with my binary. > Don't know if it was commmited. It was comitted to HEAD, MFCed to stable/8 a few days ago and MFCed to stable/7 earlier today. /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 18:15:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11DE1106566B; Mon, 7 Sep 2009 18:15:55 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0258FC13; Mon, 7 Sep 2009 18:15:54 +0000 (UTC) Received: by bwz2 with SMTP id 2so504500bwz.43 for ; Mon, 07 Sep 2009 11:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=oFUwxgqDKPoCUp8thR/nGIKBR84MDBGUJF9BxSRMUSQ=; b=Sd/hIvn0x1wDynBG1XM+AS6c8FF1A5Z3vDfk8zqK0RalnRz3lRWo0tXT0m2cptf8zV LhX3Lo/jawoXjbymu+R/xQDb5yYIDkov5pJjIhojTk1qknYqvodIVcN2TyprqZSt12oW Ex+342IWyiiKnCdGArKedaHab5RJUPDgkEop0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ZsdQLqYNUE+o0DBlBoC/8crvPzcKhMvTHDosvdSan5vDNurF8i/ZAsLKNsFARgUytS b6GBI3lHzwCXoeuZWQKzrPjAI8FcqlESq3OH5Q9JNBS2Xw4vptTXHHx1s0+5sND1b2QC 6puG+xUmiMugutuoipq13fAJ2atiLZ3rwa3aw= MIME-Version: 1.0 Received: by 10.204.34.199 with SMTP id m7mr12256189bkd.48.1252347351707; Mon, 07 Sep 2009 11:15:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Sep 2009 22:15:48 +0400 Message-ID: From: pluknet To: FreeBSD Current , freebsd-emulation@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: acquiring duplicate lock of same type: "ftlk" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 18:15:55 -0000 2009/8/27 pluknet : > Hi. > > Got it on FreeBSD 9.0-CURRENT while been running in Xorg, don't know > where exactly. > > Acquiring duplicate lock of same type: "ftlk" > =A01st ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c= :177 > =A02nd ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c= :203 > KDB: stack backtrace: > db_trace_self_wrapper(c07fd8ea,ea393b58,c060a145,c05fac1b,c08007b2,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c05fac1b,c08007b2,c0b49757,c58ead20,ea393bb4,...) at > kdb_backtrace+0x29 > _witness_debugger(c08007b2,c0b49793,c0b49757,cb,0,...) at _witness_debugg= er+0x25 > witness_checkorder(c9bba780,9,c0b49757,cb,0,...) at witness_checkorder+0x= 469 > _sx_xlock(c9bba780,0,c0b49757,cb,0,...) at _sx_xlock+0x85 > futex_get0(c0609f8c,c09cc7a8,c9ac7764,c09cc7a8,c084df3c,...) at futex_get= 0+0x116 > linux_sys_futex(c9ac76c0,ea393cf8,ea393d18,ea393d1c,c0b4cf40,...) at > linux_sys_futex+0x6f > syscall(ea393d38) at syscall+0x2b4 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (240, Linux ELF, linux_sys_futex), eip =3D 0x28799533, esp = =3D > 0xbfbfc0cc, ebp =3D 0x4000001 --- > > This time seeing this LOR again but with another one just before. lock order reversal: 1st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:497 2nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292 KDB: stack backtrace: db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at kdb_backtrace+0x29 _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at _witness_debugger+0x25 witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at witness_checkorder+0x8= 39 _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85 pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at pfs_lookup+= 0x3dd VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...) at VOP_CACHEDLOOKUP_APV+0xc5 vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at vfs_cache_lookup+0xd6 VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at VOP_LOOKUP_APV+0xe5 lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at kern_alte= rnate _path+0x1cd linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at linux_emul_convpath+0x3c linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at linux_open+= 0x41 syscall(e8214d38) at syscall+0x2b4 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, Linux ELF, linux_open), eip =3D 0x2889115e, esp =3D 0xbfbfbd1c, ebp =3D 0xbfbfbd6c --- acquiring duplicate lock of same type: "ftlk" [...] I'm running head from 08/26. There were recent changes in pseudofs. Could it be fixed? Looks like it's connected to running firefox3 with linprocfs (for adobe fla= sh). --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 19:18:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F58B106566B; Mon, 7 Sep 2009 19:18:23 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id 031DD8FC13; Mon, 7 Sep 2009 19:18:21 +0000 (UTC) Received: by fxm6 with SMTP id 6so2090454fxm.43 for ; Mon, 07 Sep 2009 12:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=KBaRHDeieiO/XEw0N/JeWDvcbUPuf0zbtiJ8z+4OcL8=; b=DrZ4sTzYFnuoKoowrEUOjbhmLc9XTy/9hf2etmTkOUL3e5IIMA4ULKEwNYhaOmWkS9 xSMp3NKRsoFMOSSFFpPhsMON3IK9XF0eAelwrAddJ146BOI10m7YvaaCqWmb8ZP6TLU7 Y4y7Nj/c6QT15823V1lyTHlPFodPdtX+rjop0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=XMb8O4n3JdL2b6d9cil2PooamytGJv87gKhuzmAycs8/slI1nhzGZ5Jkwg91XYkOSZ BFlMeJVMN00PIZHyepZgOZ6jcf1Wz7wkeGZq1MRYaA7banQ4XI9i1u47jh1h9B1wWaWc qquH1VnH/vb7spO29Eu8P6XI/tphyXC/DWTrk= MIME-Version: 1.0 Received: by 10.204.19.141 with SMTP id a13mr12463627bkb.11.1252351100186; Mon, 07 Sep 2009 12:18:20 -0700 (PDT) In-Reply-To: References: <20090611194557.GC98175@bsdcrew.de> <991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com> <20090906162544.GA39448@bsdcrew.de> <991123400909061150h56dc6e07uf8d8e721f6c923bf@mail.gmail.com> From: Odhiambo Washington Date: Mon, 7 Sep 2009 22:18:00 +0300 Message-ID: <991123400909071218s2af7a76ybcac8702d697362f@mail.gmail.com> To: CmdLnKid Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 19:18:23 -0000 On Mon, Sep 7, 2009 at 7:45 PM, CmdLnKid wrote: > On Sun, 6 Sep 2009 14:50 -0000, odhiambo wrote: > > On Sun, Sep 6, 2009 at 7:25 PM, Martin Wilke wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On Sun, Sep 06, 2009 at 06:11:48PM +0300, Odhiambo Washington wrote: >>> >>>> On Sun, Sep 6, 2009 at 1:40 PM, Danny Braniss >>>> >>> wrote: >>> >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Huhu, >>>>>> >>>>>> Yes we life and that's good :-). >>>>>> Changes: >>>>>> >>>>>> - Fix build error when compiling in debug mode on FreeBSD HEAD >>>>>> - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite >>>>>> >>>>> timeout. >>> >>>> - Some FreeBSD relate typos >>>>>> - Enable shared OpenGL service. Completely untested due to lack of >>>>>> appropriate hardware but it compiles at least >>>>>> - Add support for shared clipboards. Requires libXt >>>>>> - FreeBSD: Implement preemption API for guest SMP and enable >>>>>> it (slightly tested). Add neccessary RTMP* methods in userspace >>>>>> for the frontends to detect the number of CPUs >>>>>> - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex >>>>>> instead of a spinlock to fix the problems users are seeing >>>>>> (assertions with debugging enabled) while still being able >>>>>> to run on 100Hz hosts. No problems detected so far and Solaris >>>>>> doesn't use a spin mutex in this code too so it shouldn't do >>>>>> any harm (keeping fingers crossed)space for the frontends to >>>>>> detect the number of CPUs >>>>>> - Add support for curl >>>>>> - Add VBoxSharedClipboard >>>>>> >>>>>> Ports Changes; >>>>>> - Force guestadditions version to 2.2.4 >>>>>> - Removed Qt3 include replacements (already upstream) >>>>>> - Removed cosmetic X11 include path patch >>>>>> >>>>>> Please make SURE, your world and kernel is in sync and you've read >>>>>> the pkg-messages. Also please unload the kernel module before >>>>>> you update the port ;-). >>>>>> >>>>>> Many thx to all Vbox Devs, All supporters, my nice team! :-) >>>>>> >>>>>> http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz >>>>>> >>>>>> >>>>> >>> >>>> >>>>>> Happy Testing! >>>>>> >>>>>> ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no >>>>> longer available, there is a >>>>> >>>>> >>> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2 >>> >>>> then again in ports/emulatores/virtualbox the version is 3.0.51r22226, >>>>> >>>>> can someone please explain? >>>>> >>>>> >>>>> >>>> >>>> And on my FreeBSD 7.2-STABLE, compiling virtualbox fails as follows: >>>> >>>> >>>> >>>> kBuild: Linking VBoxREM64 >>>> kBuild: Installing VBoxREM64 => >>>> >>>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBox >>> >>>> REM64.so >>>> kmk[2]: Leaving directory >>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' >>>> kmk[1]: Leaving directory >>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' >>>> kBuild: Pass - Programs >>>> kmk[1]: Entering directory >>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' >>>> kmk[2]: Entering directory >>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' >>>> kBuild: Compiling tstAPI - >>>> >>>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/src/VBox/Main/testcase/tstAPI.cpp >>> >>>> kBuild: Linking tstAPI >>>> /usr/local/lib/libssl.so.5: undefined reference to `d2i_X509_EXTENSIONS' >>>> /usr/local/lib/libssl.so.5: undefined reference to >>>> `ENGINE_get_ssl_client_cert_function' >>>> /usr/local/lib/libssl.so.5: undefined reference to `HMAC_CTX_set_flags' >>>> /usr/local/lib/libssl.so.5: undefined reference to `i2d_X509_EXTENSIONS' >>>> /usr/local/lib/libssl.so.5: undefined reference to >>>> `ENGINE_load_ssl_client_cert' >>>> /usr/local/lib/libssl.so.5: undefined reference to `pqueue_size' >>>> /usr/local/lib/libssl.so.5: undefined reference to `EVP_idea_cbc' >>>> kmk[2]: *** >>>> >>>> [/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/obj/tstAPI/tstAPI] >>> >>>> Error 1 >>>> The failing command: >>>> @g++ '-Wl,-rpath,/usr/local/lib/virtualbox' -m32 -o >>>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r >>>> 22226/out/freebsd.x86/release/obj/tstAPI/tstAPI >>>> >>>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/ >>> >>>> release/obj/tstAPI/tstAPI.o -L/usr/lib -L/usr/X11R6/lib >>>> -L/usr/local/lib >>>> /usr/ports/emulators/virtualbox/work/virtualbo >>>> x-3.0.51r22226/out/freebsd.x86/release/bin/VBoxRT.so >>>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freeb >>>> sd.x86/release/lib/VBoxCOM.a >>>> >>>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBoxX >>> >>>> PCOM.so >>>> kmk[2]: Leaving directory >>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' >>>> kmk[1]: *** [pass_binaries_this] Error 2 >>>> kmk[1]: Leaving directory >>>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' >>>> kmk: *** [pass_binaries_order] Error 2 >>>> *** Error code 2 >>>> >>>> Stop in /usr/ports/emulators/virtualbox. >>>> >>>> >>>> I hope someone can advise on what is needed. >>>> >>>> >>> deinstall openssl from ports and try again :) >>> >>> >>> I remember we had this suggestion before, and either you (or someone >> else) >> was going to look into the use of openssl from the ports:-) >> Looks like I will have to recompile most apps that have linked against >> openssl, no? >> >> > Just create a backup package of your openssl port with ( pkg_create -b ) > then uninstall the port, rebuild the port in question and ( pkg_add ) the > openssl port again. This will at least get the port out of the way for you > to complete the build and will let you determine further action. > > It's not such a critical box. It's a testbed nyway so I did not bother backing up anything since I will be able to fix any broken packages. Let me see how it goes. So far so good.... the build process is running... -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "If you have nothing good to say about someone, just shut up!." -- Lucky Dube From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 20:21:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9429106566B for ; Mon, 7 Sep 2009 20:21:47 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 2240B8FC17 for ; Mon, 7 Sep 2009 20:21:46 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n87KLju8057880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Sep 2009 22:21:46 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4AA56B59.1060702@omnilan.de> Date: Mon, 07 Sep 2009 22:21:45 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: "Carlos A. M. dos Santos" References: <4AA33DF9.6070803@omnilan.de> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig35EA91877266B3E510F3871C" Cc: freebsd-current@freebsd.org Subject: Re: Funding ODD support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 20:21:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig35EA91877266B3E510F3871C Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Carlos A. M. dos Santos schrieb am 07.09.2009 16:32 (localtime): > On Sun, Sep 6, 2009 at 1:43 AM, Harald > Schmalzbauer wrote: >> Hello, >> >> I'm looking for somebody who has time and knowledge to fix ODD support= in >> FreeBSD. > [...] >=20 > I'm not sure if such work should be funded by a separate bounty or by > the FreeBSD foundation. Anyway, I would happily donate some money for > improvements on the CD/DVD writing support. I'd like to see either an > improved version of burncd or some new tool provided by the base > system. I haven't done any "official application" because of my felt severity yet= =2E For a long term project the FreeBSD foundation was the better way, I thin= k. But I hoped somebody would be able to fix it before 8.0-RELEASE, which=20 is not too far away. I just got one more reply from another fellow willing to donate for=20 fixing ODD support, but no reply from any coder yet... All in all, not much response. It seems the ones using ODDs are considering the problems as quiet=20 severe, but it also seems there are not many fellows missing working ODD = support. Is the media itself really outdated? I haven't done any blu-ray=20 experiments under FreeBSD yet, but I can't imagine things are working=20 better with that media. So for now the pot is about 500 bucks. Anyone to pick up? Regards, -Harry --------------enig35EA91877266B3E510F3871C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkqla1kACgkQLDqVQ9VXb8j8wQCdEPkbvsX0Mo6pe3camSRP6Bj9 h/gAoLCUrs+vweAnnvQ34NgXvw/WaS5v =pqhL -----END PGP SIGNATURE----- --------------enig35EA91877266B3E510F3871C-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 17:08:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3050C106566B; Mon, 7 Sep 2009 17:08:44 +0000 (UTC) (envelope-from cmdlnkid@gmail.com) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 8681C8FC1B; Mon, 7 Sep 2009 17:08:43 +0000 (UTC) Received: by yxe2 with SMTP id 2so5244354yxe.3 for ; Mon, 07 Sep 2009 10:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :in-reply-to:message-id:references:user-agent:x-openpgp-key-id :x-openpgp-key-fingerprint:mime-version:content-type; bh=L/EgjxQXSscYzAIyInrm2t12oWfddP+9ldGK9li6TRs=; b=D8gSP3OhRdOeNwti/0HduaNhSXINa4SZf1IAR0JkEtl7orlK6cD5UwpwcCF8kKeEGw d+B+ctEDEUo6ptTZJYCVClKcpG31/wZyVMeORnYXtNPngo/7rAWO1s09hhEAP61iL5Yd NmsBqAc3gSUNK8GnwXOVsGSk04Rv2GT0pV6sg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=OIQEPHeYQspnPygf2/V0NhOFTLVr1m1kZIWLREtbioDlDUGyE9DNVmp3B89RJHkIVM cXMT1kw7X2+6Aq01T5ARgf4GnCGpiIY0qhy5FiNvzN9QoL25qPr80YTEQfA4N/Xo35Kl +1DHH3RFrnuYiXV9P1gxozQKL+utdK3Vqto4E= Received: by 10.91.95.5 with SMTP id x5mr11392845agl.28.1252341921194; Mon, 07 Sep 2009 09:45:21 -0700 (PDT) Received: from firewall.5p.local (adsl-99-19-45-98.dsl.klmzmi.sbcglobal.net [99.19.45.98]) by mx.google.com with ESMTPS id 2sm5770577aga.58.2009.09.07.09.45.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Sep 2009 09:45:19 -0700 (PDT) Date: Mon, 7 Sep 2009 12:45:05 -0400 From: CmdLnKid To: Odhiambo Washington In-Reply-To: <991123400909061150h56dc6e07uf8d8e721f6c923bf@mail.gmail.com> Message-ID: References: <20090611194557.GC98175@bsdcrew.de> <991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com> <20090906162544.GA39448@bsdcrew.de> <991123400909061150h56dc6e07uf8d8e721f6c923bf@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-ID: 0xDFFDD218 X-OpenPGP-Key-Fingerprint: 2924 1C72 A6C2 852A 2094 25EE 9968 2636 DFFD D218 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 07 Sep 2009 20:48:31 +0000 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 17:08:44 -0000 On Sun, 6 Sep 2009 14:50 -0000, odhiambo wrote: > On Sun, Sep 6, 2009 at 7:25 PM, Martin Wilke wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On Sun, Sep 06, 2009 at 06:11:48PM +0300, Odhiambo Washington wrote: >>> On Sun, Sep 6, 2009 at 1:40 PM, Danny Braniss >> wrote: >>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Huhu, >>>>> >>>>> Yes we life and that's good :-). >>>>> Changes: >>>>> >>>>> - Fix build error when compiling in debug mode on FreeBSD HEAD >>>>> - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite >> timeout. >>>>> - Some FreeBSD relate typos >>>>> - Enable shared OpenGL service. Completely untested due to lack of >>>>> appropriate hardware but it compiles at least >>>>> - Add support for shared clipboards. Requires libXt >>>>> - FreeBSD: Implement preemption API for guest SMP and enable >>>>> it (slightly tested). Add neccessary RTMP* methods in userspace >>>>> for the frontends to detect the number of CPUs >>>>> - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex >>>>> instead of a spinlock to fix the problems users are seeing >>>>> (assertions with debugging enabled) while still being able >>>>> to run on 100Hz hosts. No problems detected so far and Solaris >>>>> doesn't use a spin mutex in this code too so it shouldn't do >>>>> any harm (keeping fingers crossed)space for the frontends to >>>>> detect the number of CPUs >>>>> - Add support for curl >>>>> - Add VBoxSharedClipboard >>>>> >>>>> Ports Changes; >>>>> - Force guestadditions version to 2.2.4 >>>>> - Removed Qt3 include replacements (already upstream) >>>>> - Removed cosmetic X11 include path patch >>>>> >>>>> Please make SURE, your world and kernel is in sync and you've read >>>>> the pkg-messages. Also please unload the kernel module before >>>>> you update the port ;-). >>>>> >>>>> Many thx to all Vbox Devs, All supporters, my nice team! :-) >>>>> >>>>> http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz >> >>>>> >>>>> Happy Testing! >>>>> >>>> ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no >>>> longer available, there is a >>>> >> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2 >>>> then again in ports/emulatores/virtualbox the version is 3.0.51r22226, >>>> >>>> can someone please explain? >>>> >>>> >>> >>> >>> And on my FreeBSD 7.2-STABLE, compiling virtualbox fails as follows: >>> >>> >>> >>> kBuild: Linking VBoxREM64 >>> kBuild: Installing VBoxREM64 => >>> >> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBox >>> REM64.so >>> kmk[2]: Leaving directory >>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' >>> kmk[1]: Leaving directory >>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' >>> kBuild: Pass - Programs >>> kmk[1]: Entering directory >>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' >>> kmk[2]: Entering directory >>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' >>> kBuild: Compiling tstAPI - >>> >> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/src/VBox/Main/testcase/tstAPI.cpp >>> kBuild: Linking tstAPI >>> /usr/local/lib/libssl.so.5: undefined reference to `d2i_X509_EXTENSIONS' >>> /usr/local/lib/libssl.so.5: undefined reference to >>> `ENGINE_get_ssl_client_cert_function' >>> /usr/local/lib/libssl.so.5: undefined reference to `HMAC_CTX_set_flags' >>> /usr/local/lib/libssl.so.5: undefined reference to `i2d_X509_EXTENSIONS' >>> /usr/local/lib/libssl.so.5: undefined reference to >>> `ENGINE_load_ssl_client_cert' >>> /usr/local/lib/libssl.so.5: undefined reference to `pqueue_size' >>> /usr/local/lib/libssl.so.5: undefined reference to `EVP_idea_cbc' >>> kmk[2]: *** >>> >> [/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/obj/tstAPI/tstAPI] >>> Error 1 >>> The failing command: >>> @g++ '-Wl,-rpath,/usr/local/lib/virtualbox' -m32 -o >>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r >>> 22226/out/freebsd.x86/release/obj/tstAPI/tstAPI >>> >> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/ >>> release/obj/tstAPI/tstAPI.o -L/usr/lib -L/usr/X11R6/lib >>> -L/usr/local/lib >>> /usr/ports/emulators/virtualbox/work/virtualbo >>> x-3.0.51r22226/out/freebsd.x86/release/bin/VBoxRT.so >>> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freeb >>> sd.x86/release/lib/VBoxCOM.a >>> >> /usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226/out/freebsd.x86/release/bin/VBoxX >>> PCOM.so >>> kmk[2]: Leaving directory >>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' >>> kmk[1]: *** [pass_binaries_this] Error 2 >>> kmk[1]: Leaving directory >>> `/usr/ports/emulators/virtualbox/work/virtualbox-3.0.51r22226' >>> kmk: *** [pass_binaries_order] Error 2 >>> *** Error code 2 >>> >>> Stop in /usr/ports/emulators/virtualbox. >>> >>> >>> I hope someone can advise on what is needed. >>> >> >> deinstall openssl from ports and try again :) >> >> > I remember we had this suggestion before, and either you (or someone else) > was going to look into the use of openssl from the ports:-) > Looks like I will have to recompile most apps that have linked against > openssl, no? > Just create a backup package of your openssl port with ( pkg_create -b ) then uninstall the port, rebuild the port in question and ( pkg_add ) the openssl port again. This will at least get the port out of the way for you to complete the build and will let you determine further action. Best regards. -- - (2^(N-1)) From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 21:06:19 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CAF61065672 for ; Mon, 7 Sep 2009 21:06:19 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id DDC508FC1E for ; Mon, 7 Sep 2009 21:06:18 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 227B21E0037D; Mon, 7 Sep 2009 23:06:17 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n87Kxu1x093121; Mon, 7 Sep 2009 22:59:56 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id n87Kxtic093120; Mon, 7 Sep 2009 22:59:55 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Mon, 7 Sep 2009 22:59:55 +0200 To: Juergen Lock Message-ID: <20090907205955.GA91866@triton8.kn-bremen.de> References: <4A93AFF9.1060201@web.de> <52d4a3890908250316l4de68725xa9d780e7d5b37205@mail.gmail.com> <52d4a3890908250321u746e5757u136030bcbc19208d@mail.gmail.com> <4A93BF0C.8040601@web.de> <20090826221001.GA1070@triton8.kn-bremen.de> <4A96C8D9.6070804@web.de> <20090829211848.GA59305@triton8.kn-bremen.de> <4A9B800F.1040209@web.de> <20090831212723.GA32448@triton8.kn-bremen.de> <20090901201248.GA60123@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090901201248.GA60123@triton8.kn-bremen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Mohammed Gamal , freebsd-current@FreeBSD.org, Jan Kiszka , qemu-devel@nongnu.org, Avi Kivity Subject: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 21:06:19 -0000 [I'm copying freebsd-current@FreeBSD.org because ppl there might know more about this...] qemu on FreeBSD hosts used to be able to run a (FreeBSD at least) guest with the same HZ as the host (like, 1000) with (mostly) proper timing once, but no longer. :( It seems there are two problems involved: a) use of apic seems to cause the clock irq rate to be doubled to 2 * HZ (can anyone explain why?), i.e. a FreeBSD 7 guest on a FreeBSD 7 host only gets proper timing after setting hint.apic.0.disabled=1 via the loader. (as can be verified by `vmstat -i' and `time sleep 2' in an installed guest or via the fixit->cdrom/dvd shell on a FreeBSD livefs or dvd1 iso.) b) qemu running on FreeBSD 8 hosts (and most likely head) has the additional problem of running its timers only at HZ/2 when using setitimer(2) (called `-clock unix' in qemu), as seen below. (as also seen below, timer_settime(2) aka `-clock dynticks' in qemu behaves even worse, but that is similarly true on FreeBSD 7 which is why I removed the patch that enabled that from our qemu port(s) a few days ago.) And the only reason FreeBSD 8 guests are usually less affected by these problems is they now reduce their HZ to 100 when they detect being run in a VM. (which makes sense for other reasons as well, don't get me wrong... but of course doesn't help when the host is running with HZ=100 too.) On Tue, Sep 01, 2009 at 10:12:48PM +0200, Juergen Lock wrote: > On Mon, Aug 31, 2009 at 11:27:23PM +0200, Juergen Lock wrote: > > On Mon, Aug 31, 2009 at 09:47:27AM +0200, Jan Kiszka wrote: > > > Juergen Lock wrote: > > > > On Thu, Aug 27, 2009 at 07:56:41PM +0200, Jan Kiszka wrote: > > > >> Juergen Lock wrote: > > > >>> On Tue, Aug 25, 2009 at 12:38:04PM +0200, Jan Kiszka wrote: > > > >>>> Mohammed Gamal wrote: > > > >>>>> On Tue, Aug 25, 2009 at 1:16 PM, Mohammed Gamal wrote: > > > >>>>>> On Tue, Aug 25, 2009 at 12:33 PM, Jan Kiszka wrote: > > > >>>>>>> Mohammed Gamal wrote: > > > >>>>>>>> qemu-system-x86_64 -hda /dev/null -cdrom > > > >>>>>>>> > > > >>>>>>> I only have kubuntu-9.04-alternate-amd64.iso at hand ATM, and with that > > > >>>>>>> image I'm unable to reproduce. Will download and check standard ubuntu > > > >>>>>>> later today. > > > >>>>>>> > > > >>>>>>>> I was using qemu-kvm, but I assume that using -no-kvm would be > > > >>>>>>>> equivalent to using plain qemu, no? > > > >>>>>>> Generally yes, but not necessarily (e.g. the BIOSes are different). So > > > >>>>>>> it's better to check such issues also against "clean" qemu, specifically > > > >>>>>>> as we are on qemu-devel here. > > > >>>>>>> > > > >>>>>>> Jan > > > >>>>>>> > > > >>>>>>> > > > >>>>>> Just tested this now on a vanilla qemu, I am still able to reproduce > > > >>>>>> the same issue. > > > >>>>>> > > > >>>>> This bug might be related to the same problem > > > >>>>> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/379000 > > > >>>> I think at least those issues should be solved with recent qemu and > > > >>>> bioses. Note that this report refers to a fairly old qemu version > > > >>>> (0.10.0-derived). > > > >>> Btw I had reported the same symptom as in that ubuntu ticket for FreeBSD 8 > > > >>> hosts both with 0.10.6 and 0.11.0rc1 before: > > > >>> http://lists.gnu.org/archive/html/qemu-devel/2009-08/msg00396.html > > > >>> As mentioned in that post I was able to work around the issue by passig > > > >>> the linux guest kernels `no_timer_check' after which they seemed to boot up > > > >>> just fine, so I suspect in that case its not actually an apic routing > > > >>> problem but just guest timer irqs arriving late/irregularly which cause > > > >>> the guest kernel timer checks to time out and fail. > > > >> Does this happen with git head and its corresponding bios, too? I cannot > > > >> imagine that the FreeBSD platform is so irregularly generating timer > > > >> events for qemu that Linux gets unhappy during this test loop (I think > > > >> to remember it needs 3 out of 10 ticks or so to be satisfied). > > > > > > > > Alright so I testwise updated the FreeBSD qemu-devel port to git head > > > > (db3c9e08e0d6eaf83f9d7a2c87dc45af3ac8f4dd, update at > > > > http://people.freebsd.org/~nox/qemu/qemu-devel-20090829.patch > > > > > > You will have to help me isolating the reason as I don't have any BSD > > > host. And running recent qemu/-kvm on Linux hosts does not trigger > > > problems around booting ubuntu here. > > > > Well I don't quite know where to start looking, of course I'd be > > happy to test patches... :) > > Ok I now found the #if 0 in vl.c:host_alarm_handler(), enabled it and got > this with a FreeBSD 7.2 iso (which defaults to HZ=1000) and -clock dynticks: > ..and this was on a FreeBSD 8 host: > timer: min=2555 us max=32004 us avg=5150 us avg_freq=194.149 Hz > timer: min=2451 us max=7205 us avg=3012 us avg_freq=331.960 Hz > timer: min=2855 us max=7994 us avg=3019 us avg_freq=331.191 Hz > timer: min=2099 us max=20003 us avg=3057 us avg_freq=327.073 Hz > timer: min=2143 us max=11897 us avg=3081 us avg_freq=324.527 Hz > timer: min=2110 us max=80014 us avg=3165 us avg_freq=315.913 Hz > timer: min=2088 us max=51999 us avg=3206 us avg_freq=311.873 Hz > > and this with the same guest and -clock unix: > > timer: min=1614 us max=7121 us avg=2009 us avg_freq=497.692 Hz > timer: min=876 us max=11134 us avg=2016 us avg_freq=495.967 Hz > timer: min=753 us max=9245 us avg=2014 us avg_freq=496.455 Hz > timer: min=1798 us max=6211 us avg=2008 us avg_freq=497.941 Hz > timer: min=1772 us max=6142 us avg=2008 us avg_freq=497.943 Hz > timer: min=1767 us max=6157 us avg=2008 us avg_freq=497.942 Hz > timer: min=14 us max=6139 us avg=2008 us avg_freq=497.939 Hz > timer: min=736 us max=9969 us avg=2016 us avg_freq=495.962 Hz > timer: min=176 us max=11427 us avg=2076 us avg_freq=481.631 Hz > timer: min=229 us max=9827 us avg=2030 us avg_freq=492.546 Hz > timer: min=430 us max=11082 us avg=2078 us avg_freq=481.166 Hz > timer: min=226 us max=9871 us avg=2026 us avg_freq=493.517 Hz > timer: min=605 us max=10829 us avg=2082 us avg_freq=480.243 Hz > timer: min=57 us max=10976 us avg=2028 us avg_freq=493.031 Hz > timer: min=398 us max=11036 us avg=2080 us avg_freq=480.704 Hz > > `vmstat -i' in the guest (available e.g. from the fixit->cdrom/dvd shell > on a livefs or dvd1 iso) gives similar values as avg_freq above for the > `cpu0: timer' irq rate. (Btw, FreeBSD 8 reduces its HZ to 100 when > running in a vm so the `vmstat -i' values will be a little lower if you > try that as a guest.) > > And `vmstat -i' on the host (also running with HZ=1000) reports a > rate of 1999 for each cpu's timer irq, so there are clearly quite a few > irqs missing there... > > (Btw I'm wondering if the poor usb performance I reported a long time > ago already could be related to this also...) And here is the same guest with -clock unix on a FreeBSD 7 host: (same with and without apic, except of course that only without apic timing in the guest is ok.) timer: min=847 us max=6146 us avg=1005 us avg_freq=994.950 Hz timer: min=866 us max=6130 us avg=1005 us avg_freq=994.960 Hz timer: min=868 us max=6133 us avg=1005 us avg_freq=994.958 Hz timer: min=287 us max=35199 us avg=1089 us avg_freq=918.216 Hz timer: min=201 us max=13551 us avg=1029 us avg_freq=971.757 Hz timer: min=792 us max=6211 us avg=1005 us avg_freq=994.961 Hz timer: min=145 us max=6185 us avg=1007 us avg_freq=992.984 Hz timer: min=852 us max=6152 us avg=1005 us avg_freq=994.961 Hz timer: min=820 us max=6175 us avg=1005 us avg_freq=994.960 Hz timer: min=654 us max=6242 us avg=1005 us avg_freq=994.966 Hz timer: min=675 us max=6196 us avg=1005 us avg_freq=994.952 Hz timer: min=829 us max=6162 us avg=1005 us avg_freq=994.960 Hz timer: min=503 us max=6136 us avg=1005 us avg_freq=994.960 Hz timer: min=859 us max=6138 us avg=1005 us avg_freq=994.960 Hz timer: min=856 us max=6149 us avg=1005 us avg_freq=994.960 Hz timer: min=832 us max=6164 us avg=1005 us avg_freq=994.961 Hz timer: min=829 us max=6174 us avg=1005 us avg_freq=994.958 Hz timer: min=826 us max=6173 us avg=1005 us avg_freq=994.960 Hz timer: min=828 us max=6168 us avg=1005 us avg_freq=994.961 Hz timer: min=841 us max=6160 us avg=1005 us avg_freq=994.960 Hz timer: min=857 us max=6135 us avg=1005 us avg_freq=994.959 Hz timer: min=857 us max=6139 us avg=1005 us avg_freq=994.959 Hz timer: min=845 us max=6147 us avg=1005 us avg_freq=994.960 Hz timer: min=854 us max=6143 us avg=1005 us avg_freq=994.960 Hz timer: min=854 us max=6142 us avg=1005 us avg_freq=994.960 Hz timer: min=857 us max=6142 us avg=1005 us avg_freq=994.960 Hz timer: min=859 us max=6141 us avg=1005 us avg_freq=994.961 Hz timer: min=849 us max=6141 us avg=1005 us avg_freq=994.962 Hz timer: min=857 us max=6143 us avg=1005 us avg_freq=994.962 Hz timer: min=864 us max=6138 us avg=1005 us avg_freq=994.958 Hz timer: min=863 us max=6139 us avg=1005 us avg_freq=994.961 Hz timer: min=869 us max=6136 us avg=1005 us avg_freq=994.960 Hz timer: min=857 us max=6143 us avg=1005 us avg_freq=994.959 Hz timer: min=865 us max=6133 us avg=1005 us avg_freq=994.960 Hz And the same guest/host with -clock dynticks: timer: min=1657 us max=32164 us avg=6732 us avg_freq=148.534 Hz timer: min=1675 us max=7158 us avg=2010 us avg_freq=497.480 Hz timer: min=1773 us max=7200 us avg=2010 us avg_freq=497.480 Hz timer: min=1798 us max=7148 us avg=2010 us avg_freq=497.480 Hz timer: min=1851 us max=7144 us avg=2013 us avg_freq=496.739 Hz timer: min=1821 us max=7136 us avg=2020 us avg_freq=495.017 Hz timer: min=1823 us max=7173 us avg=2010 us avg_freq=497.480 Hz timer: min=1825 us max=39002 us avg=2076 us avg_freq=481.664 Hz timer: min=1851 us max=7145 us avg=2012 us avg_freq=496.985 Hz timer: min=1855 us max=16998 us avg=2106 us avg_freq=474.803 Hz timer: min=1855 us max=7138 us avg=2010 us avg_freq=497.480 Hz timer: min=1858 us max=7136 us avg=2010 us avg_freq=497.480 Hz timer: min=1856 us max=7138 us avg=2010 us avg_freq=497.480 Hz timer: min=1855 us max=7138 us avg=2017 us avg_freq=495.754 Hz timer: min=1818 us max=7143 us avg=2009 us avg_freq=497.728 Hz timer: min=1851 us max=7141 us avg=2010 us avg_freq=497.480 Hz timer: min=1859 us max=7140 us avg=2010 us avg_freq=497.480 Hz timer: min=1851 us max=7138 us avg=2010 us avg_freq=497.480 Hz For people wanting to experiment, you can escape to the loader prompt from the FreeBSD boot menu and then type: set hint.apic.0.disabled=1 and optionally: set kern.hz="1000" and then: boot -v (for verbose dmesg, otherwise `boot' without the -v.) Any enlightnig comments appreciated... :) Juergen From owner-freebsd-current@FreeBSD.ORG Mon Sep 7 23:40:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D50A4106566B for ; Mon, 7 Sep 2009 23:40:48 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) Received: from www.heimat.gr.jp (unknown [IPv6:2001:3e0:a84::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9A63A8FC15 for ; Mon, 7 Sep 2009 23:40:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at heimat.gr.jp Received: from ra333.heimat.gr.jp.kankyo-u.ac.jp (ra333.heimat.gr.jp [IPv6:2001:3e0:a84:0:200:4cff:fe17:573c]) by www.heimat.gr.jp (8.14.3/8.14.3) with ESMTP id n87Ne9QK015612; Tue, 8 Sep 2009 08:40:10 +0900 (JST) (envelope-from nakaji@kankyo-u.ac.jp) From: NAKAJI Hiroyuki To: "Bjoern A. Zeeb" References: <20090829182437.GV37252@cicely7.cicely.de> <86ljkqk6vw.fsf@ra333.heimat.gr.jp> <20090907173139.GG15218@cicely7.cicely.de> <20090907175855.W68375@maildrop.int.zabbadoz.net> Date: Tue, 08 Sep 2009 08:40:09 +0900 In-Reply-To: <20090907175855.W68375@maildrop.int.zabbadoz.net> (Bjoern A. Zeeb's message of "Mon, 7 Sep 2009 18:00:20 +0000 (UTC)") Message-ID: <86eiqijpd2.fsf@ra333.heimat.gr.jp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-6.1 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on www.heimat.gr.jp Cc: freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: ELF interpreter /libexec/ld-elf.so.1 not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 23:40:48 -0000 >>>>> In <20090907175855.W68375@maildrop.int.zabbadoz.net> >>>>> "Bjoern A. Zeeb" wrote: > > On Tue, Sep 08, 2009 at 02:21:39AM +0900, NAKAJI Hiroyuki wrote: > >> I hit the same error on RELENG_7/amd64 with another 32bit binary. > >> Some new feature MFCed? > > > > Bjoern A. Zeeb send me a patch, which at least worked with my binary. > > Don't know if it was commmited. > It was comitted to HEAD, MFCed to stable/8 a few days ago and MFCed > to stable/7 earlier today. Thanks. Is it r196924? http://lists.freebsd.org/pipermail/svn-src-stable-7/2009-September/001900.html -- NAKAJI Hiroyuki From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 02:17:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4A98106566B for ; Tue, 8 Sep 2009 02:17:24 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 427168FC13 for ; Tue, 8 Sep 2009 02:17:24 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 4so1467902eyf.9 for ; Mon, 07 Sep 2009 19:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QKVS75gDVgBiEky+47WuUYfJJGgDMC293DOlXjOXKlQ=; b=t7bp3HZJppyiSHHvrf0GfpUVlBvHzPKHHeYPfWX6AzGApsr4dxI4gAWMut1Zgdx+eR KWfPsK4YXvhYs6SvUnBQL45olL3Xze9bimJmt1NJBbRKpnnl9bFIajjE9CpeZanQmsEo A6Acp2qboD7mxQtB8MI3oXUGHcAzqtDb3Sj50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YQH1BLjlu/b6/h154o8zJzxoRFwUNJ/B4/g0xteeP+PC8uwKwrUdJPlifKR9PYr5Vk d7t7KFwnAWIplkgvVVECTTMAV9aujUD3MiVcVpITPt5NDUU9GqhShLNI1jbbsE7LTuw5 eQqfpp1VPxsk5DKV1XexvQlMfvE8w1IlUubJQ= MIME-Version: 1.0 Received: by 10.211.154.7 with SMTP id g7mr16971910ebo.10.1252376243426; Mon, 07 Sep 2009 19:17:23 -0700 (PDT) In-Reply-To: <20090907205955.GA91866@triton8.kn-bremen.de> References: <4A93AFF9.1060201@web.de> <52d4a3890908250321u746e5757u136030bcbc19208d@mail.gmail.com> <4A93BF0C.8040601@web.de> <20090826221001.GA1070@triton8.kn-bremen.de> <4A96C8D9.6070804@web.de> <20090829211848.GA59305@triton8.kn-bremen.de> <4A9B800F.1040209@web.de> <20090831212723.GA32448@triton8.kn-bremen.de> <20090901201248.GA60123@triton8.kn-bremen.de> <20090907205955.GA91866@triton8.kn-bremen.de> Date: Mon, 7 Sep 2009 22:17:23 -0400 Message-ID: From: Ryan Stone To: Juergen Lock Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Mohammed Gamal , freebsd-current@freebsd.org, Jan Kiszka , qemu-devel@nongnu.org, Avi Kivity Subject: Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 02:17:26 -0000 I'm not entirely clear on why it's done this way, but the timer is run at twice hz for statistics-gathering purposes*. CPU usage statistics gathering is driven off of the timer interrupt. Running the timer at twice hz may be an attempt to eliminate clock-aliasing problems; if so, it's a poor way of doing so. In any case, seeing interrupts come in at twice hz is expected behaviour. This means that the guest will be requesting a timer interrupt rate of twice the granularity that the host's scheduler can support; this may be the cause of your other timing problems(although I have a hard time imagining how). This timer is twice hz behaviour has existed at least since FreeBSD 6.1, so I can't explain why you see the new behaviour between 7 and 8. You do have hz set to 1000 on both the guest and host when running 7? * Actually, from looking at the code the behaviour is dynamic. If hz >= 1500, the timer interrupt rate is set to hz. If 750 <= hz < 1500, the timer interrupt rate is set to 2 * hz. If hz < 750, the timer interrupt rate is set to 4 * hz. From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 05:55:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DF9F1065693 for ; Tue, 8 Sep 2009 05:55:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id CB4648FC12 for ; Tue, 8 Sep 2009 05:55:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id E6E3C41C6B4; Tue, 8 Sep 2009 07:55:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id dH4uyUNoHg5B; Tue, 8 Sep 2009 07:55:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 3384241C6A7; Tue, 8 Sep 2009 07:55:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 68F964448E6; Tue, 8 Sep 2009 05:51:27 +0000 (UTC) Date: Tue, 8 Sep 2009 05:51:27 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: NAKAJI Hiroyuki In-Reply-To: <86eiqijpd2.fsf@ra333.heimat.gr.jp> Message-ID: <20090908055055.C68375@maildrop.int.zabbadoz.net> References: <20090829182437.GV37252@cicely7.cicely.de> <86ljkqk6vw.fsf@ra333.heimat.gr.jp> <20090907173139.GG15218@cicely7.cicely.de> <20090907175855.W68375@maildrop.int.zabbadoz.net> <86eiqijpd2.fsf@ra333.heimat.gr.jp> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: ELF interpreter /libexec/ld-elf.so.1 not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 05:55:08 -0000 On Tue, 8 Sep 2009, NAKAJI Hiroyuki wrote: Good morning, >>>>>> In <20090907175855.W68375@maildrop.int.zabbadoz.net> >>>>>> "Bjoern A. Zeeb" wrote: > >>> On Tue, Sep 08, 2009 at 02:21:39AM +0900, NAKAJI Hiroyuki wrote: >>>> I hit the same error on RELENG_7/amd64 with another 32bit binary. >>>> Some new feature MFCed? >>> >>> Bjoern A. Zeeb send me a patch, which at least worked with my binary. >>> Don't know if it was commmited. > >> It was comitted to HEAD, MFCed to stable/8 a few days ago and MFCed >> to stable/7 earlier today. > > Thanks. Is it r196924? > http://lists.freebsd.org/pipermail/svn-src-stable-7/2009-September/001900.html Yes, exactly. /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 07:26:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D47DF106566B for ; Tue, 8 Sep 2009 07:26:51 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id AE89E8FC16 for ; Tue, 8 Sep 2009 07:26:51 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Mkv6I-00058B-RO for freebsd-current@freebsd.org; Tue, 08 Sep 2009 00:26:50 -0700 Message-ID: <25341094.post@talk.nabble.com> Date: Tue, 8 Sep 2009 00:26:50 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org In-Reply-To: <4AA56B59.1060702@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <4AA33DF9.6070803@omnilan.de> <4AA56B59.1060702@omnilan.de> Subject: Re: Funding ODD support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 07:26:51 -0000 Harald Schmalzbauer-7 wrote: > > Carlos A. M. dos Santos schrieb am 07.09.2009 16:32 (localtime): >> On Sun, Sep 6, 2009 at 1:43 AM, Harald >> Schmalzbauer wrote: >>> Hello, >>> >>> I'm looking for somebody who has time and knowledge to fix ODD support >>> in >>> FreeBSD. >> [...] >> >> I'm not sure if such work should be funded by a separate bounty or by >> the FreeBSD foundation. Anyway, I would happily donate some money for >> improvements on the CD/DVD writing support. I'd like to see either an >> improved version of burncd or some new tool provided by the base >> system. > > I haven't done any "official application" because of my felt severity yet. > For a long term project the FreeBSD foundation was the better way, I > think. > But I hoped somebody would be able to fix it before 8.0-RELEASE, which > is not too far away. > I just got one more reply from another fellow willing to donate for > fixing ODD support, but no reply from any coder yet... > > All in all, not much response. > It seems the ones using ODDs are considering the problems as quiet > severe, but it also seems there are not many fellows missing working ODD > support. > Is the media itself really outdated? I haven't done any blu-ray > experiments under FreeBSD yet, but I can't imagine things are working > better with that media. > > So for now the pot is about 500 bucks. > Anyone to pick up? > > Regards, > > -Harry > > > > Hello. I think you should be more specific about your problems, for most people present ODD support is working. For the record, I just rebooted with audio cd inserted, without problem. (some cam errors, I'm using ahci) http://pastebin.com/m1359b95d and ripped track from that cd. http://pastebin.com/m187d2d17 -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/Funding-ODD-support-tp25314648p25341094.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 08:33:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91D071065672 for ; Tue, 8 Sep 2009 08:33:36 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from kennaway-macbookpro.config (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F1B7D8FC18; Tue, 8 Sep 2009 08:33:35 +0000 (UTC) Message-ID: <4AA616E1.1020503@FreeBSD.org> Date: Tue, 08 Sep 2009 09:33:37 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Harald Schmalzbauer References: <4AA0F8FE.6050908@omnilan.de> <3a142e750909040834g2465d932t4b65ff02727761bf@mail.gmail.com> <4AA15F66.9070907@omnilan.de> In-Reply-To: <4AA15F66.9070907@omnilan.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: xorg running > 48h starts consuming CPU cycles with BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 08:33:36 -0000 Harald Schmalzbauer wrote: > Paul B. Mahol schrieb am 04.09.2009 17:34 (localtime): >> On 9/4/09, Harald Schmalzbauer wrote: >>> Hello, >>> >>> I have one problem with xorg running on BETA3. >>> Repeatably, after more than 48hour uptime, my workstation showes >>> increased load. The longer the uptime, the more cpu cycles xorg >>> consumes. >>> It's absolutely application independent. After 3 or 4 days, almost one >>> complete CPU is occupied by xorg, but I have no idea what xorg is doing. >>> Is there any way to "look inside" xorg to see where the CPU cycles >>> vanish? Apart from ktrace/gdb/etc, dunno. >>> With uptimes shorter than 2 days I can't see xorg consuming any >>> remarkable CPU cycles. >>> Xorg is 1.6.1, compiled on BETA3: >>> 1157 root 1 53 0 828M 234M select 1 40:04 15.38% Xorg >> >> What video driver Xorg is using? > > nvidia (not nv) Does it happen with nv? If not, it's likely to be a driver issue. Kris From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 09:11:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BEAC106566C; Tue, 8 Sep 2009 09:11:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 9A7AE8FC1B; Tue, 8 Sep 2009 09:11:19 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n889BEux080674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Sep 2009 12:11:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n889BEUT065771; Tue, 8 Sep 2009 12:11:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n889BE8V065770; Tue, 8 Sep 2009 12:11:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Sep 2009 12:11:14 +0300 From: Kostik Belousov To: pluknet Message-ID: <20090908091114.GH47688@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BqNvIJgrK1/MQy2W" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-emulation@freebsd.org, FreeBSD Current Subject: Re: acquiring duplicate lock of same type: "ftlk" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 09:11:20 -0000 --BqNvIJgrK1/MQy2W Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote: > 2009/8/27 pluknet : > > Hi. > > > > Got it on FreeBSD 9.0-CURRENT while been running in Xorg, don't know > > where exactly. > > > > Acquiring duplicate lock of same type: "ftlk" > > =9A1st ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex= .c:177 > > =9A2nd ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex= .c:203 > > KDB: stack backtrace: > > db_trace_self_wrapper(c07fd8ea,ea393b58,c060a145,c05fac1b,c08007b2,...) > > at db_trace_self_wrapper+0x26 > > kdb_backtrace(c05fac1b,c08007b2,c0b49757,c58ead20,ea393bb4,...) at > > kdb_backtrace+0x29 > > _witness_debugger(c08007b2,c0b49793,c0b49757,cb,0,...) at _witness_debu= gger+0x25 > > witness_checkorder(c9bba780,9,c0b49757,cb,0,...) at witness_checkorder+= 0x469 > > _sx_xlock(c9bba780,0,c0b49757,cb,0,...) at _sx_xlock+0x85 > > futex_get0(c0609f8c,c09cc7a8,c9ac7764,c09cc7a8,c084df3c,...) at futex_g= et0+0x116 > > linux_sys_futex(c9ac76c0,ea393cf8,ea393d18,ea393d1c,c0b4cf40,...) at > > linux_sys_futex+0x6f > > syscall(ea393d38) at syscall+0x2b4 > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > --- syscall (240, Linux ELF, linux_sys_futex), eip =3D 0x28799533, esp = =3D > > 0xbfbfc0cc, ebp =3D 0x4000001 --- > > > > =46rom what dchagin@ told me, the LOR is unavoidable since he has to acquire two sx locks of the same name. On the other hand, second sx lock is not visible to any thread except the current one, so the LOR should be innocent. >=20 > This time seeing this LOR again but with another one just before. > lock order reversal: > 1st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:497 > 2nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292 > KDB: stack backtrace: > db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at > kdb_backtrace+0x29 > _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at > _witness_debugger+0x25 > witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at witness_checkorder+0= x839 > _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85 > pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f > pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a > pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at pfs_looku= p+0x3dd > VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...) > at VOP_CACHEDLOOKUP_APV+0xc5 > vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at > vfs_cache_lookup+0xd6 > VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at > VOP_LOOKUP_APV+0xe5 > lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b > namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f > kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at kern_al= ternate > _path+0x1cd > linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at > linux_emul_convpath+0x3c > linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at linux_ope= n+0x41 > syscall(e8214d38) at syscall+0x2b4 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (5, Linux ELF, linux_open), eip =3D 0x2889115e, esp =3D > 0xbfbfbd1c, ebp =3D 0xbfbfbd6c --- > acquiring duplicate lock of same type: "ftlk" > [...] >=20 > I'm running head from 08/26. > There were recent changes in pseudofs. Could it be fixed? > Looks like it's connected to running firefox3 with linprocfs (for adobe f= lash). The second LOR actually exposes the right order. It would be interesting to look up the point where the other order is established. --BqNvIJgrK1/MQy2W Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkqmH7IACgkQC3+MBN1Mb4hWsgCg9r/UK/ONeVF1VI0tse7z9g++ ZhkAn27cjfb6rsT7bOd5D+M2laBw4Sjg =l0qZ -----END PGP SIGNATURE----- --BqNvIJgrK1/MQy2W-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 09:13:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E59F1065672 for ; Tue, 8 Sep 2009 09:13:04 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id 4885E8FC0C for ; Tue, 8 Sep 2009 09:13:03 +0000 (UTC) Received: by fxm6 with SMTP id 6so2355541fxm.43 for ; Tue, 08 Sep 2009 02:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=51zFWpfFNkpzEpIoNMlF1ZWhoGOGBVQcNnW6vJXp1nY=; b=L/PmOp3VmL98uMBISFAFBKJ40n72sAOGSC9uTvtxpY4NNQqGYCo1chN8g5m7MHScAq yv19IvCHVk9hi1VvvpWiZVwTGmUHWDWGvEVthCR5jL0e4INSZAP306DoDrXl6dCPbHqX EWFPwaIi9F0eu42OGdaR1XyD2NTSEGc0QHeLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=qTV+o/H3iq83aKvbpVyUzh8Q/CL9b+KvNuXJOI4AsWvlbxDimYIGk3hy7CPpP5DTkw VmGo2EGMH9N9gaDop7Sl25hwAsBQbbgaBXYNb4D6pI17FgXKzy6bEze2S8ZGrm8l+jOx iaDkKbJN2V36B9BmFj3RtSS3OmWWlz8sa/o0s= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.29.193 with SMTP id r1mr5918301fac.29.1252401182424; Tue, 08 Sep 2009 02:13:02 -0700 (PDT) In-Reply-To: <20090908091114.GH47688@deviant.kiev.zoral.com.ua> References: <20090908091114.GH47688@deviant.kiev.zoral.com.ua> Date: Tue, 8 Sep 2009 11:13:02 +0200 X-Google-Sender-Auth: 2aee096baf16c628 Message-ID: <3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com> From: Attilio Rao To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-emulation@freebsd.org, pluknet , FreeBSD Current Subject: Re: acquiring duplicate lock of same type: "ftlk" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 09:13:04 -0000 2009/9/8 Kostik Belousov : > On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote: >> 2009/8/27 pluknet : >> > Hi. >> > >> > Got it on FreeBSD 9.0-CURRENT while been running in Xorg, don't know >> > where exactly. >> > >> > Acquiring duplicate lock of same type: "ftlk" >> > 1st ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:177 >> > 2nd ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:203 >> > KDB: stack backtrace: >> > db_trace_self_wrapper(c07fd8ea,ea393b58,c060a145,c05fac1b,c08007b2,...) >> > at db_trace_self_wrapper+0x26 >> > kdb_backtrace(c05fac1b,c08007b2,c0b49757,c58ead20,ea393bb4,...) at >> > kdb_backtrace+0x29 >> > _witness_debugger(c08007b2,c0b49793,c0b49757,cb,0,...) at _witness_debugger+0x25 >> > witness_checkorder(c9bba780,9,c0b49757,cb,0,...) at witness_checkorder+0x469 >> > _sx_xlock(c9bba780,0,c0b49757,cb,0,...) at _sx_xlock+0x85 >> > futex_get0(c0609f8c,c09cc7a8,c9ac7764,c09cc7a8,c084df3c,...) at futex_get0+0x116 >> > linux_sys_futex(c9ac76c0,ea393cf8,ea393d18,ea393d1c,c0b4cf40,...) at >> > linux_sys_futex+0x6f >> > syscall(ea393d38) at syscall+0x2b4 >> > Xint0x80_syscall() at Xint0x80_syscall+0x20 >> > --- syscall (240, Linux ELF, linux_sys_futex), eip = 0x28799533, esp = >> > 0xbfbfc0cc, ebp = 0x4000001 --- >> > >> > > From what dchagin@ told me, the LOR is unavoidable since he has to > acquire two sx locks of the same name. On the other hand, second sx lock > is not visible to any thread except the current one, so the LOR should > be innocent. > >> >> This time seeing this LOR again but with another one just before. >> lock order reversal: >> 1st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:497 >> 2nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292 >> KDB: stack backtrace: >> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...) >> at db_trace_self_wrapper+0x26 >> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at >> kdb_backtrace+0x29 >> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at >> _witness_debugger+0x25 >> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at witness_checkorder+0x839 >> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85 >> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f >> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a >> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at pfs_lookup+0x3dd >> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...) >> at VOP_CACHEDLOOKUP_APV+0xc5 >> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at >> vfs_cache_lookup+0xd6 >> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at >> VOP_LOOKUP_APV+0xe5 >> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b >> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f >> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at kern_alternate >> _path+0x1cd >> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at >> linux_emul_convpath+0x3c >> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at linux_open+0x41 >> syscall(e8214d38) at syscall+0x2b4 >> Xint0x80_syscall() at Xint0x80_syscall+0x20 >> --- syscall (5, Linux ELF, linux_open), eip = 0x2889115e, esp = >> 0xbfbfbd1c, ebp = 0xbfbfbd6c --- >> acquiring duplicate lock of same type: "ftlk" >> [...] >> >> I'm running head from 08/26. >> There were recent changes in pseudofs. Could it be fixed? >> Looks like it's connected to running firefox3 with linprocfs (for adobe flash). > > The second LOR actually exposes the right order. It would be interesting > to look up the point where the other order is established. You would manually patch the witness static table with this order and the opposite will show, when happening. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 11:02:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 645B81065676 for ; Tue, 8 Sep 2009 11:02:50 +0000 (UTC) (envelope-from sweetnavelorange@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id E92C18FC15 for ; Tue, 8 Sep 2009 11:02:49 +0000 (UTC) Received: by ewy4 with SMTP id 4so1536727ewy.36 for ; Tue, 08 Sep 2009 04:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=3PsfBXvUYmorhakpEpi7ZMkz7xfwaIYfqfurY9ymFGk=; b=qUu+I8hPxCmkqxi+6Fdcz+QFRVkDXmEtiSu8+NwBhzhe1vq9ueg1CEaloUqc2hGMfb mPD8yHfqv5iB5CImjQTqPPoNwfYjwqh7Hujft56KFPkYMLpkZiNv3LVv2erFZUGEHudP OGtVqQUiPBM5M9uZWvqk4ezVgPI5SggzVkP9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NiQAAKMtE1g2lUWSY6ld/fGFcSsqSuvAi/wq+XsQ74A+vhkhg+vo51LY+TEToX6Tvx JJtxB9SmGDcNa2RLPo+4X2dnRK3ydJTk0AmD2yBrrNlHUGBSepSzojUWmq6h9qBrrt0Z fOTQmU5iv3j3FZmgMzCoGpdSjhVHwU7swESGo= MIME-Version: 1.0 Received: by 10.216.24.195 with SMTP id x45mr1609924wex.82.1252407768955; Tue, 08 Sep 2009 04:02:48 -0700 (PDT) Date: Tue, 8 Sep 2009 23:02:48 +1200 Message-ID: From: James Butler To: FreeBSD CURRENT Mailing List Content-Type: text/plain; charset=UTF-8 Subject: Can't boot 8.0-BETA4 from USB stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 11:02:50 -0000 Greetings all, I have an amd64 system (Asus A8V-MX) which boots 7.2 from a USB flash drive. Trying an 8-STABLE kernel from Saturday (identifies as 8.0-BETA4), the system can't boot - here is the last bit of the kernel messages (typed, with comments): [witness performance blah blah blah] root mount waiting for: usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered root mount waiting for: usbus2 uhub2: 2 ports with 2 removable, self powered root mount waiting for: usbus2 ugen2.2: at usbus2 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0000 root mount waiting for: usbus2 umass0:0:0:-1: Attached to scbus0 Trying to mount root from ufs:/dev/da0s1a ROOT MOUNT ERROR: If you have invalid mount options, reboot, and da0 at umass-sim0 bus 0 target 0 lun 0 <---- This is suspicious da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3875MB (7936000 512 byte sectors: 255H 63S/T 493C) first try the following from <---- The rest of the message that was cut off above the loader prompt: etc. etc. until the mountroot> prompt, and after that even specifying the device doesn't work (and ? doesn't list it). It seems to my non-hacker eyes that the device is not attaching until after it should be. Any help would be appreciated, and I can provide further information as needed. Thanks, James Butler From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 11:50:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C4321065672 for ; Tue, 8 Sep 2009 11:50:11 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 7B72B8FC1B for ; Tue, 8 Sep 2009 11:50:10 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Na0XZysqMGgA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=l2kFXysqq0mMDRsvP1MA:9 a=8vU5hjXLtrs5ixoLFDoA:7 a=OwEQH9ZdZysM0Fzp9dSHwUT0MgAA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1302160460; Tue, 08 Sep 2009 13:50:08 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 8 Sep 2009 13:50:32 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: In-Reply-To: X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909081350.34461.hselasky@c2i.net> Cc: James Butler Subject: Re: Can't boot 8.0-BETA4 from USB stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 11:50:11 -0000 On Tuesday 08 September 2009 13:02:48 James Butler wrote: > Greetings all, > > I have an amd64 system (Asus A8V-MX) which boots 7.2 from a USB flash > drive. Trying an 8-STABLE kernel from Saturday (identifies as > 8.0-BETA4), the system can't boot - here is the last bit of the kernel > messages (typed, with comments): > > [witness performance blah blah blah] > root mount waiting for: usbus2 usbus1 usbus0 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > root mount waiting for: usbus2 > uhub2: 2 ports with 2 removable, self powered > root mount waiting for: usbus2 > ugen2.2: at usbus2 > umass0: on usbus2 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > root mount waiting for: usbus2 > umass0:0:0:-1: Attached to scbus0 > Trying to mount root from ufs:/dev/da0s1a > ROOT MOUNT ERROR: > If you have invalid mount options, reboot, and da0 at umass-sim0 bus 0 > target 0 lun 0 <---- This is suspicious > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 3875MB (7936000 512 byte sectors: 255H 63S/T 493C) > first try the following from <---- The rest of the message that was > cut off above > the loader prompt: > > etc. etc. until the mountroot> prompt, and after that even specifying > the device doesn't work (and ? doesn't list it). It seems to my > non-hacker eyes that the device is not attaching until after it should > be. > > Any help would be appreciated, and I can provide further information as > needed. Hi, It looks like your device is detected too late. Have you tried another USB port? Or plugging in another dummy USB device? --HPS From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 11:55:05 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2AC2106566C for ; Tue, 8 Sep 2009 11:55:05 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id 22EAE8FC1E for ; Tue, 8 Sep 2009 11:55:04 +0000 (UTC) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id n88Bsxct030749 for ; Tue, 8 Sep 2009 13:55:00 +0200 (CEST) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.14.2/Submit) id n88Bsx6n030748 for current@freebsd.org; Tue, 8 Sep 2009 13:54:59 +0200 (CEST) (envelope-from mail25@bzerk.org) Date: Tue, 8 Sep 2009 13:54:59 +0200 From: Ruben de Groot To: current@freebsd.org Message-ID: <20090908115459.GA30570@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.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Tue, 08 Sep 2009 13:55:03 +0200 (CEST) Cc: Subject: 8.0-BETA2 on soekris discarding packets? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 11:55:05 -0000 Hi, I'm trying 8.0-BETA2 on a 4511 soekris board, but found a problem. Outgoing networking is fine, but it looks like incoming connections are silently discarded. No firewall is configured. Here's a tcpdump of normal outgoing DNS traffic (IP address of the soekris is 192.168.179.15): listening on sis0, link-type EN10MB (Ethernet), capture size 96 bytes 10:33:50.053875 IP 192.168.179.15.23093 > ei.lan.domain: 45893+ PTR? 255.179.168.192.in-addr.arpa. (46) 10:33:50.055038 IP ei.lan.domain > 192.168.179.15.23093: 45893 NXDomain* 0/1/0 (109) 10:33:50.066917 IP 192.168.179.15.13890 > ei.lan.domain: 45894+ PTR? 9.179.168.192.in-addr.arpa. (44) 10:33:50.067834 IP ei.lan.domain > 192.168.179.15.13890: 45894* 1/1/1 (113) And here's a dump of an incoming ssh connection: listening on sis0, link-type EN10MB (Ethernet), capture size 96 bytes 10:26:40.176756 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 1961056657 ecr 0,sackOK,eol], length 0 10:26:43.175176 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 1961059657 ecr 0,sackOK,eol], length 0 10:26:46.374688 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 1961062857 ecr 0,sackOK,eol], length 0 10:26:49.574197 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,sackOK,eol], length 0 10:26:52.773759 IP ei.lan.55742 > 192.168.179.15.ssh: Flags [S], seq 1547228218, win 65535, options [mss 1460,sackOK,eol], length 0 Et cetera. No replies. This goes for all tcp ports, but ping works. nmap from another host says: # nmap soekris Starting Nmap 4.85BETA7 ( http://nmap.org ) at 2009-09-08 13:31 CEST All 1000 scanned ports on 192.168.179.15 are filtered MAC Address: 00:00:24:CB:93:28 (Connect AS) Nmap done: 1 IP address (1 host up) scanned in 21.67 seconds Anyone else seeing this? Ruben kernel config is below. include GENERIC cpu I486_CPU cpu I586_CPU ident SOEKRIS machine i386 options CPU_ELAN options CPU_SOEKRIS options HZ=150 #options CPU_ELAN_XTAL options CPU_GEODE From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 12:03:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A37351065670; Tue, 8 Sep 2009 12:03:51 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id D26A18FC13; Tue, 8 Sep 2009 12:03:50 +0000 (UTC) Received: from vhoffman.lon.namesco.net (115.73-246-213.ippool.namesco.net [213.246.73.115]) (authenticated bits=0) by unsane.co.uk (8.14.3/8.14.3) with ESMTP id n88C6aPA002716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Sep 2009 13:06:37 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4AA64808.4030105@unsane.co.uk> Date: Tue, 08 Sep 2009 13:03:20 +0100 From: Vincent Hoffman User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Danny Braniss References: <20090611194557.GC98175@bsdcrew.de> <991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com> <20090906162544.GA39448@bsdcrew.de> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, Odhiambo Washington , freebsd-current@freebsd.org, freebsd-emulation@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 12:03:51 -0000 Danny Braniss wrote: > [...] > >>>> ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no >>>> longer available, there is a >>>> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2 >>>> then again in ports/emulatores/virtualbox the version is 3.0.51r22226, >>>> >>>> can someone please explain? >>>> > > hi, the above was my question, which was totally ignored, not nice. > I will try and refrase it: > the call for testing is for a version (2.2.51r20457) which is not available, while > the ports is 3.0.51r22226, so while I managed to compile it, it complains that COM > is not running, all this under 8BETA-3, both under 32 and 64 bit. > thnaks, > danny > > The call for testing went out on 11th june (http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008061.html) I can only assume it was considered tested and working as the port was committed on 15th june (http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/virtualbox/Makefile?rev=1.1;content-type=text%2Fplain) Since then there have been 4 updates to the port. The last of which updated it to 3.0.51r22226 on august 14th. I would say the call for testing is no longer valid, please use the version in ports. Vince > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 12:41:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74A791065672 for ; Tue, 8 Sep 2009 12:41:35 +0000 (UTC) (envelope-from oliver@namp.de) Received: from grisu.qmail-ldap.de (grisu.qmail-ldap.de [78.46.218.233]) by mx1.freebsd.org (Postfix) with ESMTP id 652978FC0A for ; Tue, 8 Sep 2009 12:41:33 +0000 (UTC) Received: (qmail 91427 invoked from network); 8 Sep 2009 12:45:27 -0000 Received: from unknown (HELO mail.kuehlbox.de) (oliver@namp.de@[78.46.218.233]) (envelope-sender ) by grisu.qmail-ldap.de (qmail-ldap-1.03) with SMTP for ; 8 Sep 2009 12:45:24 -0000 Received: from: grisu.qmail-ldap.de ([78.46.218.233]) by HSF smtp proxy MIME-Version: 1.0 X-Priority: Normal X-Mailer: AtMail 1.03 Message-ID: <24905.1252413921@namp.de> To: X-Origin: 195.180.14.14 X-Atmail-Account: oliver@namp.de Date: Tue, 8 Sep 2009 14:45:21 +0200 From: Oliver Fakler Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: boot from raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: oliver@namp.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 12:41:35 -0000 On Mon 07/09/09 20:22 , Paul Wootton wrote:Oliver Fakler wrote: > On Mon 07/09/09 13:40 , Bernhard Schmidt wrote: > Am 07.09.2009 um 11:13 schrieb Oliver Fakler: > > > > BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; } > > > > On Mon 07/09/09 10:07 , Bernhard Schmidt =20 > > wrote: > > > > > > Am 06.09.2009 um 21:45 schrieb Oliver Fakler: > > > > > > > > > > > Hi all, > > > > > > i installed a 8.0 beta 3 amd64 based testsystem. > > > > > > i tried with a root on a raidz, but i have a problem after the > first > > > reboot, there is a error message: > > > > > > can't load kernel > > > I found something that boot root from raidz is not supported, > but > > > maybe there is a solution?? > > > Hope some can help me > > > > > > There are patches from Doug Rabson which add support for booting > from > > raidz/raidz2. > > > > > http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html [1]" target=3D"_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-Decemb= er/005498.html > [2]" > target=3D"_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-Decemb= er/005498.html [2]" target=3D"_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-Decemb= er/005498.html > > > " > target=3D"_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-Decemb= er/005498.html [3]" target=3D"_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-Decemb= er/005498.html > [3]" > target=3D"_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-Decemb= er/005498.html [4]" target=3D"_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-Decemb= er/005498.html > Seems that patch made it already into the tree (r192194). > > > > > > I tried it, but after a make obj && make depend the make failed > with =20 > > different errors like undeclared and has no member named. > > > > I used patch raidzboot-14052009.diff started patching from > /usr/src/=20 > > sys/ , i'm not sure if this was the right way. > > > > I'm also not sure if the way of installation was the right one, =20 > > here's the way i go: > > > > > > gpart create -s GPT da0 > > gpart add -b 34 -s 128 -t freebsd-boot da0 > > gpart add -b 162 -s 5242880 -t freebsd-swap da0 > > gpart add -b 5243042 -s 11534141 -t freebsd-zfs da0 > > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 > da0 > > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 > da1 > > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 > da2 > > > Can you try zfsboot instead of gptzfsboot? > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.htm= l [5]" target=3D"_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/20= 09-05/msg00689.html > [4]" > target=3D"_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/20= 09-05/msg00689.html [6]" target=3D"_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/20= 09-05/msg00689.html > > at the end of the mail. > > > > > > kldload /mnt2/boot/kernel/opensolaris.ko > > kldload /mnt2/boot/kernel/zfs.ko > > > > zpool create tank raidz da0p3 da1p1 d2p1 > > > > zfs create tank/tmp > > zfs create tank/usr > > zfs create tank/var > > > > cd /dist/8.0-BETA3/base > > export DESTDIR=3D/tank > > ./install.sh > > You are about to extract the base distribution into /tank - are > you =20 > > SURE > > you want to do this over your installed system (y/n)? y > > cd ../kernels > > ./install.sh generic > > cd /tank/boot > > cp -Rp GENERIC/* kernel/ > > > > cd /dist/8.0-BETA3/src > > ./install.sh all > > Extracting sources into /usr/src... > > Extracting source component: base > > Extracting source component: bin > > Extracting source component: cddl > > Extracting source component: contrib > > Extracting source component: crypto > > Extracting source component: etc > > Extracting source component: games > > Extracting source component: gnu > > Extracting source component: include > > Extracting source component: krb5 > > Extracting source component: lib > > Extracting source component: libexec > > Extracting source component: release > > Extracting source component: rescue > > Extracting source component: sbin > > Extracting source component: secure > > Extracting source component: share > > Extracting source component: sys > > Extracting source component: tools > > Extracting source component: ubin > > Extracting source component: usbin > > Done extracting sources. > > Done extracting sources. > > cd ../manpages > > ./install.sh > > > > echo 'zfs_enable=3D"YES"' > /tank/etc/rc.conf > > echo 'LOADER_ZFS_SUPPORT=3D"YES"' > /tank/etc/src.conf > > echo 'zfs_load=3D"YES"' > /tank/boot/loader.conf > > echo 'vfs.root.mountfrom=3D"zfs:tank"' >> /tank/boot/loader.conf > > echo ´/dev/da0p2 none swap sw 0 0´>> /tank/etc/fstab > > > > mkdir /boot/zfs > > zpool export tank && zpool import tank > > cp /boot/zfs/zpool.cache /tank/boot/zfs/ > > > > chroot /tank > > mount -t devfs devfs /dev > > unset DESTDIR > > cd /usr/src/sys/boot/ > > make obj > > make depend > > make > > cd i386/loader > > make install > > umount /dev > > touch /etc/fstab > > exit > > > > export LD_LIBRARY_PATH=3D/mnt2/lib > > zfs set mountpoint=3Dlegacy tank > > zfs set mountpoint=3D/tmp tank/tmp > > zfs set mountpoint=3D/var tank/var > > zfs set mountpoint=3D/usr tank/usr > > zpool set bootfs=3Dtank tank > > > Seems correct at first glance. > -- > Bernhard > testet with zfsboot instead of gptzfsboot but it was not successfull > :-( > > Links: > ------ > [2] http://mail.kuehlbox.de/parse.php%3Fredirect%3D%26lt%3Ba [7]" target=3D"_blank">http://mail.kuehlbox.de/parse.php?redirect=3D [3] http://mail.kuehlbox.de/parse.php%3Fredirect%3D%26lt%3Ba [8]" target=3D"_blank">http://mail.kuehlbox.de/parse.php?redirect=3D [4] http://mail.kuehlbox.de/parse.php%3Fredirect%3D%26lt%3Ba [9]" target=3D"_blank">http://mail.kuehlbox.de/parse.php?redirect=3D _______________________________________________ > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current [11]" target=3D"_blank">http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to " I have a fully running GPT ZFS RaidZ setup using what was at the time 8-HEAD I cant remember the exact steps I took, but one thing I have different=20 is I have a root filesystem within my zpool [ /usr/home/paul]$ gpart show =3D> 34 976773101 ada1 GPT (466G) 34 256 1 freebsd-boot (128K) 290 8388608 2 freebsd-swap (4.0G) 8388898 147912557 3 freebsd-zfs (71G) 156301455 820471680 - free - (391G) =3D> 34 488394988 ada2 GPT (233G) 34 256 1 freebsd-boot (128K) 290 8388608 2 freebsd-swap (4.0G) 8388898 147912557 3 freebsd-zfs (71G) 156301455 332093567 - free - (158G) =3D> 34 156301421 ada3 GPT (75G) 34 256 1 freebsd-boot (128K) 290 8388608 2 freebsd-swap (4.0G) 8388898 147912557 3 freebsd-zfs (71G) [ /usr/home/paul]$ zpool status pool: zboot state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zboot ONLINE 0 0 0 ada1p3 ONLINE 0 0 0 ada2p3 ONLINE 0 0 0 ada3p3 ONLINE 0 0 0 errors: No known data errors [ /usr/home/paul]$ zfs list NAME USED AVAIL REFER MOUNTPOINT zboot 33.5G 175G 18K none zboot/root 12.4G 175G 12.2G none zboot/tmp 82.9M 175G 82.6M none zboot/usr 20.8G 175G 16.5G none zboot/var 216M 175G 123M none Im also using fstabs to mount my ZFS filesystems [ /usr/home/paul]$ more /etc/fstab # Device Mountpoint FStype Options Dump =20 Pass# zboot/root / zfs rw 0 =20 0 zboot/usr /usr zfs rw 0 =20 0 zboot/var /var zfs rw 0 =20 0 zboot/tmp /tmp zfs rw,noatime 0 =20 0 proc /proc procfs rw 0 =20 0 I remember speak to someone a while back, and I *think* we came to the=20 conclusion that using the zpool as your root will not work correctly and=20 you should really create a root filesystem inside the zpool Lets me know how this works out for you Paul ---------------------------------------------------------------------------= -------- Fletcher Moorland Limited is a company registered in England and Wales.=20 Registration number: 2984467.=20 Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG.=20 VAT Registration number: 478730606=20 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk [17]" target=3D"_blank">http://www.fletchermoorland.co.uk=20 _______________________________________________ mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current [19]" target=3D"_blank">http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "" your pool is just a stripe, no raidz i testet it with striping, and it was successfull, but i need a raidz there are some new errors on Beta4 can'tfind root filesystem maybe you're right with your idea of an extra root folder, but i think if he can't find root filesystem, he also can't read fstab. maybe more ideas? :-) cheers=20 Oliver Links: ------ [1] http://mail.kuehlbox.de/parse.php?redirect=3D Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70C411065679 for ; Tue, 8 Sep 2009 13:40:18 +0000 (UTC) (envelope-from boogie@lazybytes.org) Received: from mail.lazybytes.org (odin.rinet.ru [195.54.209.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA0E8FC20 for ; Tue, 8 Sep 2009 13:40:18 +0000 (UTC) Received: from [192.168.251.193] (nat-addr.off.rinet.ru [195.54.192.77]) by mail.lazybytes.org (Postfix) with ESMTPSA id 8852C14035C9 for ; Tue, 8 Sep 2009 17:21:15 +0400 (MSD) Message-ID: <4AA65ABE.4000207@lazybytes.org> Date: Tue, 08 Sep 2009 17:23:10 +0400 From: Sergey Vinogradov User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.96.0 OpenPGP: url=http://lazybytes.org/people/boogie/pubkey.gpg Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig262262376F52F557BE95DEC3" Subject: ath(4) Atheros AR9285 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 13:40:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig262262376F52F557BE95DEC3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Just wanted to know, if there will be any Atheros AR9285 support in ath(4) driver in nearest future? I've got my ASUS Eee 1005HA with one of these wireless adapters, and it doesn't seem to be working. --=20 wbr, Boo --------------enig262262376F52F557BE95DEC3 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.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqmWsQACgkQCt8hfbw1GpYMcwCeOnDR9hArxwjrnJAbqOT4B68u UNEAnip8QkvXIYxcTWL6wDajeadzXHtw =mgo0 -----END PGP SIGNATURE----- --------------enig262262376F52F557BE95DEC3-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 05:43:16 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83ADA106566B for ; Tue, 8 Sep 2009 05:43:16 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (hergotha.csail.mit.edu [66.92.79.170]) by mx1.freebsd.org (Postfix) with ESMTP id 269668FC0C for ; Tue, 8 Sep 2009 05:43:15 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.2/8.14.2) with ESMTP id n885GbrJ065214; Tue, 8 Sep 2009 01:16:37 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.2/8.13.8/Submit) id n885Gba0065213; Tue, 8 Sep 2009 01:16:37 -0400 (EDT) (envelope-from wollman) Date: Tue, 8 Sep 2009 01:16:37 -0400 (EDT) From: Garrett Wollman Message-Id: <200909080516.n885Gba0065213@hergotha.csail.mit.edu> To: rysto32@gmail.com X-Newsgroups: mit.lcs.mail.freebsd-current In-Reply-To: References: <4A93AFF9.1060201@web.de> <52d4a3890908250321u746e5757u136030bcbc19208d@mail.gmail.com> <4A93BF0C.8040601@web.de> <20090826221001.GA1070@triton8.kn-bremen.de> <4A96C8D9.6070804@web.de> <20090829211848.GA59305@triton8.kn-bremen.de> <4A9B800F.1040209@web.de> <20090831212723.GA32448@triton8.kn-bremen.de> <20090901201248.GA60123@triton8.kn-bremen.de> <20090907205955.GA91866@triton8.kn-bremen.de> Organization: None X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (hergotha.csail.mit.edu [127.0.0.1]); Tue, 08 Sep 2009 01:16:37 -0400 (EDT) X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hergotha.csail.mit.edu X-Mailman-Approved-At: Tue, 08 Sep 2009 13:43:03 +0000 Cc: current@freebsd.org Subject: Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 05:43:16 -0000 In article , Ryan Stone wrote: >I'm not entirely clear on why it's done this way, but the timer is run at >twice hz for statistics-gathering purposes*. CPU usage statistics gathering >is driven off of the timer interrupt. Running the timer at twice hz may be >an attempt to eliminate clock-aliasing problems; if so, it's a poor way of >doing so. The statistics timer is supposed to be jittered with an exponential distribution, so that applications cannot avoid being charged for CPU time by running synchronously (and out-of-phase) with the timer. This was historically broken on PC hardware, and is probably still broken on SMP PC hardware, because there are insufficient programmable timer interrupts. Ideally, you'd like a distinct statistics timers on each CPU, with a sufficiently (quickly) programmable period. -GAWollman From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 05:50:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ED00106568F for ; Tue, 8 Sep 2009 05:50:11 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id 19A8B8FC12 for ; Tue, 8 Sep 2009 05:50:10 +0000 (UTC) Received: by fxm6 with SMTP id 6so2268965fxm.43 for ; Mon, 07 Sep 2009 22:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ns7wnowQl6zyQjm3WoBzRzQ6FzsOIKc/BEG2iaLuRZk=; b=CBh3S8xv/tO0ZU1pVmbMf+fruLLUwqb1jDwHYdHrLGs7HXoig5J/MKhwCJnRi1sBgU isGj5HqktuHIjeRC/awtdgQmA6OwSbgBPfJp8rgv248Empe3bV9CZRSiiqcLn2apwQ2/ BBCC1cbl6tLwCgPLbbmItN/QMBI5z9RybrBdI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HdiIR/WT6UuRzMVczFO+aMje/L3N+Xu4sWgIlyk8sDRmA9PuC/9lpQkMeUeiJoD8Dz Wwbd8c6HzftPtZnsvlYjmqTnDPBd9wqDevnPg/az47TNB/iFZG0QT/1Lt9KJdEjl12qA 4mo93IhOGN/60SqH593oD71Hlg1Hxhzg5dIm8= MIME-Version: 1.0 Received: by 10.204.154.86 with SMTP id n22mr2330779bkw.110.1252389009495; Mon, 07 Sep 2009 22:50:09 -0700 (PDT) Date: Tue, 8 Sep 2009 01:50:09 -0400 Message-ID: From: grarpamp To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 08 Sep 2009 14:05:55 +0000 Subject: LOR RELENG_8 fd/zfs (close) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 05:50:11 -0000 Didn't see the 1st/2nd "a (b) @ src_file" on the big page of LOR's. Put here for anyone interested. lock order reversal: 1st 0xc8f1d42c filedesc structure (filedesc structure) @ /.../src/sys/kern/kern_descrip.c:1088 2nd 0xc4af38b8 ufs (ufs) @ /.../src/sys/kern/vfs_subr.c:4091 KDB: stack backtrace: db_trace_self_wrapper(c0c75d72,e6f4ca2c,c08c1365,c08b20eb,c0c78d15,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08b20eb,c0c78d15,c452c2a0,c452f638,e6f4ca88,...) at kdb_backtrace+0x29 _witness_debugger(c0c78d15,c4af38b8,c0c6b44b,c452f638,c0c801f7,...) at _witness_debugger+0x25 witness_checkorder(c4af38b8,9,c0c801f7,ffb,c4af38d4,...) at witness_checkorder+0x839 __lockmgr_args(c4af38b8,80400,c4af38d4,0,0,...) at __lockmgr_args+0x7a7 ffs_lock(e6f4cb98,4,0,80400,c4af3860,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0d7a580,e6f4cb98,c0c6d72e,c0d92fe0,c4af3860,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c4af3860,80400,c0c801f7,ffb,e6f4cbf4,...) at _vn_lock+0x5e vfs_knllock(c4af3860,0,c0c6d72e,696,c4c22e9c,...) at vfs_knllock+0x29 knlist_remove_kq(0,e6f4cc14,c090c9a9,c7fcaea4,c4c22e9c,...) at knlist_remove_kq+0x85 knlist_remove(c7fcaea4,c4c22e9c,0,e6f4cc40,c084fe85,...) at knlist_remove+0x1b filt_vfsdetach(c4c22e9c,0,c0c6d72e,777,9,...) at filt_vfsdetach+0x39 knote_fdclose(c632d6c0,9,c0c6d256,440,c8f1d42c,...) at knote_fdclose+0xf5 kern_close(c632d6c0,9,e6f4cd2c,c0bb0a53,c632d6c0,...) at kern_close+0xd2 close(c632d6c0,e6f4ccf8,4,c0c795e6,c0d58d48,...) at close+0x1a syscall(e6f4cd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x2837b2a3, esp = 0xbfbfe45c, ebp = 0xbfbfe478 --- lock order reversal: 1st 0xc8f1d42c filedesc structure (filedesc structure) @ /.../src/sys/kern/kern_descrip.c:1088 2nd 0xc8c7e37c zfs (zfs) @ /.../src/sys/kern/vfs_subr.c:4091 KDB: stack backtrace: db_trace_self_wrapper(c0c75d72,e6f4ca34,c08c1365,c08b20eb,c0c78d15,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08b20eb,c0c78d15,c452c2a0,c452fd20,e6f4ca90,...) at kdb_backtrace+0x29 _witness_debugger(c0c78d15,c8c7e37c,c1218129,c452fd20,c0c801f7,...) at _witness_debugger+0x25 witness_checkorder(c8c7e37c,9,c0c801f7,ffb,c8c7e398,...) at witness_checkorder+0x839 __lockmgr_args(c8c7e37c,80400,c8c7e398,0,0,...) at __lockmgr_args+0x7a7 vop_stdlock(e6f4cb98,4,0,80400,c8c7e324,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c121d560,e6f4cb98,c0c6d72e,c0d92fe0,c8c7e324,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c8c7e324,80400,c0c801f7,ffb,e6f4cbf4,...) at _vn_lock+0x5e vfs_knllock(c8c7e324,0,c0c6d72e,696,c82bc908,...) at vfs_knllock+0x29 knlist_remove_kq(0,e6f4cc14,c090c9a9,c82eed78,c82bc908,...) at knlist_remove_kq+0x85 knlist_remove(c82eed78,c82bc908,0,e6f4cc40,c084fe85,...) at knlist_remove+0x1b filt_vfsdetach(c82bc908,0,c0c6d72e,777,17,...) at filt_vfsdetach+0x39 knote_fdclose(c632d6c0,1d7,c0c6d256,440,c8f1d42c,...) at knote_fdclose+0xf5 kern_close(c632d6c0,1d7,e6f4cd2c,c0bb0a53,c632d6c0,...) at kern_close+0xd2 close(c632d6c0,e6f4ccf8,4,c0dcb8c0,c0d58d48,...) at close+0x1a syscall(e6f4cd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x2837b2a3, esp = 0xbfbfe48c, ebp = 0xbfbfe4a8 --- From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 14:09:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 580E6106566B; Tue, 8 Sep 2009 14:09:07 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id EF80D8FC19; Tue, 8 Sep 2009 14:09:06 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Ml1NY-000CZ0-Kl; Tue, 08 Sep 2009 17:09:04 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Vincent Hoffman In-reply-to: <4AA64808.4030105@unsane.co.uk> References: <20090611194557.GC98175@bsdcrew.de> <991123400909060811u9bea4d9rdbf453dfaae7c185@mail.gmail.com> <20090906162544.GA39448@bsdcrew.de> <4AA64808.4030105@unsane.co.uk> Comments: In-reply-to Vincent Hoffman message dated "Tue, 08 Sep 2009 13:03:20 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Sep 2009 17:09:04 +0300 From: Danny Braniss Message-ID: Cc: ports@freebsd.org, Odhiambo Washington , freebsd-current@freebsd.org, freebsd-emulation@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 14:09:07 -0000 > Danny Braniss wrote: > > [...] > > > >>>> ok, so some time has passed, but virtualbox-2.2.51r20457.tar.gz is no > >>>> longer available, there is a > >>>> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/virtualbox-2.2.51r20457.tar.bz2 > >>>> then again in ports/emulatores/virtualbox the version is 3.0.51r22226, > >>>> > >>>> can someone please explain? > >>>> > > > > hi, the above was my question, which was totally ignored, not nice. > > I will try and refrase it: > > the call for testing is for a version (2.2.51r20457) which is not available, while > > the ports is 3.0.51r22226, so while I managed to compile it, it complains that COM > > is not running, all this under 8BETA-3, both under 32 and 64 bit. > > thnaks, > > danny > > > > > The call for testing went out on 11th june > (http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008061.html) > I can only assume it was considered tested and working as the port was > committed on 15th june > (http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/virtualbox/Makefile?rev=1.1;content-type=text%2Fplain) > > Since then there have been 4 updates to the port. The last of which > updated it to 3.0.51r22226 on august 14th. > > I would say the call for testing is no longer valid, please use the > version in ports. thank you, and all those involved! danny From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 07:24:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBB901065672 for ; Tue, 8 Sep 2009 07:24:32 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 3A8A98FC12 for ; Tue, 8 Sep 2009 07:24:31 +0000 (UTC) Received: by bwz2 with SMTP id 2so743725bwz.43 for ; Tue, 08 Sep 2009 00:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=TdfqMSH0UaClRT/yGKFW0y4KgkHIoYMNrFIdOFFdxU8=; b=Is8z4c62mDdn61L29nDU5cPZ++T2pPZCJtc3GSQXLZg3rZAOrsZUVfv0yaXggiiNz2 KlqCbFQ2OyvmcjLk8pgh7S2TUbP6RGFUEME0OGhaPLfdi00tI/2YtYZBSVSzCcs7jgEn TfWYTIyDPMQ2uSbImWZ77/x5+ZSKhO7CHDm7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CxJuGERjScfxvTxvsHKrF8XYzkYY9R7QeawJxNctt3tt7j9uv3gbIROhuA8N2Q44n/ JFJgDAFACV48MsfmcPSyg300gopw6roecgp6/9NgTxhjraqbTghuflS/ZPlihjLPLpZM LVYncsIbpUrvK2O0YXrFlCqj/YJu21SbUTL+k= MIME-Version: 1.0 Received: by 10.204.153.217 with SMTP id l25mr12961201bkw.108.1252394670890; Tue, 08 Sep 2009 00:24:30 -0700 (PDT) Date: Tue, 8 Sep 2009 03:24:30 -0400 Message-ID: From: grarpamp To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 08 Sep 2009 14:32:17 +0000 Subject: tzsetup and EST5EDT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 07:24:32 -0000 Can't seem to set EST5EDT using the menus: wall: yes region: america country: united states zone: all eastern time choices, 1~10, come up with EST. Almost certain this is wrong. info google: EST EST5EDT Use 'cp /usr/share/zoneinfo/EST5EDT /etc/localtime' or 'echo y | tzsetup -s /usr/share/zoneinfo/EST5EDT' instead. RELENG_8 From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 14:50:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0D71106568D for ; Tue, 8 Sep 2009 14:50:14 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id BDC968FC0A for ; Tue, 8 Sep 2009 14:50:13 +0000 (UTC) Received: (qmail 9009 invoked from network); 8 Sep 2009 14:23:29 -0000 Received: from unknown (HELO ale.andxor.it) (192.168.2.5) by andxor.it with SMTP; 8 Sep 2009 14:23:29 -0000 Message-ID: <4AA668E0.1010305@FreeBSD.org> Date: Tue, 08 Sep 2009 16:23:28 +0200 From: Alex Dupre User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: Sergey Vinogradov References: <4AA65ABE.4000207@lazybytes.org> In-Reply-To: <4AA65ABE.4000207@lazybytes.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ath(4) Atheros AR9285 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 14:50:14 -0000 Sergey Vinogradov ha scritto: > Just wanted to know, if there will be any Atheros AR9285 support in > ath(4) driver in nearest future? I've got my ASUS Eee 1005HA with one of > these wireless adapters, and it doesn't seem to be working. I think it should work with FreeBSD 8.0. -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 15:00:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A25FA106566C for ; Tue, 8 Sep 2009 15:00:39 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id CE5D58FC0A for ; Tue, 8 Sep 2009 15:00:38 +0000 (UTC) Received: from demophon.fletchermoorland.co.uk (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.3/8.14.3) with ESMTP id n88F0UGD073234; Tue, 8 Sep 2009 16:00:31 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4AA67F6B.20800@fletchermoorland.co.uk> Date: Tue, 08 Sep 2009 15:59:39 +0000 From: Paul Wootton User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: oliver@namp.de References: <24905.1252413921@namp.de> In-Reply-To: <24905.1252413921@namp.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.64 on 192.168.0.1 X-Spam-Status: No, score=-4.4 required=10.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hydra.fletchermoorland.co.uk Cc: freebsd-current@freebsd.org Subject: Re: boot from raidz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 15:00:39 -0000 Oliver Fakler wrote: > On Mon 07/09/09 20:22 , Paul Wootton wrote:Oliver Fakler wrote: > > On Mon 07/09/09 13:40 , Bernhard Schmidt wrote: > > Am 07.09.2009 um 11:13 schrieb Oliver Fakler: > > > > > > BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; > } > > > > > > On Mon 07/09/09 10:07 , Bernhard Schmidt > > > wrote: > > > > > > > > > Am 06.09.2009 um 21:45 schrieb Oliver Fakler: > > > > > > > > > > > > > > > Hi all, > > > > > > > > i installed a 8.0 beta 3 amd64 based testsystem. > > > > > > > > i tried with a root on a raidz, but i have a problem after > the > > first > > > > reboot, there is a error message: > > > > > > > > can't load kernel > > > > I found something that boot root from raidz is not supported, > > but > > > > maybe there is a solution?? > > > > Hope some can help me > > > > > > > > > There are patches from Doug Rabson which add support for > booting > > from > > > raidz/raidz2. > > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html > [1]" > target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html > > [2]" > > > target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html > [2]" > target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html > > > > > " > > > target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html > [3]" > target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html > > [3]" > > > target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html > [4]" > target="_blank">http://lists.freebsd.org/pipermail/freebsd-fs/2008-December/005498.html > > Seems that patch made it already into the tree (r192194). > > > > > > > > > I tried it, but after a make obj && make depend the make failed > > with > > > different errors like undeclared and has no member named. > > > > > > I used patch raidzboot-14052009.diff started patching from > > /usr/src/ > > > sys/ , i'm not sure if this was the right way. > > > > > > I'm also not sure if the way of installation was the right one, > > > > here's the way i go: > > > > > > > > > gpart create -s GPT da0 > > > gpart add -b 34 -s 128 -t freebsd-boot da0 > > > gpart add -b 162 -s 5242880 -t freebsd-swap da0 > > > gpart add -b 5243042 -s 11534141 -t freebsd-zfs da0 > > > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 > > da0 > > > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 > > da1 > > > gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 > > da2 > > > > > Can you try zfsboot instead of gptzfsboot? > > > > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html > [5]" > target="_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html > > [4]" > > > target="_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html > [6]" > target="_blank">http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2009-05/msg00689.html > > > > at the end of the mail. > > > > > > > > > kldload /mnt2/boot/kernel/opensolaris.ko > > > kldload /mnt2/boot/kernel/zfs.ko > > > > > > zpool create tank raidz da0p3 da1p1 d2p1 > > > > > > zfs create tank/tmp > > > zfs create tank/usr > > > zfs create tank/var > > > > > > cd /dist/8.0-BETA3/base > > > export DESTDIR=/tank > > > ./install.sh > > > You are about to extract the base distribution into /tank - are > > you > > > SURE > > > you want to do this over your installed system (y/n)? y > > > cd ../kernels > > > ./install.sh generic > > > cd /tank/boot > > > cp -Rp GENERIC/* kernel/ > > > > > > cd /dist/8.0-BETA3/src > > > ./install.sh all > > > Extracting sources into /usr/src... > > > Extracting source component: base > > > Extracting source component: bin > > > Extracting source component: cddl > > > Extracting source component: contrib > > > Extracting source component: crypto > > > Extracting source component: etc > > > Extracting source component: games > > > Extracting source component: gnu > > > Extracting source component: include > > > Extracting source component: krb5 > > > Extracting source component: lib > > > Extracting source component: libexec > > > Extracting source component: release > > > Extracting source component: rescue > > > Extracting source component: sbin > > > Extracting source component: secure > > > Extracting source component: share > > > Extracting source component: sys > > > Extracting source component: tools > > > Extracting source component: ubin > > > Extracting source component: usbin > > > Done extracting sources. > > > Done extracting sources. > > > cd ../manpages > > > ./install.sh > > > > > > echo 'zfs_enable="YES"' > /tank/etc/rc.conf > > > echo 'LOADER_ZFS_SUPPORT="YES"' > /tank/etc/src.conf > > > echo 'zfs_load="YES"' > /tank/boot/loader.conf > > > echo 'vfs.root.mountfrom="zfs:tank"' >> /tank/boot/loader.conf > > > echo ´/dev/da0p2 none swap sw 0 0´>> > /tank/etc/fstab > > > > > > mkdir /boot/zfs > > > zpool export tank && zpool import tank > > > cp /boot/zfs/zpool.cache /tank/boot/zfs/ > > > > > > chroot /tank > > > mount -t devfs devfs /dev > > > unset DESTDIR > > > cd /usr/src/sys/boot/ > > > make obj > > > make depend > > > make > > > cd i386/loader > > > make install > > > umount /dev > > > touch /etc/fstab > > > exit > > > > > > export LD_LIBRARY_PATH=/mnt2/lib > > > zfs set mountpoint=legacy tank > > > zfs set mountpoint=/tmp tank/tmp > > > zfs set mountpoint=/var tank/var > > > zfs set mountpoint=/usr tank/usr > > > zpool set bootfs=tank tank > > > > > Seems correct at first glance. > > -- > > Bernhard > > testet with zfsboot instead of gptzfsboot but it was not > successfull > > :-( > > > > Links: > > ------ > > [2] http://mail.kuehlbox.de/parse.php%3Fredirect%3D%26lt%3Ba [7]" > target="_blank">http://mail.kuehlbox.de/parse.php?redirect= [3] > http://mail.kuehlbox.de/parse.php%3Fredirect%3D%26lt%3Ba [8]" > target="_blank">http://mail.kuehlbox.de/parse.php?redirect= [4] > http://mail.kuehlbox.de/parse.php%3Fredirect%3D%26lt%3Ba [9]" > target="_blank">http://mail.kuehlbox.de/parse.php?redirect= > _______________________________________________ > > mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current [11]" > target="_blank">http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > I have a fully running GPT ZFS RaidZ setup using what was at the > time 8-HEAD > I cant remember the exact steps I took, but one thing I have > different > is I have a root filesystem within my zpool > [ /usr/home/paul]$ gpart show > => 34 976773101 ada1 GPT (466G) > 34 256 1 freebsd-boot (128K) > 290 8388608 2 freebsd-swap (4.0G) > 8388898 147912557 3 freebsd-zfs (71G) > 156301455 820471680 - free - (391G) > => 34 488394988 ada2 GPT (233G) > 34 256 1 freebsd-boot (128K) > 290 8388608 2 freebsd-swap (4.0G) > 8388898 147912557 3 freebsd-zfs (71G) > 156301455 332093567 - free - (158G) > => 34 156301421 ada3 GPT (75G) > 34 256 1 freebsd-boot (128K) > 290 8388608 2 freebsd-swap (4.0G) > 8388898 147912557 3 freebsd-zfs (71G) > [ /usr/home/paul]$ zpool status > pool: zboot > state: ONLINE > scrub: none requested > config: > NAME STATE READ WRITE CKSUM > zboot ONLINE 0 0 0 > ada1p3 ONLINE 0 0 0 > ada2p3 ONLINE 0 0 0 > ada3p3 ONLINE 0 0 0 > errors: No known data errors > [ /usr/home/paul]$ zfs list > NAME USED AVAIL REFER MOUNTPOINT > zboot 33.5G 175G 18K none > zboot/root 12.4G 175G 12.2G none > zboot/tmp 82.9M 175G 82.6M none > zboot/usr 20.8G 175G 16.5G none > zboot/var 216M 175G 123M none > Im also using fstabs to mount my ZFS filesystems > [ /usr/home/paul]$ more /etc/fstab > # Device Mountpoint FStype Options Dump > > Pass# > zboot/root / zfs rw 0 > 0 > zboot/usr /usr zfs rw 0 > 0 > zboot/var /var zfs rw 0 > 0 > zboot/tmp /tmp zfs rw,noatime 0 > 0 > proc /proc procfs rw 0 > 0 > I remember speak to someone a while back, and I *think* we came to > the > conclusion that using the zpool as your root will not work correctly > and > you should really create a root filesystem inside the zpool > Lets me know how this works out for you > Paul > > ----------------------------------------------------------------------------------- > Fletcher Moorland Limited is a company registered in England and > Wales. > Registration number: 2984467. > Registered office: Elenora Street, Stoke on Trent, Staffordshire, > ST4 1QG. > VAT Registration number: 478730606 > Telephone: 01782 411021 | Fax: 01782 744470 | > http://www.fletchermoorland.co.uk [17]" > target="_blank">http://www.fletchermoorland.co.uk > _______________________________________________ > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current [19]" > target="_blank">http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "" > your pool is just a stripe, no raidz > > i testet it with striping, and it was successfull, but i need a > raidz > > there are some new errors on Beta4 > > can'tfind root filesystem > > maybe you're right with your idea of an extra root folder, but i > think if he can't find root filesystem, he also can't read fstab. > maybe more ideas? :-) > cheers > Oliver > > Links: > ------ > [1] http://mail.kuehlbox.de/parse.php?redirect= [2] http://mail.kuehlbox.de/parse.php?redirect= [3] http://mail.kuehlbox.de/parse.php?redirect= [4] http://mail.kuehlbox.de/parse.php?redirect= [5] http://mail.kuehlbox.de/parse.php?redirect= [6] http://mail.kuehlbox.de/parse.php?redirect= [7] http://mail.kuehlbox.de/parse.php?redirect= [8] http://mail.kuehlbox.de/parse.php?redirect= [9] http://mail.kuehlbox.de/parse.php?redirect= [11] http://mail.kuehlbox.de/parse.php?redirect= [17] http://mail.kuehlbox.de/parse.php?redirect= [19] http://mail.kuehlbox.de/parse.php?redirect= _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Ok, so now I feel like a fool... You're right... It's not a raidz, but it *should* have been one. I had tried MANY things and it was getting late (or early depending onm how you look at it) that night when I finally got the system up... So, i'll take my system off line in the next few days and try rebuilding with a raidz... I thought it was too good to be true Paul ----------------------------------------------------------------------------------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 15:43:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BA431065695; Tue, 8 Sep 2009 15:43:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 183008FC19; Tue, 8 Sep 2009 15:43:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n88Fhrt2095932; Tue, 8 Sep 2009 11:43:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n88Fhrge095909; Tue, 8 Sep 2009 15:43:53 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 8 Sep 2009 15:43:53 GMT Message-Id: <200909081543.n88Fhrge095909@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 15:43:54 -0000 TB --- 2009-09-08 15:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-08 15:25:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-09-08 15:25:00 - cleaning the object tree TB --- 2009-09-08 15:26:11 - cvsupping the source tree TB --- 2009-09-08 15:26:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-09-08 15:31:55 - building world TB --- 2009-09-08 15:31:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-08 15:31:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-08 15:31:55 - TARGET=amd64 TB --- 2009-09-08 15:31:55 - TARGET_ARCH=amd64 TB --- 2009-09-08 15:31:55 - TZ=UTC TB --- 2009-09-08 15:31:55 - __MAKE_CONF=/dev/null TB --- 2009-09-08 15:31:55 - cd /src TB --- 2009-09-08 15:31:55 - /usr/bin/make -B buildworld >>> World build started on Tue Sep 8 15:31:56 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gethostbyht.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gethostbynis.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gethostnamadr.c cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/getifaddrs.c /src/lib/libc/net/getifaddrs.c: In function 'getifaddrs': /src/lib/libc/net/getifaddrs.c:168: error: 'XXX' undeclared (first use in this function) /src/lib/libc/net/getifaddrs.c:168: error: (Each undeclared identifier is reported only once /src/lib/libc/net/getifaddrs.c:168: error: for each function it appears in.) *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-08 15:43:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-08 15:43:53 - ERROR: failed to build world TB --- 2009-09-08 15:43:53 - 509.45 user 74.31 system 1133.00 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 15:54:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECDEB106566B for ; Tue, 8 Sep 2009 15:54:10 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 8CE6B8FC08 for ; Tue, 8 Sep 2009 15:54:10 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n88Fs8Gg020466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Sep 2009 17:54:09 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <107BC6AC-0CF6-423F-8AD9-843DA1370035@lassitu.de> From: Stefan Bethke To: grarpamp In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Sep 2009 17:54:07 +0200 References: X-Mailer: Apple Mail (2.936) Cc: freebsd-current@freebsd.org Subject: Re: tzsetup and EST5EDT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 15:54:11 -0000 Am 08.09.2009 um 09:24 schrieb grarpamp: > Can't seem to set EST5EDT using the menus: > wall: yes > region: america > country: united states > zone: all eastern time choices, 1~10, come up with EST. > Almost certain this is wrong. > info google: EST EST5EDT > Use > 'cp /usr/share/zoneinfo/EST5EDT /etc/localtime' > or > 'echo y | tzsetup -s /usr/share/zoneinfo/EST5EDT' > instead. > RELENG_8 I get EDT for "1 - Eastern Time" when running sysinstall on an installed system. Is your local clock on the right day? If you think sysinstall should produce "EST5EDT", you're expecting the wrong thing. For quite some time, it's given the time zone abbreviation appropriate to the chosen location for the current date and time. I don't remember if that was ever different. Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 16:16:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87A6E1065676; Tue, 8 Sep 2009 16:16:53 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 30D628FC0C; Tue, 8 Sep 2009 16:16:52 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id C6E5E69959; Tue, 8 Sep 2009 16:00:42 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n88G0ska061229; Tue, 8 Sep 2009 16:00:54 GMT (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org, amd64@freebsd.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 08 Sep 2009 15:43:53 GMT." <200909081543.n88Fhrge095909@freebsd-current.sentex.ca> Date: Tue, 08 Sep 2009 16:00:54 +0000 Message-ID: <61228.1252425654@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 16:16:53 -0000 This ones mine. I'm working on the proper fix to replace the _NO_NAMESPACE_POLLUTION hack. I should have it cleared later tonight. Poul-Henning In message <200909081543.n88Fhrge095909@freebsd-current.sentex.ca>, FreeBSD Tin derbox writes: >TB --- 2009-09-08 15:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca >TB --- 2009-09-08 15:25:00 - starting HEAD tinderbox run for amd64/amd64 >TB --- 2009-09-08 15:25:00 - cleaning the object tree >TB --- 2009-09-08 15:26:11 - cvsupping the source tree >TB --- 2009-09-08 15:26:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile >TB --- 2009-09-08 15:31:55 - building world >TB --- 2009-09-08 15:31:55 - MAKEOBJDIRPREFIX=/obj >TB --- 2009-09-08 15:31:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin >TB --- 2009-09-08 15:31:55 - TARGET=amd64 >TB --- 2009-09-08 15:31:55 - TARGET_ARCH=amd64 >TB --- 2009-09-08 15:31:55 - TZ=UTC >TB --- 2009-09-08 15:31:55 - __MAKE_CONF=/dev/null >TB --- 2009-09-08 15:31:55 - cd /src >TB --- 2009-09-08 15:31:55 - /usr/bin/make -B buildworld >>>> World build started on Tue Sep 8 15:31:56 UTC 2009 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >[...] >cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN >-I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gethostbyht.c >cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN >-I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gethostbynis.c >cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN >-I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gethostnamadr.c >cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN >-I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/getifaddrs.c >/src/lib/libc/net/getifaddrs.c: In function 'getifaddrs': >/src/lib/libc/net/getifaddrs.c:168: error: 'XXX' undeclared (first use in this function) >/src/lib/libc/net/getifaddrs.c:168: error: (Each undeclared identifier is reported only once >/src/lib/libc/net/getifaddrs.c:168: error: for each function it appears in.) >*** Error code 1 > >Stop in /src/lib/libc. >*** Error code 1 > >Stop in /src. >*** Error code 1 > >Stop in /src. >*** Error code 1 > >Stop in /src. >*** Error code 1 > >Stop in /src. >TB --- 2009-09-08 15:43:53 - WARNING: /usr/bin/make returned exit code 1 >TB --- 2009-09-08 15:43:53 - ERROR: failed to build world >TB --- 2009-09-08 15:43:53 - 509.45 user 74.31 system 1133.00 real > > >http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 16:55:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 696CA1065672 for ; Tue, 8 Sep 2009 16:55:48 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id E79218FC20 for ; Tue, 8 Sep 2009 16:55:47 +0000 (UTC) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 253777562; Tue, 08 Sep 2009 19:55:44 +0300 Message-ID: <4AA68C8A.4060405@FreeBSD.org> Date: Tue, 08 Sep 2009 19:55:38 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Harald Schmalzbauer References: <1252225381.00160049.1252212601@10.7.7.3> In-Reply-To: <1252225381.00160049.1252212601@10.7.7.3> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Funding ODD support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 16:55:48 -0000 Harald Schmalzbauer wrote: > I'm looking for somebody who has time and knowledge to fix ODD support > in FreeBSD. > I'm willing to sponsor a decent ammount. > My problem is that I can't use FreeBSD for any task in which CD or DVD > is involved. > What I want is read/write support for any ATAPI/S-ATA ODD regarding > ISO9660 and audio. Of course I'd love to have UDF support also, but for > the beginning I'd be glad if FreeBSD could boot with an inserted audio > CD. This has been a problem for more than two years now, and disabling > DMA support for ata devices isn't a satisfying solution. > > So if you think ypu can fix this and make growisofs and cdrtools working > with ATAPI and SATA devices, please contact me. > If we have working ODD support in 8.0-release I'll donate 100 extra bucks. Funding is good, but could you first once more repeat what is your problem? Which controller do you use? Which drive? Which disks and which applications? Have you tried to use different controllers, drives, disks, applications? I am asking because there quite a lot of people successfully using ODD on FreeBSD. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 17:01:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A14A106568D for ; Tue, 8 Sep 2009 17:01:00 +0000 (UTC) (envelope-from nevtic@area51.capnet.state.tx.us) Received: from area51.capnet.state.tx.us (area51.capnet.state.tx.us [141.198.193.51]) by mx1.freebsd.org (Postfix) with ESMTP id 332F68FC1E for ; Tue, 8 Sep 2009 17:00:59 +0000 (UTC) Received: from area51.capnet.state.tx.us (localhost [127.0.0.1]) by area51.capnet.state.tx.us (8.14.3/8.14.3) with ESMTP id n88GW3oB098208 for ; Tue, 8 Sep 2009 11:32:03 -0500 (CDT) (envelope-from nevtic@area51.capnet.state.tx.us) Received: from localhost (nevtic@localhost) by area51.capnet.state.tx.us (8.14.3/8.14.3/Submit) with ESMTP id n88GW3Jw098205 for ; Tue, 8 Sep 2009 11:32:03 -0500 (CDT) (envelope-from nevtic@area51.capnet.state.tx.us) Date: Tue, 8 Sep 2009 11:32:03 -0500 (CDT) From: stuart cur To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="657637799-1648946924-1252426673=:98111" Content-ID: Subject: 8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 17:01:00 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --657637799-1648946924-1252426673=:98111 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: In 8.0-B4 for amd64, bge does not recognize that there is an active ethernet connection on bge0. Switching the cable to bge1 works correctly. This seems to be the same issue as reported on July 21 by Oyvind Rakvag, but I saw no response to that report. Attached are the dmesg.boot, /var/log/messages, and output of pciconf -lv from the very first boot. stu --657637799-1648946924-1252426673=:98111 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=messages Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=messages U2VwICA4IDE1OjUxOjE3ICBuZXdzeXNsb2dbNzc1XTogbG9nZmlsZSBmaXJz dCBjcmVhdGVkDQpTZXAgIDggMTU6NTE6MTcgIHN5c2xvZ2Q6IGtlcm5lbCBi b290IGZpbGUgaXMgL2Jvb3Qva2VybmVsL2tlcm5lbA0KU2VwICA4IDE1OjUx OjE3ICBrZXJuZWw6IENvcHlyaWdodCAoYykgMTk5Mi0yMDA5IFRoZSBGcmVl QlNEIFByb2plY3QuDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogQ29weXJp Z2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAx OTkxLCAxOTkyLCAxOTkzLCAxOTk0DQpTZXAgIDggMTU6NTE6MTcgIGtlcm5l bDogVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5p YS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4NClNlcCAgOCAxNTo1MToxNyAga2Vy bmVsOiBGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhl IEZyZWVCU0QgRm91bmRhdGlvbi4NClNlcCAgOCAxNTo1MToxNyAga2VybmVs OiBGcmVlQlNEIDguMC1CRVRBNCAjMDogU3VuIFNlcCAgNiAwNDo0NDozMSBV VEMgMjAwOQ0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IHJvb3RAbWFzb24u Y3NlLmJ1ZmZhbG8uZWR1Oi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMN ClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBXQVJOSU5HOiBXSVRORVNTIG9w dGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4NClNl cCAgOCAxNTo1MToxNyAga2VybmVsOiBUaW1lY291bnRlciAiaTgyNTQiIGZy ZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMA0KU2VwICA4IDE1OjUxOjE3 ICBrZXJuZWw6IENQVTogQU1EIE9wdGVyb24odG0pIFByb2Nlc3NvciAyNzAg KDIwMDQuNTUtTUh6IEs4LWNsYXNzIENQVSkNClNlcCAgOCAxNTo1MToxNyAg a2VybmVsOiBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQgPSAweDIwZjEy ICBTdGVwcGluZyA9IDINClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBGZWF0 dXJlcz0weDE3OGJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1D RSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENM RkxVU0gsTU1YLEZYU1IsU1NFLFNTRTIsSFRUPg0KU2VwICA4IDE1OjUxOjE3 ICBrZXJuZWw6IEZlYXR1cmVzMj0weDE8U1NFMz4NClNlcCAgOCAxNTo1MTox NyAga2VybmVsOiBBTUQgRmVhdHVyZXM9MHhlMjUwMDgwMDxTWVNDQUxMLE5Y LE1NWCssRkZYU1IsTE0sM0ROb3chKywzRE5vdyE+DQpTZXAgIDggMTU6NTE6 MTcgIGtlcm5lbDogQU1EIEZlYXR1cmVzMj0weDI8Q01QPg0KU2VwICA4IDE1 OjUxOjE3ICBrZXJuZWw6IHJlYWwgbWVtb3J5ICA9IDIxNDc0ODM2NDggKDIw NDggTUIpDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogYXZhaWwgbWVtb3J5 ID0gMjA1NDQwNjE0NCAoMTk1OSBNQikNClNlcCAgOCAxNTo1MToxNyAga2Vy bmVsOiBBQ1BJIEFQSUMgVGFibGU6IDxIUCAgICAgMDAwMDAwODM+DQpTZXAg IDggMTU6NTE6MTcgIGtlcm5lbDogRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vz c29yIFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzDQpTZXAgIDggMTU6NTE6MTcg IGtlcm5lbDogRnJlZUJTRC9TTVA6IDEgcGFja2FnZShzKSB4IDIgY29yZShz KQ0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGNwdTAgKEJTUCk6IEFQSUMg SUQ6ICAwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogY3B1MSAoQVApOiBB UElDIElEOiAgMQ0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IEFDUEkgV2Fy bmluZzogSW52YWxpZCBsZW5ndGggZm9yIFBtMWFDb250cm9sQmxvY2s6IDMy LCB1c2luZyBkZWZhdWx0IDE2IDIwMDkwNTIxIHRiZmFkdC03MDcNClNlcCAg OCAxNTo1MToxNyAga2VybmVsOiBBQ1BJIFdhcm5pbmc6IEludmFsaWQgbGVu Z3RoIGZvciBQbTFiQ29udHJvbEJsb2NrOiAzMiwgdXNpbmcgZGVmYXVsdCAx NiAyMDA5MDUyMSB0YmZhZHQtNzA3DQpTZXAgIDggMTU6NTE6MTcgIGtlcm5l bDogTUFEVDogRm9yY2luZyBhY3RpdmUtbG93IHBvbGFyaXR5IGFuZCBsZXZl bCB0cmlnZ2VyIGZvciBTQ0kNClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBp b2FwaWMwIDxWZXJzaW9uIDEuMT4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJk DQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogaW9hcGljMSA8VmVyc2lvbiAx LjE+IGlycXMgMjQtMjcgb24gbW90aGVyYm9hcmQNClNlcCAgOCAxNTo1MTox NyAga2VybmVsOiBpb2FwaWMyIDxWZXJzaW9uIDEuMT4gaXJxcyAyOC0zMSBv biBtb3RoZXJib2FyZA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGlvYXBp YzMgPFZlcnNpb24gMS4xPiBpcnFzIDMyLTM1IG9uIG1vdGhlcmJvYXJkDQpT ZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogaW9hcGljNCA8VmVyc2lvbiAxLjE+ IGlycXMgMzYtMzkgb24gbW90aGVyYm9hcmQNClNlcCAgOCAxNTo1MToxNyAg a2VybmVsOiBrYmQxIGF0IGtiZG11eDANClNlcCAgOCAxNTo1MToxNyAga2Vy bmVsOiBhY3BpMDogPEhQIEEwNT4gb24gbW90aGVyYm9hcmQNClNlcCAgOCAx NTo1MToxNyAga2VybmVsOiBhY3BpMDogW0lUSFJFQURdDQpTZXAgIDggMTU6 NTE6MTcgIGtlcm5lbDogYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpDQpT ZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogVGltZWNvdW50ZXIgIkFDUEktc2Fm ZSIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSA4NTANClNlcCAgOCAx NTo1MToxNyAga2VybmVsOiBhY3BpX3RpbWVyMDogPDMyLWJpdCB0aW1lciBh dCAzLjU3OTU0NU1Iej4gcG9ydCAweDkwOC0weDkwYiBvbiBhY3BpMA0KU2Vw ICA4IDE1OjUxOjE3ICBrZXJuZWw6IHBjaWIwOiA8QUNQSSBIb3N0LVBDSSBi cmlkZ2U+IG9uIGFjcGkwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogcGNp MDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjANClNlcCAgOCAxNTo1MToxNyAg a2VybmVsOiBwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAzLjAgb24gcGNpMA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IHBjaTE6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxDQpTZXAgIDggMTU6NTE6MTcgIGtl cm5lbDogb2hjaTA6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4g bWVtIDB4ZjdjZjAwMDAtMHhmN2NmMGZmZiBpcnEgMTkgYXQgZGV2aWNlIDAu MCBvbiBwY2kxDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogb2hjaTA6IFtJ VEhSRUFEXQ0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IHVzYnVzMDogPE9I Q0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMA0KU2VwICA4 IDE1OjUxOjE3ICBrZXJuZWw6IG9oY2kxOiA8T0hDSSAoZ2VuZXJpYykgVVNC IGNvbnRyb2xsZXI+IG1lbSAweGY3Y2UwMDAwLTB4ZjdjZTBmZmYgaXJxIDE5 IGF0IGRldmljZSAwLjEgb24gcGNpMQ0KU2VwICA4IDE1OjUxOjE3ICBrZXJu ZWw6IG9oY2kxOiBbSVRIUkVBRF0NClNlcCAgOCAxNTo1MToxNyAga2VybmVs OiB1c2J1czE6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24g b2hjaTENClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBwY2kxOiA8YmFzZSBw ZXJpcGhlcmFsPiBhdCBkZXZpY2UgMi4wIChubyBkcml2ZXIgYXR0YWNoZWQp DQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogcGNpMTogPGJhc2UgcGVyaXBo ZXJhbD4gYXQgZGV2aWNlIDIuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KU2Vw ICA4IDE1OjUxOjE3ICBrZXJuZWw6IHZnYXBjaTA6IDxWR0EtY29tcGF0aWJs ZSBkaXNwbGF5PiBwb3J0IDB4NDQwMC0weDQ0ZmYgbWVtIDB4ZjYwMDAwMDAt MHhmNmZmZmZmZiwweGY1ZmYwMDAwLTB4ZjVmZjBmZmYgYXQgZGV2aWNlIDMu MCBvbiBwY2kxDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogaXNhYjA6IDxQ Q0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDQuMCBvbiBwY2kwDQpTZXAgIDgg MTU6NTE6MTcgIGtlcm5lbDogaXNhMDogPElTQSBidXM+IG9uIGlzYWIwDQpT ZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogYXRhcGNpMDogPEFNRCA4MTExIFVE TUExMzMgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3 MC0weDE3NywweDM3NiwweDIwMDAtMHgyMDBmIGF0IGRldmljZSA0LjEgb24g cGNpMA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGF0YTA6IDxBVEEgY2hh bm5lbCAwPiBvbiBhdGFwY2kwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDog YXRhMDogW0lUSFJFQURdDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogYXRh MTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTANClNlcCAgOCAxNTo1MTox NyAga2VybmVsOiBhdGExOiBbSVRIUkVBRF0NClNlcCAgOCAxNTo1MToxNyAg a2VybmVsOiBwY2kwOiA8YnJpZGdlPiBhdCBkZXZpY2UgNC4zIChubyBkcml2 ZXIgYXR0YWNoZWQpDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogcGNpYjI6 IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAN ClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBwY2kyOiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liMg0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGNpc3MwOiA8 SFAgU21hcnQgQXJyYXkgNmk+IHBvcnQgMHg1MDAwLTB4NTBmZiBtZW0gMHhm N2RmMDAwMC0weGY3ZGYxZmZmLDB4ZjdkODAwMDAtMHhmN2RiZmZmZiBpcnEg MjQgYXQgZGV2aWNlIDQuMCBvbiBwY2kyDQpTZXAgIDggMTU6NTE6MTcgIGtl cm5lbDogY2lzczA6IFBFUkZPUk1BTlQgVHJhbnNwb3J0DQpTZXAgIDggMTU6 NTE6MTcgIGtlcm5lbDogY2lzczA6IFtJVEhSRUFEXQ0KU2VwICA4IDE1OjUx OjE3ICBrZXJuZWw6IHBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQg ZGV2aWNlIDguMCBvbiBwY2kwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDog cGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMNClNlcCAgOCAxNTo1MTox NyAga2VybmVsOiBiZ2UwOiA8SFAgTkM3NzgyIEdpZ2FiaXQgU2VydmVyIEFk YXB0ZXIsIEFTSUMgcmV2LiAweDIxMDA+IG1lbSAweGY3ZWYwMDAwLTB4Zjdl ZmZmZmYgaXJxIDI4IGF0IGRldmljZSA2LjAgb24gcGNpMw0KU2VwICA4IDE1 OjUxOjE3ICBrZXJuZWw6IG1paWJ1czA6IDxNSUkgYnVzPiBvbiBiZ2UwDQpT ZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogYnJncGh5MDogPEJDTTU3MDQgMTAv MTAwLzEwMDBiYXNlVFggUEhZPiBQSFkgMSBvbiBtaWlidXMwDQpTZXAgIDgg MTU6NTE6MTcgIGtlcm5lbDogYnJncGh5MDogIDEwYmFzZVQsIDEwYmFzZVQt RkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlVCwgMTAw MGJhc2VULUZEWCwgYXV0bw0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGJn ZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjE3OmE0OmE3OmViOmU0DQpTZXAg IDggMTU6NTE6MTcgIGtlcm5lbDogYmdlMDogW0lUSFJFQURdDQpTZXAgIDgg MTU6NTE6MTcgIGtlcm5lbDogYmdlMTogPEhQIE5DNzc4MiBHaWdhYml0IFNl cnZlciBBZGFwdGVyLCBBU0lDIHJldi4gMHgyMTAwPiBtZW0gMHhmN2VlMDAw MC0weGY3ZWVmZmZmIGlycSAyOSBhdCBkZXZpY2UgNi4xIG9uIHBjaTMNClNl cCAgOCAxNTo1MToxNyAga2VybmVsOiBtaWlidXMxOiA8TUlJIGJ1cz4gb24g YmdlMQ0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGJyZ3BoeTE6IDxCQ001 NzA0IDEwLzEwMC8xMDAwYmFzZVRYIFBIWT4gUEhZIDEgb24gbWlpYnVzMQ0K U2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGJyZ3BoeTE6ICAxMGJhc2VULCAx MGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFz ZVQsIDEwMDBiYXNlVC1GRFgsIGF1dG8NClNlcCAgOCAxNTo1MToxNyAga2Vy bmVsOiBiZ2UxOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxNzphNDphNzplYjpl Mw0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGJnZTE6IFtJVEhSRUFEXQ0K U2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IHBjaWI0OiA8QUNQSSBIb3N0LVBD SSBicmlkZ2U+IG9uIGFjcGkwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDog cGNpNDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjQNClNlcCAgOCAxNTo1MTox NyAga2VybmVsOiBwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSA5LjAgb24gcGNpNA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IHBj aTU6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1DQpTZXAgIDggMTU6NTE6MTcg IGtlcm5lbDogcmwwOiA8UmVhbFRlayA4MTM5IDEwLzEwMEJhc2VUWD4gcG9y dCAweDYwMDAtMHg2MGZmIG1lbSAweGY3ZmYwMDAwLTB4ZjdmZjAwZmYgaXJx IDMyIGF0IGRldmljZSA4LjAgb24gcGNpNQ0KU2VwICA4IDE1OjUxOjE3ICBr ZXJuZWw6IG1paWJ1czI6IDxNSUkgYnVzPiBvbiBybDANClNlcCAgOCAxNTo1 MToxNyAga2VybmVsOiBybHBoeTA6IDxSZWFsVGVrIGludGVybmFsIG1lZGlh IGludGVyZmFjZT4gUEhZIDAgb24gbWlpYnVzMg0KU2VwICA4IDE1OjUxOjE3 ICBrZXJuZWw6IHJscGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBi YXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8NClNlcCAgOCAxNTo1MToxNyAg a2VybmVsOiBybDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjQwOmY0OmVkOjk5 OmVjDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogcmwwOiBbSVRIUkVBRF0N ClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBwY2liNjogPEFDUEkgUENJLVBD SSBicmlkZ2U+IGF0IGRldmljZSAxMC4wIG9uIHBjaTQNClNlcCAgOCAxNTo1 MToxNyAga2VybmVsOiBwY2k2OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNg0K U2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGF0a2JkYzA6IDxLZXlib2FyZCBj b250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0IGlycSAxIG9uIGFj cGkwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogYXRrYmQwOiA8QVQgS2V5 Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzANClNlcCAgOCAxNTo1MToxNyAga2Vy bmVsOiBrYmQwIGF0IGF0a2JkMA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6 IGF0a2JkMDogW0dJQU5ULUxPQ0tFRF0NClNlcCAgOCAxNTo1MToxNyAga2Vy bmVsOiBhdGtiZDA6IFtJVEhSRUFEXQ0KU2VwICA4IDE1OjUxOjE3ICBrZXJu ZWw6IHBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMA0KU2Vw ICA4IDE1OjUxOjE3ICBrZXJuZWw6IHBzbTA6IFtHSUFOVC1MT0NLRURdDQpT ZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogcHNtMDogW0lUSFJFQURdDQpTZXAg IDggMTU6NTE6MTcgIGtlcm5lbDogcHNtMDogbW9kZWwgR2VuZXJpYyBQUy8y IG1vdXNlLCBkZXZpY2UgSUQgMA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6 IHVhcnQwOiA8MTY1NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAweDNmOC0weDNm ZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwDQpTZXAgIDggMTU6NTE6MTcg IGtlcm5lbDogdWFydDA6IFtGSUxURVJdDQpTZXAgIDggMTU6NTE6MTcgIGtl cm5lbDogZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyIChGREUpPiBw b3J0IDB4M2YyLTB4M2Y1IGlycSA2IGRycSAyIG9uIGFjcGkwDQpTZXAgIDgg MTU6NTE6MTcgIGtlcm5lbDogZmRjMDogW0ZJTFRFUl0NClNlcCAgOCAxNTo1 MToxNyAga2VybmVsOiBjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwDQpTZXAg IDggMTU6NTE6MTcgIGtlcm5lbDogcG93ZXJub3cwOiA8Q29vbGBuJ1F1aWV0 IEs4PiBvbiBjcHUwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogY3B1MTog PEFDUEkgQ1BVPiBvbiBhY3BpMA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6 IHBvd2Vybm93MTogPENvb2xgbidRdWlldCBLOD4gb24gY3B1MQ0KU2VwICA4 IDE1OjUxOjE3ICBrZXJuZWw6IG9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0 IGlvbWVtIDB4YzAwMDAtMHhjN2ZmZiwweGM4MDAwLTB4Y2JmZmYsMHhlZTAw MC0weGVmZmZmIG9uIGlzYTANClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBz YzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMA0K U2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IHNjMDogVkdBIDwxNiB2aXJ0dWFs IGNvbnNvbGVzLCBmbGFncz0weDMwMD4NClNlcCAgOCAxNTo1MToxNyAga2Vy bmVsOiB2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4 M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwDQpTZXAgIDggMTU6 NTE6MTcgIGtlcm5lbDogYXRydGMwOiA8QVQgUmVhbCBUaW1lIENsb2NrPiBh dCBwb3J0IDB4NzAgaXJxIDggb24gaXNhMA0KU2VwICA4IDE1OjUxOjE3ICBr ZXJuZWw6IHBwYzA6IGNhbm5vdCByZXNlcnZlIEkvTyBwb3J0IHJhbmdlDQpT ZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogdWFydDE6IDxOb24tc3RhbmRhcmQg bnM4MjUwIGNsYXNzIFVBUlQgd2l0aCBGSUZPcz4gYXQgcG9ydCAweDJmOC0w eDJmZiBpcnEgMyBvbiBpc2EwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDog dWFydDE6IFtGSUxURVJdDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogVGlt ZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYw0KU2VwICA4IDE1OjUx OjE3ICBrZXJuZWw6IHVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYx LjANClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiB1c2J1czE6IDEyTWJwcyBG dWxsIFNwZWVkIFVTQiB2MS4wDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDog dWdlbjAuMTogPEFNRD4gYXQgdXNidXMwDQpTZXAgIDggMTU6NTE6MTcgIGtl cm5lbDogdWh1YjA6IDxBTUQgT0hDSSByb290IEhVQiwgY2xhc3MgOS8wLCBy ZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMA0KU2VwICA4IDE1OjUx OjE3ICBrZXJuZWw6IHVnZW4xLjE6IDxBTUQ+IGF0IHVzYnVzMQ0KU2VwICA4 IDE1OjUxOjE3ICBrZXJuZWw6IHVodWIxOiA8QU1EIE9IQ0kgcm9vdCBIVUIs IGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czEN ClNlcCAgOCAxNTo1MToxNyAga2VybmVsOiBhY2QwOiBDRFJXIDxEVy0yMjRF LVIvQy5BQj4gYXQgYXRhMC1tYXN0ZXIgVURNQTMzDQpTZXAgIDggMTU6NTE6 MTcgIGtlcm5lbDogdWh1YjA6IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJsZSwg c2VsZiBwb3dlcmVkDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogdWh1YjE6 IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQpTZXAg IDggMTU6NTE6MTcgIGtlcm5lbDogZGEwIGF0IGNpc3MwIGJ1cyAwIHRhcmdl dCAwIGx1biAwDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogZGEwOiA8Q09N UEFRIFJBSUQgMSAgVk9MVU1FIE9LPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFND U0ktNCBkZXZpY2UgDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogZGEwOiAx MzUuMTY4TUIvcyB0cmFuc2ZlcnMNClNlcCAgOCAxNTo1MToxNyAga2VybmVs OiBkYTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZA0KU2VwICA4IDE1OjUx OjE3ICBrZXJuZWw6IGRhMDogNzAwMDFNQiAoMTQzMzYzMDQwIDUxMiBieXRl IHNlY3RvcnM6IDI1NUggMzJTL1QgMTc1NjlDKQ0KU2VwICA4IDE1OjUxOjE3 ICBrZXJuZWw6IGRhMSBhdCBjaXNzMCBidXMgMCB0YXJnZXQgMSBsdW4gMA0K U2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGRhMTogPENPTVBBUSBSQUlEIDEg IFZPTFVNRSBPSz4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTQgZGV2aWNl IA0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IGRhMTogMTM1LjE2OE1CL3Mg dHJhbnNmZXJzDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogZGExOiBDb21t YW5kIFF1ZXVlaW5nIGVuYWJsZWQNClNlcCAgOCAxNTo1MToxNyAga2VybmVs OiBkYTE6IDI4NjA5N01CICg1ODU5MjgyMjAgNTEyIGJ5dGUgc2VjdG9yczog MjU1SCAzMlMvVCA2NTUzNUMpDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDog U01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhDQpTZXAgIDggMTU6NTE6MTcgIGtl cm5lbDogV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0 IHJlZHVjZWQgcGVyZm9ybWFuY2UuDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5l bDogR0VPTTogZGEwOiBwYXJ0aXRpb24gMSBkb2VzIG5vdCBzdGFydCBvbiBh IHRyYWNrIGJvdW5kYXJ5Lg0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IEdF T006IGRhMDogcGFydGl0aW9uIDEgZG9lcyBub3QgZW5kIG9uIGEgdHJhY2sg Ym91bmRhcnkuDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogR0VPTTogZGEw czE6IGdlb21ldHJ5IGRvZXMgbm90IG1hdGNoIGxhYmVsICgyNTVoLDYzcyAh PSAyNTVoLDMycykuDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogR0VPTTog ZGExOiBwYXJ0aXRpb24gMSBkb2VzIG5vdCBzdGFydCBvbiBhIHRyYWNrIGJv dW5kYXJ5Lg0KU2VwICA4IDE1OjUxOjE3ICBrZXJuZWw6IEdFT006IGRhMTog cGFydGl0aW9uIDEgZG9lcyBub3QgZW5kIG9uIGEgdHJhY2sgYm91bmRhcnku DQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogR0VPTTogZGExczE6IGdlb21l dHJ5IGRvZXMgbm90IG1hdGNoIGxhYmVsICgyNTVoLDYzcyAhPSAyNTVoLDMy cykuDQpTZXAgIDggMTU6NTE6MTcgIGtlcm5lbDogVHJ5aW5nIHRvIG1vdW50 IHJvb3QgZnJvbSB1ZnM6L2Rldi9kYTBzMWENClNlcCAgOCAxNTo1MToyOCAg bG9naW46IFJPT1QgTE9HSU4gKHJvb3QpIE9OIHR0eXYxDQpTZXAgIDggMTU6 NTI6MTIgIGtlcm5lbDogYmdlMTogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQ DQpTZXAgIDggMTU6NTI6NTEgIGtlcm5lbDogYmdlMTogbGluayBzdGF0ZSBj aGFuZ2VkIHRvIERPV04NClNlcCAgOCAxNTo1Mjo1MyAga2VybmVsOiBiZ2Ux OiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANClNlcCAgOCAxNTo1Mzo0OSAg a2VybmVsOiBiZ2UxOiBwcm9taXNjdW91cyBtb2RlIGVuYWJsZWQNClNlcCAg OCAxNTo1NDoxMiAga2VybmVsOiBiZ2UxOiBwcm9taXNjdW91cyBtb2RlIGRp c2FibGVkDQpTZXAgIDggMTU6NTk6MTkgIHJvb3Q6IFVua25vd24gVVNCIGRl dmljZTogdmVuZG9yIDB4MTNmZSBwcm9kdWN0IDB4MWEyMSBidXMgdWh1YjEN ClNlcCAgOCAxNTo1OToxOSAga2VybmVsOiB1Z2VuMS4yOiA8dmVuZG9yIDB4 MTNmZT4gYXQgdXNidXMxDQpTZXAgIDggMTU6NTk6MTkgIGtlcm5lbDogdW1h c3MwOiA8dmVuZG9yIDB4MTNmZSBVU0IgRElTSyBQcm8sIGNsYXNzIDAvMCwg cmV2IDIuMDAvMS4wMCwgYWRkciAyPiBvbiB1c2J1czENClNlcCAgOCAxNTo1 OToxOSAga2VybmVsOiB1bWFzczA6ICBTQ1NJIG92ZXIgQnVsay1Pbmx5OyBx dWlya3MgPSAweDAwMDANClNlcCAgOCAxNTo1OToyMCAga2VybmVsOiB1bWFz czA6MzowOi0xOiBBdHRhY2hlZCB0byBzY2J1czMNClNlcCAgOCAxNTo1OToy MSAga2VybmVsOiAocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBURVNUIFVO SVQgUkVBRFkuIENEQjogMCAwIDAgMCAwIDAgDQpTZXAgIDggMTU6NTk6MjEg IGtlcm5lbDogKHByb2JlMDp1bWFzcy1zaW0wOjA6MDowKTogQ0FNIFN0YXR1 czogU0NTSSBTdGF0dXMgRXJyb3INClNlcCAgOCAxNTo1OToyMSAga2VybmVs OiAocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBTQ1NJIFN0YXR1czogQ2hl Y2sgQ29uZGl0aW9uDQpTZXAgIDggMTU6NTk6MjEgIGtlcm5lbDogKHByb2Jl MDp1bWFzcy1zaW0wOjA6MDowKTogVU5JVCBBVFRFTlRJT04gYXNjOjI4LDAN ClNlcCAgOCAxNTo1OToyMSAga2VybmVsOiAocHJvYmUwOnVtYXNzLXNpbTA6 MDowOjApOiBOb3QgcmVhZHkgdG8gcmVhZHkgY2hhbmdlLCBtZWRpdW0gbWF5 IGhhdmUgY2hhbmdlZA0KU2VwICA4IDE1OjU5OjIxICBrZXJuZWw6IChwcm9i ZTA6dW1hc3Mtc2ltMDowOjA6MCk6IFJldHJ5aW5nIENvbW1hbmQgKHBlciBT ZW5zZSBEYXRhKQ0KU2VwICA4IDE1OjU5OjIxICBrZXJuZWw6IGRhMiBhdCB1 bWFzcy1zaW0wIGJ1cyAwIHRhcmdldCAwIGx1biAwDQpTZXAgIDggMTU6NTk6 MjEgIGtlcm5lbDogZGEyOiA8IFVTQiBESVNLIFBybyBQTUFQPiBSZW1vdmFi bGUgRGlyZWN0IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIA0KU2VwICA4IDE1OjU5 OjIxICBrZXJuZWw6IGRhMjogMS4wMDBNQi9zIHRyYW5zZmVycw0KU2VwICA4 IDE1OjU5OjIxICBrZXJuZWw6IGRhMjogMTk0MU1CICgzOTc2MTkyIDUxMiBi eXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMjQ3QykNClNlcCAgOCAxNTo1OToy MSAga2VybmVsOiAocHJvYmUwOnVtYXNzLXNpbTA6MDowOjEpOiBURVNUIFVO SVQgUkVBRFkuIENEQjogMCAyMCAwIDAgMCAwIA0KU2VwICA4IDE1OjU5OjIx ICBrZXJuZWw6IChwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MSk6IENBTSBTdGF0 dXM6IFNDU0kgU3RhdHVzIEVycm9yDQpTZXAgIDggMTU6NTk6MjEgIGtlcm5l bDogKHByb2JlMDp1bWFzcy1zaW0wOjA6MDoxKTogU0NTSSBTdGF0dXM6IENo ZWNrIENvbmRpdGlvbg0KU2VwICA4IDE1OjU5OjIxICBrZXJuZWw6IChwcm9i ZTA6dW1hc3Mtc2ltMDowOjA6MSk6IFVOSVQgQVRURU5USU9OIGFzYzoyOCww DQpTZXAgIDggMTU6NTk6MjEgIGtlcm5lbDogKHByb2JlMDp1bWFzcy1zaW0w OjA6MDoxKTogTm90IHJlYWR5IHRvIHJlYWR5IGNoYW5nZSwgbWVkaXVtIG1h eSBoYXZlIGNoYW5nZWQNClNlcCAgOCAxNTo1OToyMSAga2VybmVsOiAocHJv YmUwOnVtYXNzLXNpbTA6MDowOjEpOiBSZXRyeWluZyBDb21tYW5kIChwZXIg U2Vuc2UgRGF0YSkNClNlcCAgOCAxNTo1OToyMSAga2VybmVsOiBkYTMgYXQg dW1hc3Mtc2ltMCBidXMgMCB0YXJnZXQgMCBsdW4gMQ0KU2VwICA4IDE1OjU5 OjIxICBrZXJuZWw6IGRhMzogPCBVU0IgRElTSyBQcm8gUE1BUD4gUmVtb3Zh YmxlIERpcmVjdCBBY2Nlc3MgU0NTSS0wIGRldmljZSANClNlcCAgOCAxNTo1 OToyMSAga2VybmVsOiBkYTM6IDEuMDAwTUIvcyB0cmFuc2ZlcnMNClNlcCAg OCAxNTo1OToyMSAga2VybmVsOiBkYTM6IDI0TUIgKDUwMTc2IDUxMiBieXRl IHNlY3RvcnM6IDY0SCAzMlMvVCAyNEMpDQpTZXAgIDggMTU6NTk6MjIgIGtl cm5lbDogR0VPTTogZGEyOiBwYXJ0aXRpb24gMSBkb2VzIG5vdCBzdGFydCBv biBhIHRyYWNrIGJvdW5kYXJ5Lg0KU2VwICA4IDE1OjU5OjIyICBrZXJuZWw6 IEdFT006IGRhMjogcGFydGl0aW9uIDEgZG9lcyBub3QgZW5kIG9uIGEgdHJh Y2sgYm91bmRhcnkuDQo= --657637799-1648946924-1252426673=:98111 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=dmesg.boot Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=dmesg.boot Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2Yg VGhlIEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVCU0QgOC4wLUJFVEE0ICMw OiBTdW4gU2VwICA2IDA0OjQ0OjMxIFVUQyAyMDA5DQogICAgcm9vdEBtYXNv bi5jc2UuYnVmZmFsby5lZHU6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJ Qw0KV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJl ZHVjZWQgcGVyZm9ybWFuY2UuDQpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1 ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMA0KQ1BVOiBBTUQgT3B0ZXJvbih0 bSkgUHJvY2Vzc29yIDI3MCAoMjAwNC41NS1NSHogSzgtY2xhc3MgQ1BVKQ0K ICBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQgPSAweDIwZjEyICBTdGVw cGluZyA9IDINCiAgRmVhdHVyZXM9MHgxNzhiZmJmZjxGUFUsVk1FLERFLFBT RSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxD TU9WLFBBVCxQU0UzNixDTEZMVVNILE1NWCxGWFNSLFNTRSxTU0UyLEhUVD4N CiAgRmVhdHVyZXMyPTB4MTxTU0UzPg0KICBBTUQgRmVhdHVyZXM9MHhlMjUw MDgwMDxTWVNDQUxMLE5YLE1NWCssRkZYU1IsTE0sM0ROb3chKywzRE5vdyE+ DQogIEFNRCBGZWF0dXJlczI9MHgyPENNUD4NCnJlYWwgbWVtb3J5ICA9IDIx NDc0ODM2NDggKDIwNDggTUIpDQphdmFpbCBtZW1vcnkgPSAyMDU0NDA2MTQ0 ICgxOTU5IE1CKQ0KQUNQSSBBUElDIFRhYmxlOiA8SFAgICAgIDAwMDAwMDgz Pg0KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3Rl ZDogMiBDUFVzDQpGcmVlQlNEL1NNUDogMSBwYWNrYWdlKHMpIHggMiBjb3Jl KHMpDQogY3B1MCAoQlNQKTogQVBJQyBJRDogIDANCiBjcHUxIChBUCk6IEFQ SUMgSUQ6ICAxDQpBQ1BJIFdhcm5pbmc6IEludmFsaWQgbGVuZ3RoIGZvciBQ bTFhQ29udHJvbEJsb2NrOiAzMiwgdXNpbmcgZGVmYXVsdCAxNiAyMDA5MDUy MSB0YmZhZHQtNzA3DQpBQ1BJIFdhcm5pbmc6IEludmFsaWQgbGVuZ3RoIGZv ciBQbTFiQ29udHJvbEJsb2NrOiAzMiwgdXNpbmcgZGVmYXVsdCAxNiAyMDA5 MDUyMSB0YmZhZHQtNzA3DQpNQURUOiBGb3JjaW5nIGFjdGl2ZS1sb3cgcG9s YXJpdHkgYW5kIGxldmVsIHRyaWdnZXIgZm9yIFNDSQ0KaW9hcGljMCA8VmVy c2lvbiAxLjE+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZA0KaW9hcGljMSA8 VmVyc2lvbiAxLjE+IGlycXMgMjQtMjcgb24gbW90aGVyYm9hcmQNCmlvYXBp YzIgPFZlcnNpb24gMS4xPiBpcnFzIDI4LTMxIG9uIG1vdGhlcmJvYXJkDQpp b2FwaWMzIDxWZXJzaW9uIDEuMT4gaXJxcyAzMi0zNSBvbiBtb3RoZXJib2Fy ZA0KaW9hcGljNCA8VmVyc2lvbiAxLjE+IGlycXMgMzYtMzkgb24gbW90aGVy Ym9hcmQNCmtiZDEgYXQga2JkbXV4MA0KYWNwaTA6IDxIUCBBMDU+IG9uIG1v dGhlcmJvYXJkDQphY3BpMDogW0lUSFJFQURdDQphY3BpMDogUG93ZXIgQnV0 dG9uIChmaXhlZCkNClRpbWVjb3VudGVyICJBQ1BJLXNhZmUiIGZyZXF1ZW5j eSAzNTc5NTQ1IEh6IHF1YWxpdHkgODUwDQphY3BpX3RpbWVyMDogPDMyLWJp dCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDkwOC0weDkwYiBvbiBh Y3BpMA0KcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gb24gYWNwaTAN CnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwDQpwY2liMTogPEFDUEkg UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzLjAgb24gcGNpMA0KcGNpMTog PEFDUEkgUENJIGJ1cz4gb24gcGNpYjENCm9oY2kwOiA8T0hDSSAoZ2VuZXJp YykgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGY3Y2YwMDAwLTB4ZjdjZjBmZmYg aXJxIDE5IGF0IGRldmljZSAwLjAgb24gcGNpMQ0Kb2hjaTA6IFtJVEhSRUFE XQ0KdXNidXMwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9u IG9oY2kwDQpvaGNpMTogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVy PiBtZW0gMHhmN2NlMDAwMC0weGY3Y2UwZmZmIGlycSAxOSBhdCBkZXZpY2Ug MC4xIG9uIHBjaTENCm9oY2kxOiBbSVRIUkVBRF0NCnVzYnVzMTogPE9IQ0kg KGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMQ0KcGNpMTogPGJh c2UgcGVyaXBoZXJhbD4gYXQgZGV2aWNlIDIuMCAobm8gZHJpdmVyIGF0dGFj aGVkKQ0KcGNpMTogPGJhc2UgcGVyaXBoZXJhbD4gYXQgZGV2aWNlIDIuMiAo bm8gZHJpdmVyIGF0dGFjaGVkKQ0KdmdhcGNpMDogPFZHQS1jb21wYXRpYmxl IGRpc3BsYXk+IHBvcnQgMHg0NDAwLTB4NDRmZiBtZW0gMHhmNjAwMDAwMC0w eGY2ZmZmZmZmLDB4ZjVmZjAwMDAtMHhmNWZmMGZmZiBhdCBkZXZpY2UgMy4w IG9uIHBjaTENCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSA0 LjAgb24gcGNpMA0KaXNhMDogPElTQSBidXM+IG9uIGlzYWIwDQphdGFwY2kw OiA8QU1EIDgxMTEgVURNQTEzMyBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4 MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4MjAwMC0weDIwMGYgYXQg ZGV2aWNlIDQuMSBvbiBwY2kwDQphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24g YXRhcGNpMA0KYXRhMDogW0lUSFJFQURdDQphdGExOiA8QVRBIGNoYW5uZWwg MT4gb24gYXRhcGNpMA0KYXRhMTogW0lUSFJFQURdDQpwY2kwOiA8YnJpZGdl PiBhdCBkZXZpY2UgNC4zIChubyBkcml2ZXIgYXR0YWNoZWQpDQpwY2liMjog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA3LjAgb24gcGNpMA0K cGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjINCmNpc3MwOiA8SFAgU21h cnQgQXJyYXkgNmk+IHBvcnQgMHg1MDAwLTB4NTBmZiBtZW0gMHhmN2RmMDAw MC0weGY3ZGYxZmZmLDB4ZjdkODAwMDAtMHhmN2RiZmZmZiBpcnEgMjQgYXQg ZGV2aWNlIDQuMCBvbiBwY2kyDQpjaXNzMDogUEVSRk9STUFOVCBUcmFuc3Bv cnQNCmNpc3MwOiBbSVRIUkVBRF0NCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJy aWRnZT4gYXQgZGV2aWNlIDguMCBvbiBwY2kwDQpwY2kzOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMw0KYmdlMDogPEhQIE5DNzc4MiBHaWdhYml0IFNlcnZl ciBBZGFwdGVyLCBBU0lDIHJldi4gMHgyMTAwPiBtZW0gMHhmN2VmMDAwMC0w eGY3ZWZmZmZmIGlycSAyOCBhdCBkZXZpY2UgNi4wIG9uIHBjaTMNCm1paWJ1 czA6IDxNSUkgYnVzPiBvbiBiZ2UwDQpicmdwaHkwOiA8QkNNNTcwNCAxMC8x MDAvMTAwMGJhc2VUWCBQSFk+IFBIWSAxIG9uIG1paWJ1czANCmJyZ3BoeTA6 ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgt RkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1GRFgsIGF1dG8NCmJnZTA6IEV0 aGVybmV0IGFkZHJlc3M6IDAwOjE3OmE0OmE3OmViOmU0DQpiZ2UwOiBbSVRI UkVBRF0NCmJnZTE6IDxIUCBOQzc3ODIgR2lnYWJpdCBTZXJ2ZXIgQWRhcHRl ciwgQVNJQyByZXYuIDB4MjEwMD4gbWVtIDB4ZjdlZTAwMDAtMHhmN2VlZmZm ZiBpcnEgMjkgYXQgZGV2aWNlIDYuMSBvbiBwY2kzDQptaWlidXMxOiA8TUlJ IGJ1cz4gb24gYmdlMQ0KYnJncGh5MTogPEJDTTU3MDQgMTAvMTAwLzEwMDBi YXNlVFggUEhZPiBQSFkgMSBvbiBtaWlidXMxDQpicmdwaHkxOiAgMTBiYXNl VCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAw MGJhc2VULCAxMDAwYmFzZVQtRkRYLCBhdXRvDQpiZ2UxOiBFdGhlcm5ldCBh ZGRyZXNzOiAwMDoxNzphNDphNzplYjplMw0KYmdlMTogW0lUSFJFQURdDQpw Y2liNDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBvbiBhY3BpMA0KcGNpNDog PEFDUEkgUENJIGJ1cz4gb24gcGNpYjQNCnBjaWI1OiA8QUNQSSBQQ0ktUENJ IGJyaWRnZT4gYXQgZGV2aWNlIDkuMCBvbiBwY2k0DQpwY2k1OiA8QUNQSSBQ Q0kgYnVzPiBvbiBwY2liNQ0KcmwwOiA8UmVhbFRlayA4MTM5IDEwLzEwMEJh c2VUWD4gcG9ydCAweDYwMDAtMHg2MGZmIG1lbSAweGY3ZmYwMDAwLTB4Zjdm ZjAwZmYgaXJxIDMyIGF0IGRldmljZSA4LjAgb24gcGNpNQ0KbWlpYnVzMjog PE1JSSBidXM+IG9uIHJsMA0KcmxwaHkwOiA8UmVhbFRlayBpbnRlcm5hbCBt ZWRpYSBpbnRlcmZhY2U+IFBIWSAwIG9uIG1paWJ1czINCnJscGh5MDogIDEw YmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgs IGF1dG8NCnJsMDogRXRoZXJuZXQgYWRkcmVzczogMDA6NDA6ZjQ6ZWQ6OTk6 ZWMNCnJsMDogW0lUSFJFQURdDQpwY2liNjogPEFDUEkgUENJLVBDSSBicmlk Z2U+IGF0IGRldmljZSAxMC4wIG9uIHBjaTQNCnBjaTY6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWI2DQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAo aTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMA0KYXRrYmQw OiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzANCmtiZDAgYXQgYXRr YmQwDQphdGtiZDA6IFtHSUFOVC1MT0NLRURdDQphdGtiZDA6IFtJVEhSRUFE XQ0KcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwDQpwc20w OiBbR0lBTlQtTE9DS0VEXQ0KcHNtMDogW0lUSFJFQURdDQpwc20wOiBtb2Rl bCBHZW5lcmljIFBTLzIgbW91c2UsIGRldmljZSBJRCAwDQp1YXJ0MDogPDE2 NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxh Z3MgMHgxMCBvbiBhY3BpMA0KdWFydDA6IFtGSUxURVJdDQpmZGMwOiA8Zmxv cHB5IGRyaXZlIGNvbnRyb2xsZXIgKEZERSk+IHBvcnQgMHgzZjItMHgzZjUg aXJxIDYgZHJxIDIgb24gYWNwaTANCmZkYzA6IFtGSUxURVJdDQpjcHUwOiA8 QUNQSSBDUFU+IG9uIGFjcGkwDQpwb3dlcm5vdzA6IDxDb29sYG4nUXVpZXQg Szg+IG9uIGNwdTANCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTANCnBvd2Vy bm93MTogPENvb2xgbidRdWlldCBLOD4gb24gY3B1MQ0Kb3JtMDogPElTQSBP cHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhjMDAwMC0weGM3ZmZmLDB4YzgwMDAt MHhjYmZmZiwweGVlMDAwLTB4ZWZmZmYgb24gaXNhMA0Kc2MwOiA8U3lzdGVt IGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTANCnNjMDogVkdBIDwx NiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4NCnZnYTA6IDxHZW5l cmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAw MC0weGJmZmZmIG9uIGlzYTANCmF0cnRjMDogPEFUIFJlYWwgVGltZSBDbG9j az4gYXQgcG9ydCAweDcwIGlycSA4IG9uIGlzYTANCnBwYzA6IGNhbm5vdCBy ZXNlcnZlIEkvTyBwb3J0IHJhbmdlDQp1YXJ0MTogPE5vbi1zdGFuZGFyZCBu czgyNTAgY2xhc3MgVUFSVCB3aXRoIEZJRk9zPiBhdCBwb3J0IDB4MmY4LTB4 MmZmIGlycSAzIG9uIGlzYTANCnVhcnQxOiBbRklMVEVSXQ0KVGltZWNvdW50 ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYw0KdXNidXMwOiAxMk1icHMgRnVs bCBTcGVlZCBVU0IgdjEuMA0KdXNidXMxOiAxMk1icHMgRnVsbCBTcGVlZCBV U0IgdjEuMA0KdWdlbjAuMTogPEFNRD4gYXQgdXNidXMwDQp1aHViMDogPEFN RCBPSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFk ZHIgMT4gb24gdXNidXMwDQp1Z2VuMS4xOiA8QU1EPiBhdCB1c2J1czENCnVo dWIxOiA8QU1EIE9IQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAv MS4wMCwgYWRkciAxPiBvbiB1c2J1czENCmFjZDA6IENEUlcgPERXLTIyNEUt Ui9DLkFCPiBhdCBhdGEwLW1hc3RlciBVRE1BMzMNCnVodWIwOiAzIHBvcnRz IHdpdGggMyByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1YjE6IDMgcG9y dHMgd2l0aCAzIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQpkYTAgYXQgY2lz czAgYnVzIDAgdGFyZ2V0IDAgbHVuIDANCmRhMDogPENPTVBBUSBSQUlEIDEg IFZPTFVNRSBPSz4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTQgZGV2aWNl IA0KZGEwOiAxMzUuMTY4TUIvcyB0cmFuc2ZlcnMNCmRhMDogQ29tbWFuZCBR dWV1ZWluZyBlbmFibGVkDQpkYTA6IDcwMDAxTUIgKDE0MzM2MzA0MCA1MTIg Ynl0ZSBzZWN0b3JzOiAyNTVIIDMyUy9UIDE3NTY5QykNCmRhMSBhdCBjaXNz MCBidXMgMCB0YXJnZXQgMSBsdW4gMA0KZGExOiA8Q09NUEFRIFJBSUQgMSAg Vk9MVU1FIE9LPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNCBkZXZpY2Ug DQpkYTE6IDEzNS4xNjhNQi9zIHRyYW5zZmVycw0KZGExOiBDb21tYW5kIFF1 ZXVlaW5nIGVuYWJsZWQNCmRhMTogMjg2MDk3TUIgKDU4NTkyODIyMCA1MTIg Ynl0ZSBzZWN0b3JzOiAyNTVIIDMyUy9UIDY1NTM1QykNClNNUDogQVAgQ1BV ICMxIExhdW5jaGVkIQ0KV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxl ZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuDQpHRU9NOiBkYTA6IHBh cnRpdGlvbiAxIGRvZXMgbm90IHN0YXJ0IG9uIGEgdHJhY2sgYm91bmRhcnku DQpHRU9NOiBkYTA6IHBhcnRpdGlvbiAxIGRvZXMgbm90IGVuZCBvbiBhIHRy YWNrIGJvdW5kYXJ5Lg0KR0VPTTogZGEwczE6IGdlb21ldHJ5IGRvZXMgbm90 IG1hdGNoIGxhYmVsICgyNTVoLDYzcyAhPSAyNTVoLDMycykuDQpHRU9NOiBk YTE6IHBhcnRpdGlvbiAxIGRvZXMgbm90IHN0YXJ0IG9uIGEgdHJhY2sgYm91 bmRhcnkuDQpHRU9NOiBkYTE6IHBhcnRpdGlvbiAxIGRvZXMgbm90IGVuZCBv biBhIHRyYWNrIGJvdW5kYXJ5Lg0KR0VPTTogZGExczE6IGdlb21ldHJ5IGRv ZXMgbm90IG1hdGNoIGxhYmVsICgyNTVoLDYzcyAhPSAyNTVoLDMycykuDQpU cnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2RhMHMxYQ0K --657637799-1648946924-1252426673=:98111 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=pciconf-lv Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=pciconf-lv cGNpYjFAcGNpMDowOjM6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAw MDAwIGNoaXA9MHg3NDYwMTAyMiByZXY9MHgwNyBoZHI9MHgwMQ0KICAgIHZl bmRvciAgICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScNCiAg ICBkZXZpY2UgICAgID0gJ1BDSSBCcmlkZ2UgKEFNRC04MTExKScNCiAgICBj bGFzcyAgICAgID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kN CmlzYWIwQHBjaTA6MDo0OjA6CWNsYXNzPTB4MDYwMTAwIGNhcmQ9MHgzMjAz MGUxMSBjaGlwPTB4NzQ2ODEwMjIgcmV2PTB4MDUgaGRyPTB4MDANCiAgICB2 ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknDQog ICAgZGV2aWNlICAgICA9ICdMUEMgQnJpZGdlIChBTUQtODExMSknDQogICAg Y2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBQQ0ktSVNB DQphdGFwY2kwQHBjaTA6MDo0OjE6CWNsYXNzPTB4MDEwMThhIGNhcmQ9MHgz MjA0MGUxMSBjaGlwPTB4NzQ2OTEwMjIgcmV2PTB4MDMgaGRyPTB4MDANCiAg ICB2ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCkn DQogICAgZGV2aWNlICAgICA9ICdVbHRyYUFUQS8xMzMgQ29udHJvbGxlciAo QU1ELTgxMTEpJw0KICAgIGNsYXNzICAgICAgPSBtYXNzIHN0b3JhZ2UNCiAg ICBzdWJjbGFzcyAgID0gQVRBDQpub25lMEBwY2kwOjA6NDozOgljbGFzcz0w eDA2ODAwMCBjYXJkPTB4MzIwNTBlMTEgY2hpcD0weDc0NmIxMDIyIHJldj0w eDA1IGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBNaWNy byBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAgPSAnQU1ELTgxMTEg QUNQSSBTeXN0ZW0gTWFuYWdlbWVudCBDb250cm9sbGVyJw0KICAgIGNsYXNz ICAgICAgPSBicmlkZ2UNCnBjaWIyQHBjaTA6MDo3OjA6CWNsYXNzPTB4MDYw NDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4NzQ1MDEwMjIgcmV2PTB4MTIg aGRyPTB4MDENCiAgICB2ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERl dmljZXMgKEFNRCknDQogICAgZGV2aWNlICAgICA9ICdQQ0ktWCBCcmlkZ2Ug KEFNRC04MTMxKScNCiAgICBjbGFzcyAgICAgID0gYnJpZGdlDQogICAgc3Vi Y2xhc3MgICA9IFBDSS1QQ0kNCmlvYXBpYzBAcGNpMDowOjc6MToJY2xhc3M9 MHgwODAwMTAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHg3NDUxMTAyMiByZXY9 MHgwMSBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnQWR2YW5jZWQgTWlj cm8gRGV2aWNlcyAoQU1EKScNCiAgICBkZXZpY2UgICAgID0gJ1BDSS1YIElP QVBJQyAoQU1ELTgxMzEpJw0KICAgIGNsYXNzICAgICAgPSBiYXNlIHBlcmlw aGVyYWwNCiAgICBzdWJjbGFzcyAgID0gaW50ZXJydXB0IGNvbnRyb2xsZXIN CnBjaWIzQHBjaTA6MDo4OjA6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAw MDAwMCBjaGlwPTB4NzQ1MDEwMjIgcmV2PTB4MTIgaGRyPTB4MDENCiAgICB2 ZW5kb3IgICAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknDQog ICAgZGV2aWNlICAgICA9ICdQQ0ktWCBCcmlkZ2UgKEFNRC04MTMxKScNCiAg ICBjbGFzcyAgICAgID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9IFBDSS1Q Q0kNCmlvYXBpYzFAcGNpMDowOjg6MToJY2xhc3M9MHgwODAwMTAgY2FyZD0w eDAwMDAwMDAwIGNoaXA9MHg3NDUxMTAyMiByZXY9MHgwMSBoZHI9MHgwMA0K ICAgIHZlbmRvciAgICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1E KScNCiAgICBkZXZpY2UgICAgID0gJ1BDSS1YIElPQVBJQyAoQU1ELTgxMzEp Jw0KICAgIGNsYXNzICAgICAgPSBiYXNlIHBlcmlwaGVyYWwNCiAgICBzdWJj bGFzcyAgID0gaW50ZXJydXB0IGNvbnRyb2xsZXINCmhvc3RiMEBwY2kwOjA6 MjQ6MDoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgx MTAwMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAn QWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScNCiAgICBkZXZpY2UgICAg ID0gJ0F0aGxvbjY0L09wdGVyb24vU2VtcHJvbiAoSzggRmFtaWx5KSBIeXBl clRyYW5zcG9ydCBUZWNobm9sb2d5IENvbmZpZ3VyYXRpb24nDQogICAgY2xh c3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQ0K aG9zdGIxQHBjaTA6MDoyNDoxOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4MDAw MDAwMDAgY2hpcD0weDExMDExMDIyIHJldj0weDAwIGhkcj0weDAwDQogICAg dmVuZG9yICAgICA9ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJw0K ICAgIGRldmljZSAgICAgPSAnQXRobG9uNjQvT3B0ZXJvbi9TZW1wcm9uIChL OCBGYW1pbHkpIEFkZHJlc3MgTWFwJw0KICAgIGNsYXNzICAgICAgPSBicmlk Z2UNCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kNCmhvc3RiMkBwY2kwOjA6 MjQ6MjoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgx MTAyMTAyMiByZXY9MHgwMCBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAn QWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScNCiAgICBkZXZpY2UgICAg ID0gJ0F0aGxvbjY0L09wdGVyb24vU2VtcHJvbiAoSzggRmFtaWx5KSBEUkFN IENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1 YmNsYXNzICAgPSBIT1NULVBDSQ0KaG9zdGIzQHBjaTA6MDoyNDozOgljbGFz cz0weDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDExMDMxMDIyIHJl dj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBN aWNybyBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAgPSAnQXRobG9u NjQvT3B0ZXJvbi9TZW1wcm9uIChLOCBGYW1pbHkpIE1pc2NlbGxhbmVvdXMg Q29udHJvbCcNCiAgICBjbGFzcyAgICAgID0gYnJpZGdlDQogICAgc3ViY2xh c3MgICA9IEhPU1QtUENJDQpvaGNpMEBwY2kwOjE6MDowOgljbGFzcz0weDBj MDMxMCBjYXJkPTB4MzIwMjBlMTEgY2hpcD0weDc0NjQxMDIyIHJldj0weDBi IGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBNaWNybyBE ZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAgPSAnVVNCIE9wZW5IQ0kg SG9zdCBDb250cm9sbGVyIChBTUQtODExMSknDQogICAgY2xhc3MgICAgICA9 IHNlcmlhbCBidXMNCiAgICBzdWJjbGFzcyAgID0gVVNCDQpvaGNpMUBwY2kw OjE6MDoxOgljbGFzcz0weDBjMDMxMCBjYXJkPTB4MzIwMjBlMTEgY2hpcD0w eDc0NjQxMDIyIHJldj0weDBiIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9 ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAg ICAgPSAnVVNCIE9wZW5IQ0kgSG9zdCBDb250cm9sbGVyIChBTUQtODExMSkn DQogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMNCiAgICBzdWJjbGFzcyAg ID0gVVNCDQpub25lMUBwY2kwOjE6MjowOgljbGFzcz0weDA4ODAwMCBjYXJk PTB4YjIwNjBlMTEgY2hpcD0weGIyMDMwZTExIHJldj0weDAxIGhkcj0weDAw DQogICAgdmVuZG9yICAgICA9ICdDb21wYXEgQ29tcHV0ZXIgQ29ycCAoTm93 IG93bmVkIGJ5IEhld2xldHQtUGFja2FyZCknDQogICAgZGV2aWNlICAgICA9 ICdJbnRlZ3JhdGVkIExpZ2h0cyBPdXQgUHJvY2Vzc29yIChpTG8pJw0KICAg IGNsYXNzICAgICAgPSBiYXNlIHBlcmlwaGVyYWwNCm5vbmUyQHBjaTA6MToy OjI6CWNsYXNzPTB4MDg4MDAwIGNhcmQ9MHhiMjA2MGUxMSBjaGlwPTB4YjIw NDBlMTEgcmV2PTB4MDEgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0Nv bXBhcSBDb21wdXRlciBDb3JwIChOb3cgb3duZWQgYnkgSGV3bGV0dC1QYWNr YXJkKScNCiAgICBkZXZpY2UgICAgID0gJ0ludGVncmF0ZWQgTGlnaHRzIE91 dCBQcm9jZXNzb3IgKGlMbyknDQogICAgY2xhc3MgICAgICA9IGJhc2UgcGVy aXBoZXJhbA0KdmdhcGNpMEBwY2kwOjE6MzowOgljbGFzcz0weDAzMDAwMCBj YXJkPTB4MDAxZTBlMTEgY2hpcD0weDQ3NTIxMDAyIHJldj0weDI3IGhkcj0w eDAwDQogICAgdmVuZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYy4g LyBBZHZhbmNlZCBNaWNybyBEZXZpY2VzLCBJbmMuJw0KICAgIGRldmljZSAg ICAgPSAnQVRJIE9uLUJvYXJkIFZHQSBmb3IgSFAgUHJvbGlhbnQgMzUwIEcz IChSYWdlIFhMIFBDSSknDQogICAgY2xhc3MgICAgICA9IGRpc3BsYXkNCiAg ICBzdWJjbGFzcyAgID0gVkdBDQpjaXNzMEBwY2kwOjI6NDowOgljbGFzcz0w eDAxMDQwMCBjYXJkPTB4NDA5MTBlMTEgY2hpcD0weDAwNDYwZTExIHJldj0w eDAxIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdDb21wYXEgQ29tcHV0 ZXIgQ29ycCAoTm93IG93bmVkIGJ5IEhld2xldHQtUGFja2FyZCknDQogICAg ZGV2aWNlICAgICA9ICdTbWFydCBBcnJheSA2NHh4LzZpIENvbnRyb2xsZXIn DQogICAgY2xhc3MgICAgICA9IG1hc3Mgc3RvcmFnZQ0KICAgIHN1YmNsYXNz ICAgPSBSQUlEDQpiZ2UwQHBjaTA6Mzo2OjA6CWNsYXNzPTB4MDIwMDAwIGNh cmQ9MHgwMGQwMGUxMSBjaGlwPTB4MTY0ODE0ZTQgcmV2PTB4MTAgaGRyPTB4 MDANCiAgICB2ZW5kb3IgICAgID0gJ0Jyb2FkY29tIENvcnBvcmF0aW9uJw0K ICAgIGRldmljZSAgICAgPSAnTmV0WHRyZW1lIER1YWwgR2lnYWJpdCBBZGFw dGVyIChCQ001NzA0KScNCiAgICBjbGFzcyAgICAgID0gbmV0d29yaw0KICAg IHN1YmNsYXNzICAgPSBldGhlcm5ldA0KYmdlMUBwY2kwOjM6NjoxOgljbGFz cz0weDAyMDAwMCBjYXJkPTB4MDBkMDBlMTEgY2hpcD0weDE2NDgxNGU0IHJl dj0weDEwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdCcm9hZGNvbSBD b3Jwb3JhdGlvbicNCiAgICBkZXZpY2UgICAgID0gJ05ldFh0cmVtZSBEdWFs IEdpZ2FiaXQgQWRhcHRlciAoQkNNNTcwNCknDQogICAgY2xhc3MgICAgICA9 IG5ldHdvcmsNCiAgICBzdWJjbGFzcyAgID0gZXRoZXJuZXQNCnBjaWI1QHBj aTA6NDo5OjA6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlw PTB4NzQ1MDEwMjIgcmV2PTB4MTIgaGRyPTB4MDENCiAgICB2ZW5kb3IgICAg ID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknDQogICAgZGV2aWNl ICAgICA9ICdQQ0ktWCBCcmlkZ2UgKEFNRC04MTMxKScNCiAgICBjbGFzcyAg ICAgID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kNCmlvYXBp YzJAcGNpMDo0Ojk6MToJY2xhc3M9MHgwODAwMTAgY2FyZD0weDAwMDAwMDAw IGNoaXA9MHg3NDUxMTAyMiByZXY9MHgwMSBoZHI9MHgwMA0KICAgIHZlbmRv ciAgICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScNCiAgICBk ZXZpY2UgICAgID0gJ1BDSS1YIElPQVBJQyAoQU1ELTgxMzEpJw0KICAgIGNs YXNzICAgICAgPSBiYXNlIHBlcmlwaGVyYWwNCiAgICBzdWJjbGFzcyAgID0g aW50ZXJydXB0IGNvbnRyb2xsZXINCnBjaWI2QHBjaTA6NDoxMDowOgljbGFz cz0weDA2MDQwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDc0NTAxMDIyIHJl dj0weDEyIGhkcj0weDAxDQogICAgdmVuZG9yICAgICA9ICdBZHZhbmNlZCBN aWNybyBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAgPSAnUENJLVgg QnJpZGdlIChBTUQtODEzMSknDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0K ICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJDQppb2FwaWMzQHBjaTA6NDoxMDox OgljbGFzcz0weDA4MDAxMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDc0NTEx MDIyIHJldj0weDAxIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdBZHZh bmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJw0KICAgIGRldmljZSAgICAgPSAn UENJLVggSU9BUElDIChBTUQtODEzMSknDQogICAgY2xhc3MgICAgICA9IGJh c2UgcGVyaXBoZXJhbA0KICAgIHN1YmNsYXNzICAgPSBpbnRlcnJ1cHQgY29u dHJvbGxlcg0KcmwwQHBjaTA6NTo4OjA6CWNsYXNzPTB4MDIwMDAwIGNhcmQ9 MHhjMTBmMTI1OSBjaGlwPTB4ODEzOTEwZWMgcmV2PTB4MTAgaGRyPTB4MDAN CiAgICB2ZW5kb3IgICAgID0gJ1JlYWx0ZWsgU2VtaWNvbmR1Y3RvcicNCiAg ICBkZXZpY2UgICAgID0gJ1JlYWx0ZWsgUlRMODEzOSBGYW1pbHkgUENJIEZh c3QgRXRoZXJuZXQgTklDIChSVEwtODEzOS84MTM5Qy84MTM5QyknDQogICAg Y2xhc3MgICAgICA9IG5ldHdvcmsNCiAgICBzdWJjbGFzcyAgID0gZXRoZXJu ZXQNCg== --657637799-1648946924-1252426673=:98111-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 17:23:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10FCE1065692 for ; Tue, 8 Sep 2009 17:23:50 +0000 (UTC) (envelope-from prvs=1502ff3bb7=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 95C568FC2C for ; Tue, 8 Sep 2009 17:23:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1252429986; x=1253034786; q=dns/txt; h=Received: Message-ID:From:To:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=RsB4kI1/eFlvDC4zrQAod D7Tstsfk7rt6NDkD70h2JI=; b=Hb8MjCy/j/XPUgRPyiIDzyt48iTsUyaf80XnW FOTduBfc44DGxHXUIY/T2UVdNOArRJYYoxcLp0kWfWBW9d9uXkvq1fod4ZeR5Dc0 ybtpoG+rUm27Y2/i6MtyeFeQlfIOPcAaunZbdkBICnynawvpN7hXcVa1yCOWtw/m EpzJFQ= X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 08 Sep 2009 18:13:06 +0100 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008188392.msg for ; Tue, 08 Sep 2009 18:13:04 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 08 Sep 2009 18:13:04 +0100 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1502ff3bb7=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@freebsd.org Message-ID: <7147C6D9FE26411197548D67E5025D75@multiplay.co.uk> From: "Steven Hartland" To: "stuart cur" , References: Date: Tue, 8 Sep 2009 18:13:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Subject: Re: 8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 17:23:50 -0000 I suspect its the same reason for issues with had with the subjects: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade kern/134658: [bce] bce driver fails on PowerEdge m610 blade. Quote: "David Christensen" I've enquired about this recently but havent seen a response as yet. Regards Steve > Sorry, this is the 5709S and I haven't had an opportunity to > implement this PHY yet. Unfortunately it's more than just a > change to miidevs since the SerDes is actually an IEEE clause > 45 compliant device (instead of the more common Clause 22 > devices found in 1GbE controllers). The registers are > diffrerent so the effort is more substantial. No estimate > yet on when I can get to it. ----- Original Message ----- From: "stuart cur" To: Sent: Tuesday, September 08, 2009 5:32 PM Subject: 8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64 > In 8.0-B4 for amd64, bge does not recognize that there is an active > ethernet connection on bge0. Switching the cable to bge1 works correctly. > > This seems to be the same issue as reported on July 21 by Oyvind Rakvag, > but I saw no response to that report. > > Attached are the dmesg.boot, /var/log/messages, and output of pciconf -lv > from the very first boot. > > stu > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 17:52:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 090501065672 for ; Tue, 8 Sep 2009 17:52:20 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id C16468FC14 for ; Tue, 8 Sep 2009 17:52:19 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Ml4ra-0004pK-VK for freebsd-current@freebsd.org; Tue, 08 Sep 2009 10:52:18 -0700 Message-ID: <25351048.post@talk.nabble.com> Date: Tue, 8 Sep 2009 10:52:18 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org In-Reply-To: <20090905150537.GA78983@cuba.calyx.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <20090905150537.GA78983@cuba.calyx.nl> Subject: Re: v9.0 treating me very well X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 17:52:20 -0000 Bill Squire {billsf} wrote: > > > Hi current-users, > > Surely we want v8.0 to work right, but many of the complaints I see have > already been fixed in v9.0 Its not my call (no way will use a Generic > kernel) > but please consider your configurations carefully. If you want to do both > you > need a separate base install and a /var. I put multiple base-installs on > flash ROM drives. Be sure they don't 'require MSDOSFS' to work, but be > prepared > to put it back and take it back. (see the ports or emulate, also in the > ports) > Hint: 2GiB drives made by a manufacturer I've taken many larger ones back > so > I refuse to advertise then, particularly since they have discontinued that > model. Hint: Its a place close to namesake of this server I'm using. > > PS: The low-cost (and best sounding) USB chips work out of the box, now on > v9.0 so if you have these try it out. I use balanced audio and have really > decent speakers -- You know if you read my previous posts. > > Bill Squire > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > Hello.. Maybe I should not reply, but curiosity got the better of me... What were you trying to communicate? What is the main thought beneath phrasing? >Surely we want v8.0 to work right, but many of the complaints I see have >already been fixed in v9.0 This is why we have MFC, and CURRENT in managed in somehow close state to STABLE prior to RELEASE. >Its not my call (no way will use a Generic kernel) ? (I fail to see connection.) >I put multiple base-installs on >flash ROM drives. You see flash drives as EEPROM, ok but I again fail to see connection. >PS: The low-cost (and best sounding) USB chips work out of the box, now on >v9.0 so if you have these try it out. Something changed after branching 8-STABLE from 8-CURRENT? I doubt it. Ariff work is nonetheless excellent. >I refuse to advertise then, particularly since they have discontinued that >model. Hint: Its a place close to namesake of this server I'm using. Why such choose of words? You want to recommend something or rather not? >I use balanced audio and have really >decent speakers -- You know if you read my previous posts It's nice to have nice speakers. -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/v9.0-treating-me-very-well-tp25309347p25351048.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 18:00:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C91611065698 for ; Tue, 8 Sep 2009 18:00:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC0A8FC18 for ; Tue, 8 Sep 2009 18:00:15 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0E78246B45; Tue, 8 Sep 2009 14:00:15 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 5E4418A020; Tue, 8 Sep 2009 14:00:14 -0400 (EDT) From: John Baldwin To: Nick Hilliard Date: Tue, 8 Sep 2009 13:25:12 -0400 User-Agent: KMail/1.9.7 References: <4A9BF23F.6070801@netability.ie> <200909011002.59592.jhb@freebsd.org> <4AA52BE4.3070708@netability.ie> In-Reply-To: <4AA52BE4.3070708@netability.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909081325.13149.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 08 Sep 2009 14:00:14 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 18:00:15 -0000 On Monday 07 September 2009 11:51:00 am Nick Hilliard wrote: > On 01/09/2009 15:02, John Baldwin wrote: > > Hmm, so an idea I had just now.. can you grab a dump of the PCI config space > > for the disk controller in the MCFG vs non-MCFG cases? That is, find the > > device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and then > > run this command under both configurations and save the output: > > > > pciconf -r pci0:0:30:0 0:0xfc > > Ok, got this working on the beta4 livefs. If hw.pci.mcfg=0, then all disks > are detected correctly. > > I've attached the pciconf output for each case. So as with the other pciconf output I got, it seems that it is reading the registers ok in both cases. Can you add some printfs to the ata driver to figure out when it starts behaving differently (e.g. reading a value from a register) between the mcfg=0 and mcfg=1 cases on 8? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 18:45:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47E1E1065672 for ; Tue, 8 Sep 2009 18:45:52 +0000 (UTC) (envelope-from billsf@cuba.calyx.nl) Received: from cuba.calyx.nl (cuba.calyx.nl [213.130.163.36]) by mx1.freebsd.org (Postfix) with ESMTP id D0B898FC0A for ; Tue, 8 Sep 2009 18:45:51 +0000 (UTC) Received: by cuba.calyx.nl (Postfix, from userid 1000) id 1641C197BE32; Tue, 8 Sep 2009 20:45:50 +0200 (CEST) Date: Tue, 8 Sep 2009 20:45:50 +0200 From: Bill Squire {billsf} To: Jakub Lach Message-ID: <20090908184550.GA64091@cuba.calyx.nl> References: <20090905150537.GA78983@cuba.calyx.nl> <25351048.post@talk.nabble.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25351048.post@talk.nabble.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: v9.0 treating me very well X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 18:45:52 -0000 On Tue, Sep 08, 2009 at 10:52:18AM -0700, Jakub Lach wrote: > > > > Bill Squire {billsf} wrote: > > > > > > Hi current-users, > > > > Surely we want v8.0 to work right, but many of the complaints I see have > > v9.0 so if you have these try it out. I use balanced audio and have really > > decent speakers -- You know if you read my previous posts. > > > > Bill Squire > > > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > > Hello.. > > Maybe I should not reply, but curiosity got the better of me... > > What were you trying to communicate? What is the main thought > beneath phrasing? Except for a stop in /cddl/ which involves a 'removed from source header file' 9.0 builds. Using this list I know how to move on. As far as the stop -- ignore it! Everything else seems to __build__ and all that I can test seems to work. > >Surely we want v8.0 to work right, but many of the complaints I see have > >already been fixed in v9.0 > This is why we have MFC, and CURRENT in managed in somehow close state > to STABLE prior to RELEASE. Its not mine either but a release is important but I prefer the 'bleading edge'. Yes, I have some gripes but not a big deal. Silly obvious little things. If you have ports -- rebuild as many as you care about -- Sometimes, usually that is, you can cheat by putting a new .so. in /usr/lib/compat and call it the old lib. I said usually works and ignore conflict warnings. BTW: How do I use the 'new' loader. I use last week's and it works fine. Also almost all modules needed are loaded automatically by acript that used kldload since I believe the kernel would otherwise panic. (It does on 7.2) when you build a minimal kernel and pre-load all the modules. Let /etc/rc automatically load as many as you can. > >Its not my call (no way will use a Generic kernel) > ? (I fail to see connection.) > > >I put multiple base-installs on > >flash ROM drives. That is so I can allways go back. I test the rebuilding every week and "don't trust" a loader with a "buffer overflow" bug. Also I've grown tolike my way of 'loading'and have received no complaints from "commercial users". Its just easier because I knowmy own way better. Yes, the last update broke many ports. Updating helps in most cases. Ports aren't really my thing because people will say I have a bad Makefile nomatter how good it is. > You see flash drives as EEPROM, ok but I again > fail to see connection. > >PS: The low-cost (and best sounding) USB chips work out of the box, now on > >v9.0 so if you have these try it out. Yes, but get the datasheet of the chip and use the proper values. If you have professional audio you should build a single ended to differential output stage. If you don't understand this, just try one,particularly if it is a C-Media device. They work __better__ than any "HiFi" solution I've spent money on only to get a Windows driver and have to get the specs and build my own driver only to find out it won't handle even 16bits worth of audio. The hda chips aren't bad for motion pictures. (Hint: Dolby doesn't enhance your music anymore -- It does make violence much more realistic -- (warning).) > Something changed after branching 8-STABLE from 8-CURRENT? I doubt it. > Ariff work is nonetheless excellent. > > >I refuse to advertise then, particularly since they have discontinued that > >model. Hint: Its a place close to namesake of this server I'm using. > > Why such choose of words? You want to recommend something > or rather not? The only reccomentation is C-Media blows Intel/Realtech out of the water if music is important for you. PC speakers work with any sound card. > >I use balanced audio and have really > >decent speakers -- You know if you read my previous posts > > It's nice to have nice speakers. That's the secret for the most part, but I'll never use commercial software for audio again. This USB stuff sounds great. > > -best regards, > Jakub Lach Good luck with your sound and use of FreeBSD to acheive it. Don't use "windows" (stolen from X-Windows) can I not reccomend some system? > -- > View this message in context: http://www.nabble.com/v9.0-treating-me-very-well-tp25309347p25351048.html > Sent from the freebsd-current mailing list archive at Nabble.com. If its audiophile, that's not proven -- IN fact disproved scientificaly. Its like arguing someone's religion -- You get nowhere. True 'HiFi' on "windows" is with a HEAVILY buffered device -- still screws up your base. Bill PS: If someone wants it spelt out how-to is this the right forum? From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 19:14:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10D401065670; Tue, 8 Sep 2009 19:14:03 +0000 (UTC) (envelope-from boogie@lazybytes.org) Received: from mail.lazybytes.org (odin.rinet.ru [195.54.209.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7AFF38FC1C; Tue, 8 Sep 2009 19:14:02 +0000 (UTC) Received: from [192.168.13.148] (broadband-77-37-224-248.nationalcablenetworks.ru [77.37.224.248]) by mail.lazybytes.org (Postfix) with ESMTPSA id 915D814035C9; Tue, 8 Sep 2009 23:11:59 +0400 (MSD) Message-ID: <4AA6ACF1.3040501@lazybytes.org> Date: Tue, 08 Sep 2009 23:13:53 +0400 From: Sergey Vinogradov User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alex Dupre References: <4AA65ABE.4000207@lazybytes.org> <4AA668E0.1010305@FreeBSD.org> In-Reply-To: <4AA668E0.1010305@FreeBSD.org> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://lazybytes.org/people/boogie/pubkey.gpg Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFFB546E5C1F72598F999A435" Cc: freebsd-current@freebsd.org Subject: Re: ath(4) Atheros AR9285 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 19:14:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFFB546E5C1F72598F999A435 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex Dupre wrote: > Sergey Vinogradov ha scritto: >> Just wanted to know, if there will be any Atheros AR9285 support in >> ath(4) driver in nearest future? I've got my ASUS Eee 1005HA with one = of >> these wireless adapters, and it doesn't seem to be working. >=20 > I think it should work with FreeBSD 8.0. >=20 Well, despite the fact that "device ath", and all related stuff are included in GENERIC kernel in 8.0-BETA4, I have no ath0 interface. "dmesg | grep -i ath" gives nothing (well, as a matter of fact it gives "alc0: ... ", but alc0 doesn't work either, link handling is broken as I understand). Is there something I'm doing wrong, or something I can do to help the development? :) --=20 wbr, Boo --------------enigFFB546E5C1F72598F999A435 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.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqmrPcACgkQCt8hfbw1GpYuUwCgiIyEFOPwcW0hi70rM8YN0Fdd ia0AnAv7ZgvG2VDbweaYhMjGkDGZ1UwZ =NcDU -----END PGP SIGNATURE----- --------------enigFFB546E5C1F72598F999A435-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 19:42:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A104B106566B; Tue, 8 Sep 2009 19:42:15 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id D15408FC26; Tue, 8 Sep 2009 19:42:14 +0000 (UTC) Received: by fxm6 with SMTP id 6so2776705fxm.43 for ; Tue, 08 Sep 2009 12:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pTcygApz4GghzmsA50ty6FoAdXqyZkvfEt+FvpvFBv0=; b=vmEb0cvjKi3ZkqF6dz7UnezD4adLUW8XO8MYraMqQpVro6Lq1t9+zvjW3nJYLyU7SN FnGHBKnOv3aW3ZVi20sA2blftG09kZoI45suvLtXCWo3ZzsbPYCRkdJDtUDx0VrNdRtq yL1pCPm4gRnHssPj4wy4yJlUn4cfTK6XQKRAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qU8Iz8Kk3xF1Y3/PAyBqBle1mS38iaSH/T/mrp1c6KXdgVYBng3pviwqe8LtENqzHG kM4eUOGfCetInDdF+P11IrUA/tRPqypGn19HXgpusqg/jjP55hP/dIAOxx5soIu63v8w 18HKBpLhRWU7/QKRfxyIzZQfMiaCTklYQfv7s= MIME-Version: 1.0 Received: by 10.204.25.152 with SMTP id z24mr13514406bkb.44.1252438933617; Tue, 08 Sep 2009 12:42:13 -0700 (PDT) In-Reply-To: <3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com> References: <20090908091114.GH47688@deviant.kiev.zoral.com.ua> <3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com> Date: Tue, 8 Sep 2009 23:42:13 +0400 Message-ID: From: pluknet To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-emulation@freebsd.org, FreeBSD Current Subject: Re: acquiring duplicate lock of same type: "ftlk" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 19:42:15 -0000 2009/9/8 Attilio Rao : > 2009/9/8 Kostik Belousov : >> On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote: >>> lock order reversal: >>> =A01st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:= 497 >>> =A02nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292 >>> KDB: stack backtrace: >>> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...) >>> at db_trace_self_wrapper+0x26 >>> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at >>> kdb_backtrace+0x29 >>> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at >>> _witness_debugger+0x25 >>> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at witness_checkorder= +0x839 >>> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85 >>> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f >>> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a >>> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at pfs_loo= kup+0x3dd >>> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...) >>> at VOP_CACHEDLOOKUP_APV+0xc5 >>> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at >>> vfs_cache_lookup+0xd6 >>> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at >>> VOP_LOOKUP_APV+0xe5 >>> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b >>> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f >>> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at kern_= alternate >>> _path+0x1cd >>> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at >>> linux_emul_convpath+0x3c >>> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at linux_o= pen+0x41 >>> syscall(e8214d38) at syscall+0x2b4 >>> Xint0x80_syscall() at Xint0x80_syscall+0x20 >>> --- syscall (5, Linux ELF, linux_open), eip =3D 0x2889115e, esp =3D >>> 0xbfbfbd1c, ebp =3D 0xbfbfbd6c --- >>> acquiring duplicate lock of same type: "ftlk" >>> [...] >> >> The second LOR actually exposes the right order. It would be interesting >> to look up the point where the other order is established. > > You would manually patch the witness static table with this order and > the opposite will show, when happening. > I've patched witness order table, and still no opposite case, nor any pseudofs related LORs at all. { "pseudofs", &lock_class_lockmgr }, { "allproc", &lock_class_sx }, { NULL, NULL }, Seen orders with pseudofs: "ufs","pseudofs" "pseudofs","allproc" "pseudofs","process lock" "pseudofs","vnode interlock" "pseudofs","struct mount mtx" "pseudofs","UMA zone" "pseudofs","sleep mtxpool" "pseudofs","Name Cache" "pseudofs","vnode_free_list" "pseudofs","pfs_node" "pseudofs","pfs_vncache" Something else? --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 19:48:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E84991065670; Tue, 8 Sep 2009 19:48:38 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id 4C44E8FC17; Tue, 8 Sep 2009 19:48:38 +0000 (UTC) Received: by fxm6 with SMTP id 6so2780548fxm.43 for ; Tue, 08 Sep 2009 12:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=FxF6iyIz3Yaxlr/2a9JYNeD4/t7osvL4m2UChl8R1Zo=; b=lMjqDNz0TPHMpevZ9wm+bMnRhVAGLs4LWoi53IrBpch/DAOaJAVcmC/IN8TfRYmOsO 5TGiDizRI0nXeHoj+ucgtLG0es+NpJTSoCcNjGeutIke3t1PViq0EBD0SxDld93GFR8G PfLpzhUE++hbK4YCvRzrBedqh0SLE1VVK7XDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=JeapOVkfzynClegJqSCCfcM5bU/fXxqDu4gg3JU0v0rbEcPoR8vZXyl9xHXLG9ulH5 yc93lK8/ajVPx3a9OnfUzkJoSVE6lMM5bQqPvSB+6WCpaOI8tJzDReETZV1QrvHPGzzI WOg5z2CctnJwrPrpt/KWQCu+f5WYVbKeMH4Cw= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.58.139 with SMTP id g11mr6185875fah.43.1252439317464; Tue, 08 Sep 2009 12:48:37 -0700 (PDT) In-Reply-To: References: <20090908091114.GH47688@deviant.kiev.zoral.com.ua> <3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com> Date: Tue, 8 Sep 2009 21:48:37 +0200 X-Google-Sender-Auth: 810d6bb753d3e452 Message-ID: <3bbf2fe10909081248w3a09c9a8ge3b6fa9de8b2d3e9@mail.gmail.com> From: Attilio Rao To: pluknet Content-Type: text/plain; charset=UTF-8 Cc: Kostik Belousov , freebsd-emulation@freebsd.org, FreeBSD Current Subject: Re: acquiring duplicate lock of same type: "ftlk" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 19:48:39 -0000 2009/9/8 pluknet : > 2009/9/8 Attilio Rao : >> 2009/9/8 Kostik Belousov : >>> On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote: >>>> lock order reversal: >>>> 1st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.c:497 >>>> 2nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:292 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,...) >>>> at db_trace_self_wrapper+0x26 >>>> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at >>>> kdb_backtrace+0x29 >>>> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at >>>> _witness_debugger+0x25 >>>> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at witness_checkorder+0x839 >>>> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85 >>>> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f >>>> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a >>>> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at pfs_lookup+0x3dd >>>> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...) >>>> at VOP_CACHEDLOOKUP_APV+0xc5 >>>> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at >>>> vfs_cache_lookup+0xd6 >>>> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at >>>> VOP_LOOKUP_APV+0xe5 >>>> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b >>>> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f >>>> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at kern_alternate >>>> _path+0x1cd >>>> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at >>>> linux_emul_convpath+0x3c >>>> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at linux_open+0x41 >>>> syscall(e8214d38) at syscall+0x2b4 >>>> Xint0x80_syscall() at Xint0x80_syscall+0x20 >>>> --- syscall (5, Linux ELF, linux_open), eip = 0x2889115e, esp = >>>> 0xbfbfbd1c, ebp = 0xbfbfbd6c --- >>>> acquiring duplicate lock of same type: "ftlk" >>>> [...] >>> >>> The second LOR actually exposes the right order. It would be interesting >>> to look up the point where the other order is established. >> >> You would manually patch the witness static table with this order and >> the opposite will show, when happening. >> > > I've patched witness order table, and still no opposite case, > nor any pseudofs related LORs at all. > { "pseudofs", &lock_class_lockmgr }, > { "allproc", &lock_class_sx }, > { NULL, NULL }, > > Seen orders with pseudofs: > "ufs","pseudofs" > "pseudofs","allproc" > "pseudofs","process lock" > "pseudofs","vnode interlock" > "pseudofs","struct mount mtx" > "pseudofs","UMA zone" > "pseudofs","sleep mtxpool" > "pseudofs","Name Cache" > "pseudofs","vnode_free_list" > "pseudofs","pfs_node" > "pseudofs","pfs_vncache" > > Something else? Probabilly it just takes time. You should try to recreate conditions you did before to get this LOR. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 19:54:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2B9C1065679; Tue, 8 Sep 2009 19:54:47 +0000 (UTC) (envelope-from tlott@gamesnet.de) Received: from spirit.gamesnet.de (spirit.gamesnet.de [87.230.101.86]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB878FC20; Tue, 8 Sep 2009 19:54:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by spirit.gamesnet.de (Postfix) with ESMTP id D35EC303723; Tue, 8 Sep 2009 21:44:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at gamesnet.de Received: from spirit.gamesnet.de ([127.0.0.1]) by localhost (spirit.gamesnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MepViZS1NZEi; Tue, 8 Sep 2009 21:44:05 +0200 (CEST) Received: from sub.han.vpn.gamesnet.de (sub.han.vpn.gamesnet.de [192.168.1.101]) by spirit.gamesnet.de (Postfix) with ESMTPSA id 4E4F1303718; Tue, 8 Sep 2009 21:44:05 +0200 (CEST) Date: Tue, 8 Sep 2009 21:44:02 +0200 From: Tobias Lott To: freebsd-current@freebsd.org Message-ID: <20090908214402.43009577@sub.han.vpn.gamesnet.de> In-Reply-To: <200909011005.18200.jhb@freebsd.org> References: <200909011005.18200.jhb@freebsd.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.6; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: gausus@gausus.net Subject: Re: Problems with ZFS on AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 19:54:48 -0000 On Tue, 1 Sep 2009 10:05:17 -0400 John Baldwin wrote: > On Tuesday 01 September 2009 9:24:24 am Maciej Jan Broniarz wrote: > > Hello, > > > > I have installed Freebsd8-beta3 on a Phenom II Quad Core with 8 gb > > ram. When I create a zfs volume all works fine. Still, when I > > reboot the system it doesn't come up. It hangs with the following > > error: > > > > http://img525.imageshack.us/img525/3832/freebsd8zfs.jpg > > > > What might be the problem? > > It's probably a NULL pointer dereference, but we would need a stack > trace to investigate this further. > My Problem seems to be related. Updating a Machine to 8.0-BETA4 #3 caused same, its a i386 System using gpt with zfs-only volumes beside swap. http://i25.tinypic.com/343p0s0.jpg I'll try to see if I can get a stack trace -- Tobias Lott From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 20:01:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E90F106566B; Tue, 8 Sep 2009 20:01:59 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id E69148FC13; Tue, 8 Sep 2009 20:01:58 +0000 (UTC) Received: from [192.168.1.4] (adsl-146-128-114.bna.bellsouth.net [70.146.128.114]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n88K1sFP045971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Sep 2009 16:01:56 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Alexander Motin In-Reply-To: <4AA68C8A.4060405@FreeBSD.org> References: <1252225381.00160049.1252212601@10.7.7.3> <4AA68C8A.4060405@FreeBSD.org> Content-Type: text/plain Organization: FreeBSD Date: Tue, 08 Sep 2009 15:01:49 -0500 Message-Id: <1252440109.85394.2430.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Harald Schmalzbauer , freebsd-current@freebsd.org Subject: Re: Funding ODD support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 20:01:59 -0000 On Tue, 2009-09-08 at 19:55 +0300, Alexander Motin wrote: > Harald Schmalzbauer wrote: > > I'm looking for somebody who has time and knowledge to fix ODD support > > in FreeBSD. > > I'm willing to sponsor a decent ammount. > > My problem is that I can't use FreeBSD for any task in which CD or DVD > > is involved. > > What I want is read/write support for any ATAPI/S-ATA ODD regarding > > ISO9660 and audio. Of course I'd love to have UDF support also, but for > > the beginning I'd be glad if FreeBSD could boot with an inserted audio > > CD. This has been a problem for more than two years now, and disabling > > DMA support for ata devices isn't a satisfying solution. > > > > So if you think ypu can fix this and make growisofs and cdrtools working > > with ATAPI and SATA devices, please contact me. > > If we have working ODD support in 8.0-release I'll donate 100 extra bucks. > > Funding is good, but could you first once more repeat what is your > problem? Which controller do you use? Which drive? Which disks and which > applications? Have you tried to use different controllers, drives, > disks, applications? I am asking because there quite a lot of people > successfully using ODD on FreeBSD. FWIW, some of the recent changes do seem to have broken things a bit for me... But I can't quite put my finger on where the breakage is. Some apps seem to work, depending on media, while other don't (that used to). For example I can burn a data DVD using tkdvd, but not brasero. brasero does seem to be able to burn data cds, though I'm getting horrible throughput which I don't understand. (I seem to max at about 4x writing cds on a 48x cd burner, IIRC). I haven't found any tool that is able to write a DL dvd, currently. robert. -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 20:03:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3243B106566B for ; Tue, 8 Sep 2009 20:03:40 +0000 (UTC) (envelope-from boogie@lazybytes.org) Received: from mail.lazybytes.org (odin.rinet.ru [195.54.209.3]) by mx1.freebsd.org (Postfix) with ESMTP id C23148FC16 for ; Tue, 8 Sep 2009 20:03:39 +0000 (UTC) Received: from [192.168.13.148] (broadband-77-37-224-248.nationalcablenetworks.ru [77.37.224.248]) by mail.lazybytes.org (Postfix) with ESMTPSA id D4E3114035C9; Wed, 9 Sep 2009 00:01:36 +0400 (MSD) Message-ID: <4AA6B894.5090904@lazybytes.org> Date: Wed, 09 Sep 2009 00:03:32 +0400 From: Sergey Vinogradov User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: herbs References: <4AA65ABE.4000207@lazybytes.org> <20090908195516.GA8398@greencat.langhans.com.pl> In-Reply-To: <20090908195516.GA8398@greencat.langhans.com.pl> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://lazybytes.org/people/boogie/pubkey.gpg Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE8BD6177E190EE06D3197356" Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: ath(4) Atheros AR9285 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 20:03:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE8BD6177E190EE06D3197356 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable herbs wrote: > I had serious problems using the port hal in combination with an Athero= s > WiFi card. Maybe disable hal and try again? >=20 > Cheers > herb langhans > =20 > On Tue, Sep 08, 2009 at 05:23:10PM +0400, Sergey Vinogradov wrote: >> Hi, >> Just wanted to know, if there will be any Atheros AR9285 support in >> ath(4) driver in nearest future? I've got my ASUS Eee 1005HA with one = of >> these wireless adapters, and it doesn't seem to be working. >> >> --=20 >> wbr, >> Boo >> >=20 >=20 >=20 It's a fresh install, nothing but base system and GENERIC kernel installe= d. --=20 wbr, Boo --------------enigE8BD6177E190EE06D3197356 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.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqmuJkACgkQCt8hfbw1GpZf+wCePbwODfj5DKWqKDR2Nwb7Cd8S zkkAnjmrNQX/hsfqgCXRFP5TA/lKwDGQ =OhpA -----END PGP SIGNATURE----- --------------enigE8BD6177E190EE06D3197356-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 20:08:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49240106566C for ; Tue, 8 Sep 2009 20:08:59 +0000 (UTC) (envelope-from herbs@langhans.com.pl) Received: from langhans.com.pl (host-194126238033.net-serwis.pl [194.126.238.33]) by mx1.freebsd.org (Postfix) with ESMTP id 0943D8FC0A for ; Tue, 8 Sep 2009 20:08:58 +0000 (UTC) Received: by langhans.com.pl (Postfix, from userid 1000) id CE39C1B9B37; Tue, 8 Sep 2009 21:55:16 +0200 (CEST) Date: Tue, 8 Sep 2009 21:55:16 +0200 From: herbs To: Sergey Vinogradov , freebsd-current@freebsd.org, freebsd-questions@freebsd.org Message-ID: <20090908195516.GA8398@greencat.langhans.com.pl> References: <4AA65ABE.4000207@lazybytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AA65ABE.4000207@lazybytes.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: ath(4) Atheros AR9285 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 20:08:59 -0000 I had serious problems using the port hal in combination with an Atheros WiFi card. Maybe disable hal and try again? Cheers herb langhans On Tue, Sep 08, 2009 at 05:23:10PM +0400, Sergey Vinogradov wrote: > Hi, > Just wanted to know, if there will be any Atheros AR9285 support in > ath(4) driver in nearest future? I've got my ASUS Eee 1005HA with one of > these wireless adapters, and it doesn't seem to be working. > > -- > wbr, > Boo > -- ******* Herbert Langhans, Warschau ******* Sprachtraining Langhans ******* http://www.langhans.com.pl ******* herbert at langhans.com.pl ******* NIP 526-229-61-51 ******* Regon 014911759 ******* Tel. 603 341 441 From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 20:25:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B218E106566B for ; Tue, 8 Sep 2009 20:25:55 +0000 (UTC) (envelope-from jfb@mr-paradox.net) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [IPv6:2001:470:b:28:f::1]) by mx1.freebsd.org (Postfix) with ESMTP id 84BB58FC12 for ; Tue, 8 Sep 2009 20:25:55 +0000 (UTC) Received: by vexbert.mr-paradox.net (Postfix, from userid 16139) id 51F3D84562; Tue, 8 Sep 2009 16:25:55 -0400 (EDT) Date: Tue, 8 Sep 2009 16:25:53 -0400 From: Jeff Blank To: freebsd-current@freebsd.org Message-ID: <20090908202553.GA1368@mr-happy.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e Subject: 8.0-BETA4 panic: ffs_sync: rofs mod X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 20:25:55 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, My 8.0-BETA4/amd64 installation panicked when I attempted to create a file on zvol-backed UFS. This installation is otherwise UFS-free, ZFS v13 w/gptzfsboot method linked from wiki, single zpool mirror (ad{4,6}p3). # zfs create -V 18G z0/ufs0 # newfs -U -L oldbender /dev/zvol/z0/ufs0 # mount /dev/ufs/oldbender /old # touch /old/foo The system usually panics immediately, but once it waited a few seconds to do so, and I saw the file had been created. The file was not there upon reboot in all cases, and the filesystem was considered clean by fsck. Should I expect this to work? And/or is it a known issue? (Didn't find any similar-looking problems by googling or browsing list archives.) Please let me know if I need to provide more details. Jeff --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="panic.txt" console output: fs = /old panic: ffs_sync: rofs mod cpuid = 1 KDB: enter: panic [thread pid 19 tid 100049 ] Stopped at kdb_enter+0x3d: movq $0,0x68d1e0(%rip) db> bt Tracing pid 19 tid 100049 td 0xffffff0002ad7000 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b ffs_sync() at ffs_sync+0x544 sync_fsync() at sync_fsync+0x13a sync_vnode() at sync_vnode+0x157 sched_sync() at sched_sync+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074cd7d30, rbp = 0 --- db> kgdb upon reboot: # kgdb /boot/kernel/kernel /var/crash/vmcore.1 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: fs = /old panic: ffs_sync: rofs mod cpuid = 1 KDB: enter: panic Physical memory: 4076 MB Dumping 1396 MB: 1381 1365 1349 1333 1317 1301 1285 1269 1253 1237 1221 1205 1189 1173 1157 1141 1125 1109 1093 1077 1061 1045 1029 1013 997 981 965 949 933 917 901 885 869 853 837 821 805 789 773 757 741 725 709 693 677 661 645 629 613 597 581 565 549 533 517 501 485 469 453 437 421 405 389 373 357 341 325 309 293 277 261 245 229 213 197 181 165 149 133 117 101 85 69 53 37 21 5 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/radeon.ko...Reading symbols from /boot/kernel/radeon.ko.symbols...done. done. Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff801d90fc in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801d9431 in db_command (last_cmdp=0xffffffff80be9720, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801d9680 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff801db659 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff805b2025 in kdb_trap (type=3, code=0, tf=0xffffff8074cd7880) at /usr/src/sys/kern/subr_kdb.c:535 #6 0xffffffff80864af1 in trap (frame=0xffffff8074cd7880) at /usr/src/sys/amd64/amd64/trap.c:613 #7 0xffffffff8084a7d3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #8 0xffffffff805b21fd in kdb_enter (why=0xffffffff8095cf97 "panic", msg=0xa
) at cpufunc.h:63 #9 0xffffffff8058298b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:562 #10 0xffffffff807a8cc4 in ffs_sync (mp=Variable "mp" is not available. ) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1261 #11 0xffffffff80615cda in sync_fsync (ap=Variable "ap" is not available. ) at /usr/src/sys/kern/vfs_subr.c:3433 #12 0xffffffff80614197 in sync_vnode (slp=0xffffff00029f14a8, bo=0xffffff8074cd7bf0, td=0xffffff0002ad7000) at vnode_if.h:549 #13 0xffffffff80614401 in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1799 #14 0xffffffff8055a73a in fork_exit (callout=0xffffffff80614230 , arg=0x0, frame=0xffffff8074cd7c80) at /usr/src/sys/kern/kern_fork.c:838 #15 0xffffffff8084acae in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:561 #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000001 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x00000000012d7000 in ?? () #41 0x0000000000000000 in ?? () #42 0xffffffff80c25840 in affinity () #43 0xffffffff80c25840 in affinity () #44 0xffffff0002802390 in ?? () #45 0xffffff8074cd74e0 in ?? () #46 0xffffff8074cd7498 in ?? () #47 0xffffff0002ad7000 in ?? () #48 0xffffffff805a57e0 in sched_switch (td=0x0, newtd=0xffffffff80614230, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1858 Previous frame inner to this frame (corrupt stack?) (kgdb) --J2SCkAp4GZ/dPZZf-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 20:37:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46CCB106566B for ; Tue, 8 Sep 2009 20:37:09 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.freebsd.org (Postfix) with ESMTP id 922A68FC13 for ; Tue, 8 Sep 2009 20:37:08 +0000 (UTC) Received: by mail.0x20.net (Postfix, from userid 1002) id DD8D63A61E; Tue, 8 Sep 2009 22:17:13 +0200 (CEST) Date: Tue, 8 Sep 2009 22:17:13 +0200 From: Lars Engels To: current@freebsd.org Message-ID: <20090908201713.GD41185@e.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="69pVuxX8awAiJ7fD" Content-Disposition: inline X-Editor: VIM - Vi IMproved 7.2 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: CFH: fix multimedia/pwcbsd with usb2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 20:37:09 -0000 --69pVuxX8awAiJ7fD Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, could someone with some more USB and C knowledge than me take a look at multimedia/pwcbsd? I'd really like to get the port fixed before the ports freeze starts. Here is the compile output: In file included from pwc.c:27: pwc.h:47:31: error: dev/usb/usb_mfunc.h: No such file or directory pwc.h:48:31: error: dev/usb/usb_error.h: No such file or directory In file included from pwc.h:50, from pwc.c:27: @/dev/usb/usb_core.h:121: error: field 'timeout_handle' has incomplete type @/dev/usb/usb_core.h:140: error: expected specifier-qualifier-list before '= usb_callback_t' pwc.h:52:32: error: dev/usb/usb_lookup.h: No such file or directory In file included from pwc.h:55, from pwc.c:27: @/dev/usb/usb_request.h:32: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_clear_hub_feature' @/dev/usb/usb_request.h:34: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_clear_port_feature' @/dev/usb/usb_request.h:36: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_get_alt_interface_no' @/dev/usb/usb_request.h:39: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_get_config' @/dev/usb/usb_request.h:41: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_get_descriptor_ptr' @/dev/usb/usb_request.h:43: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_get_config_desc' @/dev/usb/usb_request.h:45: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_get_config_desc_full' @/dev/usb/usb_request.h:48: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_get_desc' @/dev/usb/usb_request.h:52: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_get_device_desc' @/dev/usb/usb_request.h:54: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_get_device_status' @/dev/usb/usb_request.h:56: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_get_hub_descriptor' @/dev/usb/usb_request.h:59: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_get_hub_status' @/dev/usb/usb_request.h:61: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_get_port_status' @/dev/usb/usb_request.h:63: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_reset_port' @/dev/usb/usb_request.h:65: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_set_address' @/dev/usb/usb_request.h:67: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_set_hub_feature' @/dev/usb/usb_request.h:69: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_set_port_feature' @/dev/usb/usb_request.h:71: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_re_enumerate' @/dev/usb/usb_request.h:72: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_clear_device_feature' @/dev/usb/usb_request.h:73: error: expected '=3D', ',', ';', 'asm' or '__at= tribute__' before 'usbd_req_set_device_feature' pwc.c:62: error: array type has incomplete element type pwc.c:63: error: array index in non-array initializer pwc.c:63: error: (near initialization for 'pwc_config') pwc.c:64: error: field name not in record or union initializer pwc.c:64: error: (near initialization for 'pwc_config') pwc.c:65: error: field name not in record or union initializer pwc.c:65: error: (near initialization for 'pwc_config') pwc.c:66: error: field name not in record or union initializer pwc.c:66: error: (near initialization for 'pwc_config') pwc.c:67: error: field name not in record or union initializer pwc.c:67: error: (near initialization for 'pwc_config') pwc.c:68: error: field name not in record or union initializer pwc.c:68: error: (near initialization for 'pwc_config') pwc.c:69: error: field name not in record or union initializer pwc.c:69: error: (near initialization for 'pwc_config') pwc.c:69: error: field name not in record or union initializer pwc.c:69: error: (near initialization for 'pwc_config') pwc.c:70: error: field name not in record or union initializer pwc.c:70: error: (near initialization for 'pwc_config') pwc.c:73: error: array index in non-array initializer pwc.c:73: error: (near initialization for 'pwc_config') pwc.c:74: error: field name not in record or union initializer pwc.c:74: error: (near initialization for 'pwc_config') pwc.c:75: error: field name not in record or union initializer pwc.c:75: error: (near initialization for 'pwc_config') pwc.c:76: error: field name not in record or union initializer pwc.c:76: error: (near initialization for 'pwc_config') pwc.c:77: error: field name not in record or union initializer pwc.c:77: error: (near initialization for 'pwc_config') pwc.c:78: error: field name not in record or union initializer pwc.c:78: error: (near initialization for 'pwc_config') pwc.c:79: error: field name not in record or union initializer pwc.c:79: error: (near initialization for 'pwc_config') pwc.c:79: error: field name not in record or union initializer pwc.c:79: error: (near initialization for 'pwc_config') pwc.c:80: error: field name not in record or union initializer pwc.c:80: error: (near initialization for 'pwc_config') pwc.c:84: error: array type has incomplete element type cc1: warnings being treated as errors pwc.c:85: warning: implicit declaration of function 'USB_VPI' pwc.c: In function 'pwc_probe': pwc.c:145: error: dereferencing pointer to incomplete type pwc.c:152: error: dereferencing pointer to incomplete type pwc.c:155: warning: implicit declaration of function 'usb2_lookup_id_by_uaa' pwc.c:155: warning: nested extern declaration of 'usb2_lookup_id_by_uaa' pwc.c: In function 'pwc_attach': pwc.c:169: warning: implicit declaration of function 'device_set_usb2_desc' pwc.c:169: warning: nested extern declaration of 'device_set_usb2_desc' pwc.c:173: error: dereferencing pointer to incomplete type pwc.c:174: warning: implicit declaration of function 'USB_GET_DRIVER_INFO' pwc.c:174: warning: nested extern declaration of 'USB_GET_DRIVER_INFO' pwc.c:175: error: dereferencing pointer to incomplete type pwc.c:180: error: dereferencing pointer to incomplete type pwc.c:181: error: dereferencing pointer to incomplete type pwc.c:184: error: dereferencing pointer to incomplete type pwc.c: In function 'pwc_detach': pwc.c:296: warning: implicit declaration of function 'usb2_transfer_unsetup' pwc.c:296: warning: nested extern declaration of 'usb2_transfer_unsetup' pwc.c: In function 'pwc_close': pwc.c:460: warning: implicit declaration of function 'usb2_set_alt_interfac= e_index' pwc.c:460: warning: nested extern declaration of 'usb2_set_alt_interface_in= dex' pwc.c: In function 'pwc_try_video_mode': pwc.c:619: error: 'USB_ERR_NORMAL_COMPLETION' undeclared (first use in this= function) pwc.c:619: error: (Each undeclared identifier is reported only once pwc.c:619: error: for each function it appears in.) pwc.c:625: warning: implicit declaration of function 'usb2_transfer_setup' pwc.c:625: warning: nested extern declaration of 'usb2_transfer_setup' pwc.c:632: warning: implicit declaration of function 'usb2_transfer_start' pwc.c:632: warning: nested extern declaration of 'usb2_transfer_start' pwc.c: In function 'pwc_isoc_rx_callback': pwc.c:680: warning: implicit declaration of function 'USB_GET_STATE' pwc.c:680: warning: nested extern declaration of 'USB_GET_STATE' pwc.c:681: error: 'USB_ST_TRANSFERRED' undeclared (first use in this functi= on) pwc.c:682: error: dereferencing pointer to incomplete type pwc.c:686: error: 'USB_ST_SETUP' undeclared (first use in this function) pwc.c:688: error: dereferencing pointer to incomplete type pwc.c:689: error: dereferencing pointer to incomplete type pwc.c:689: error: dereferencing pointer to incomplete type pwc.c:691: error: dereferencing pointer to incomplete type pwc.c:691: error: dereferencing pointer to incomplete type pwc.c:692: warning: implicit declaration of function 'usb2_start_hardware' pwc.c:692: warning: nested extern declaration of 'usb2_start_hardware' pwc.c:695: error: dereferencing pointer to incomplete type pwc.c:695: error: 'USB_ERR_CANCELLED' undeclared (first use in this functio= n) pwc.c: In function 'pwc_isoc_handler': pwc.c:710: error: dereferencing pointer to incomplete type pwc.c:729: error: dereferencing pointer to incomplete type pwc.c:730: error: dereferencing pointer to incomplete type pwc.c:743: warning: implicit declaration of function 'usb2_copy_out' pwc.c:743: warning: nested extern declaration of 'usb2_copy_out' pwc.c:743: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /usr/ports/multimedia/pwcbsd/work/pwcbsd. Thanks a lot in advance! Lars --=20 Lars Engels E-Mail: lars.engels@0x20.net =09 --69pVuxX8awAiJ7fD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqmu8kACgkQKc512sD3afgwKgCdG8LYCXKiwtaz5WD0VmJ6iPkt zpsAoMYbCQAqDTtBZ83uCA11+9toZvOQ =9eDB -----END PGP SIGNATURE----- --69pVuxX8awAiJ7fD-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 20:47:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 970F81065670; Tue, 8 Sep 2009 20:47:00 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f197.google.com (mail-qy0-f197.google.com [209.85.221.197]) by mx1.freebsd.org (Postfix) with ESMTP id 4818F8FC0A; Tue, 8 Sep 2009 20:46:59 +0000 (UTC) Received: by qyk35 with SMTP id 35so2954225qyk.14 for ; Tue, 08 Sep 2009 13:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=3k2r9nHp9+0PSJ+cEEgk/BJ2SPUws9e8X1AaWY+udn4=; b=qZLYKT9Qr+cQV/6uzmFn5M+JStndl0dmfhg2eBju8GKMqKiTF9CJ+C2d5i6JE3Gp0W 2AL6fUULajYTPXJ/y2BzLGxO1iMuvOoVhvKn22n1HLuS14Stsfb6SZuBwqX1Keu0FeRE MdSzqdIJb130xj56V3DTpmYKc8Ld+/pkNonAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=xcMtBh4/nWLxcyDib5tOtIr6EkbkBHzmJReR5bF0MA3lnOwQzbbzEgCGLwo6Bz8EZc dVVnPGOOMme8wFcDU5V6YXs3ExThgyGNJ3UK3WwwT5DbpRMj8JiMbge43uarD7Lw5Yh4 6Y+wEGC2Y30pEX2hVwUOhupHvjTJ3E3Ld1m44= Received: by 10.224.78.219 with SMTP id m27mr10383859qak.181.1252442778144; Tue, 08 Sep 2009 13:46:18 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 5sm35504qwh.40.2009.09.08.13.46.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Sep 2009 13:46:17 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 8 Sep 2009 13:45:20 -0700 From: Pyun YongHyeon Date: Tue, 8 Sep 2009 13:45:20 -0700 To: Sergey Vinogradov Message-ID: <20090908204520.GC1520@michelle.cdnetworks.com> References: <4AA65ABE.4000207@lazybytes.org> <4AA668E0.1010305@FreeBSD.org> <4AA6ACF1.3040501@lazybytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AA6ACF1.3040501@lazybytes.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Alex Dupre Subject: Re: ath(4) Atheros AR9285 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 20:47:00 -0000 On Tue, Sep 08, 2009 at 11:13:53PM +0400, Sergey Vinogradov wrote: > Alex Dupre wrote: > > Sergey Vinogradov ha scritto: > >> Just wanted to know, if there will be any Atheros AR9285 support in > >> ath(4) driver in nearest future? I've got my ASUS Eee 1005HA with one of > >> these wireless adapters, and it doesn't seem to be working. > > > > I think it should work with FreeBSD 8.0. > > > Well, despite the fact that "device ath", and all related stuff are > included in GENERIC kernel in 8.0-BETA4, I have no ath0 interface. > "dmesg | grep -i ath" gives nothing (well, as a matter of fact it gives > "alc0: ... ", but alc0 doesn't work Would you give more details on this? Showing me demsg(8) output related with alc(4) and atphy(4) would be good help. When I tried AR8132 sample board it had no such problems on my box. AR8132 uses F1 PHY even if it support only 10/100Mbps link so this might cause problems on your box, I guess. Does your link partner support only 10/100Mbps? > either, link handling is broken as I understand). Is there something I'm > doing wrong, or something I can do to help the development? :) > > -- > wbr, > Boo > From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 21:45:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9C651065670 for ; Tue, 8 Sep 2009 21:45:01 +0000 (UTC) (envelope-from sweetnavelorange@gmail.com) Received: from mail-ew0-f221.google.com (mail-ew0-f221.google.com [209.85.219.221]) by mx1.freebsd.org (Postfix) with ESMTP id 7E19B8FC14 for ; Tue, 8 Sep 2009 21:45:01 +0000 (UTC) Received: by ewy21 with SMTP id 21so408634ewy.8 for ; Tue, 08 Sep 2009 14:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=4240ORY91IuprMZKQIzmTM/JaPblLNpvp0uk9o3mV78=; b=n3MLCA5tlAvv4Kmof2yZQcAWcb+F8QhGDslPJgu9SrsN2pHMFZ25jyogr9JLLrMS23 7tHMwpOXWA0yNHRDR1OSn5oTBaU/TDN3WE8XB6d0HIdSClqJIQsmCBehwXDgQ3ytETPM FbDE+JRNUKoASazocKECMXJEv6f1RY9a3s9/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=P0xwhN7CcfMDuxKSYNdxdi54YQlKAUDnr4uKV41ScYy40d4lokT3zborud9Bn1uZQl NjUT5mWBFW261vf01v3OiYzSzcCoxbvAfZclrKIWA/f5nHKIcgCaiQaIU+BQAGan3Ln/ p8Oiis3TsLpUZUvhEEX/eBbkR4DHMzOmNpVHQ= MIME-Version: 1.0 Received: by 10.216.88.146 with SMTP id a18mr1868738wef.56.1252446300494; Tue, 08 Sep 2009 14:45:00 -0700 (PDT) In-Reply-To: References: <200909081350.34461.hselasky@c2i.net> Date: Wed, 9 Sep 2009 09:45:00 +1200 Message-ID: From: James Butler To: FreeBSD CURRENT Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Fwd: Can't boot 8.0-BETA4 from USB stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 21:45:02 -0000 2009/9/8 Hans Petter Selasky : > On Tuesday 08 September 2009 13:02:48 James Butler wrote: >> Greetings all, >> >> I have an amd64 system (Asus A8V-MX) which boots 7.2 > from a USB flash >> drive. Trying an 8-STABLE kernel from Saturday > (identifies as >> 8.0-BETA4), the system can't boot - here is the last > bit of the kernel >> messages (typed, with comments): >> >> [witness performance blah blah blah] >> root mount waiting for: usbus2 usbus1 usbus0 >> uhub0: 2 ports with 2 removable, self powered >> uhub1: 2 ports with 2 removable, self powered >> root mount waiting for: usbus2 >> uhub2: 2 ports with 2 removable, self powered >> root mount waiting for: usbus2 >> ugen2.2: at usbus2 >> umass0: addr 2> on usbus2 >> umass0: =C2=A0SCSI over Bulk-Only; quirks =3D 0x0000 >> root mount waiting for: usbus2 >> umass0:0:0:-1: Attached to scbus0 >> Trying to mount root from ufs:/dev/da0s1a >> ROOT MOUNT ERROR: >> If you have invalid mount options, reboot, and da0 at > umass-sim0 bus 0 >> target 0 lun 0 =C2=A0<---- This is suspicious >> da0: Removable Direct Access > SCSI-0 device >> da0: 40.000MB/s transfers >> da0: 3875MB (7936000 512 byte sectors: 255H 63S/T 493C) >> first try the following from =C2=A0<---- The rest of the > message that was >> cut off above >> the loader prompt: >> >> etc. etc. until the mountroot> prompt, and after that > even specifying >> the device doesn't work (and ? doesn't list it). It > seems to my >> non-hacker eyes that the device is not attaching until > after it should >> be. >> >> Any help would be appreciated, and I can provide > further information as >> needed. > > Hi, > > It looks like your device is detected too late. Have you > tried another USB port? Or plugging in another dummy USB > device? I have tried on all the ports at the back of the box, but I just remembered there's another at the front which I will try this evening. What do you mean by "dummy USB device"? Just having something else plugged in at boot? I will also try another USB drive tonight. Thanks, James From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 22:20:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2431A106566B for ; Tue, 8 Sep 2009 22:20:31 +0000 (UTC) (envelope-from tlott@gamesnet.de) Received: from spirit.gamesnet.de (spirit.gamesnet.de [87.230.101.86]) by mx1.freebsd.org (Postfix) with ESMTP id 9782D8FC08 for ; Tue, 8 Sep 2009 22:20:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by spirit.gamesnet.de (Postfix) with ESMTP id 181AB3037D1; Wed, 9 Sep 2009 00:19:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at gamesnet.de Received: from spirit.gamesnet.de ([127.0.0.1]) by localhost (spirit.gamesnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id So8Q3kVWEQrP; Wed, 9 Sep 2009 00:19:43 +0200 (CEST) Received: from sub.han.vpn.gamesnet.de (sub.han.vpn.gamesnet.de [192.168.1.101]) by spirit.gamesnet.de (Postfix) with ESMTPSA id 5FE2A3037C2; Wed, 9 Sep 2009 00:19:43 +0200 (CEST) Date: Wed, 9 Sep 2009 00:19:42 +0200 From: Tobias Lott To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> In-Reply-To: <20090908214402.43009577@sub.han.vpn.gamesnet.de> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.6; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: Problems with ZFS on AMD64 (and i386 now) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 22:20:32 -0000 On Tue, 8 Sep 2009 21:44:02 +0200 Tobias Lott wrote: > > > On Tue, 1 Sep 2009 10:05:17 -0400 > John Baldwin wrote: > > > On Tuesday 01 September 2009 9:24:24 am Maciej Jan Broniarz wrote: > > > Hello, > > > > > > I have installed Freebsd8-beta3 on a Phenom II Quad Core with 8 gb > > > ram. When I create a zfs volume all works fine. Still, when I > > > reboot the system it doesn't come up. It hangs with the following > > > error: > > > > > > http://img525.imageshack.us/img525/3832/freebsd8zfs.jpg > > > > > > What might be the problem? > > > > It's probably a NULL pointer dereference, but we would need a stack > > trace to investigate this further. > > > My Problem seems to be related. > > Updating a Machine to 8.0-BETA4 #3 caused same, its a i386 System > using gpt with zfs-only volumes beside swap. > > http://i25.tinypic.com/343p0s0.jpg > > I'll try to see if I can get a stack trace > Hey Everyone I've managed to get some Output for this, using BETA2 LiveCD (gonna try using BETA4 CD Tomorrow). 'zfs import -f poolname' triggered this, Booting kernel.old (BETA3) and today built BETA4 Kernel Panic mounting zfs Volumes. Booting single user mode I get output of zfs list and so on but mounting whatever volume also Panics. Stack output, if there's more you need I'll gladly help http://i27.tinypic.com/2d78qpd.jpg http://i31.tinypic.com/oqhv2w.jpg http://i28.tinypic.com/oktsag.jpg -- Tobias Lott From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 23:57:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ADD1106568B for ; Tue, 8 Sep 2009 23:57:36 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206049004.chello.pl [87.206.49.4]) by mx1.freebsd.org (Postfix) with ESMTP id E28E38FC23 for ; Tue, 8 Sep 2009 23:57:35 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 415CF45CDD; Wed, 9 Sep 2009 01:57:34 +0200 (CEST) Received: from localhost (chello087206049004.chello.pl [87.206.49.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id DD37545CA0; Wed, 9 Sep 2009 01:57:28 +0200 (CEST) Date: Wed, 9 Sep 2009 01:57:31 +0200 From: Pawel Jakub Dawidek To: Jeff Blank Message-ID: <20090908235731.GG1539@garage.freebsd.pl> References: <20090908202553.GA1368@mr-happy.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TeJTyD9hb8KJN2Jy" Content-Disposition: inline In-Reply-To: <20090908202553.GA1368@mr-happy.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: 8.0-BETA4 panic: ffs_sync: rofs mod X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 23:57:36 -0000 --TeJTyD9hb8KJN2Jy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 08, 2009 at 04:25:53PM -0400, Jeff Blank wrote: > Hi, >=20 > My 8.0-BETA4/amd64 installation panicked when I attempted to create a > file on zvol-backed UFS. This installation is otherwise UFS-free, ZFS > v13 w/gptzfsboot method linked from wiki, single zpool mirror > (ad{4,6}p3). >=20 > # zfs create -V 18G z0/ufs0 > # newfs -U -L oldbender /dev/zvol/z0/ufs0 > # mount /dev/ufs/oldbender /old > # touch /old/foo >=20 > The system usually panics immediately, but once it waited a few > seconds to do so, and I saw the file had been created. The file was > not there upon reboot in all cases, and the filesystem was considered > clean by fsck. >=20 > Should I expect this to work? And/or is it a known issue? (Didn't > find any similar-looking problems by googling or browsing list > archives.) >=20 > Please let me know if I need to provide more details. [...] > fs =3D /old > panic: ffs_sync: rofs mod I have no idea why UFS thinks file system is read-only. I'm not able to reproduce your problem. Doing some stress tests on UFS on top of ZVOL seems to work for me. Is there anything unusual in your setup? Maybe you could mail: # zpool status # zpool list # zfs get -r all --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --TeJTyD9hb8KJN2Jy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKpu9rForvXbEpPzQRAmRaAJ9XHPkylfy5U5bBmonMwWuXsHffAwCfXiqc Gis1qp/r6F66c66H3085eak= =ns33 -----END PGP SIGNATURE----- --TeJTyD9hb8KJN2Jy-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 8 23:49:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE8EF106566B for ; Tue, 8 Sep 2009 23:49:38 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF5B8FC16 for ; Tue, 8 Sep 2009 23:49:37 +0000 (UTC) Received: by bwz2 with SMTP id 2so1334191bwz.43 for ; Tue, 08 Sep 2009 16:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=teA3aISyd1pLnLTjfP5qCiK7VRHOgLlOeRjS8fZ5Oko=; b=mT13BF9Dx8oJ1OMk3kZp+5M90564hUvOOg7GuR2k1aOHgfck4jYtBunWVldvVnxq5B C520/Yi0ydHEf0ForTN0Ou81TjUA4sB6ZH3FVmp2OFD0JpeW3KjEYbsPAlUd02Z3VCgt w0LAycnMJhrF8sIjH2BvBUWnKPyQaClaLo/HA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=sf74RrmQUkxYR2djKtAuDfvYA270LC9abF/3GXInUvqnFA+spXv63tnFLm0bmzINIC gOt+/wTqdAEdLM/RfvVA7C38NnyiIro6fcTDoq1VDN1m1pzqzCz+ZldJUWCT+uIUMSLa F9BkNJQz7xZPDLbgg4T/H9DZUPXI6e3pf6OLk= MIME-Version: 1.0 Received: by 10.204.160.86 with SMTP id m22mr13780379bkx.82.1252453777179; Tue, 08 Sep 2009 16:49:37 -0700 (PDT) In-Reply-To: <107BC6AC-0CF6-423F-8AD9-843DA1370035@lassitu.de> References: <107BC6AC-0CF6-423F-8AD9-843DA1370035@lassitu.de> Date: Tue, 8 Sep 2009 19:49:37 -0400 Message-ID: From: grarpamp To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 09 Sep 2009 00:18:08 +0000 Subject: Re: tzsetup and EST5EDT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 23:49:38 -0000 > I get EDT for "1 - Eastern Time" when running sysinstall on an installed > system. Is your local clock on the right day? Sorry, must've been seeing things when I wrote EST. Complicated by the 'EDT' displayed by tzsetup not[?], afaik, being an actual formal timezone but just a marker as to the current state of the actual EST5EDT timezone. I use NTP, UTC CMOS (no /etc/wall_cmos_clock), and /etc/localtime copied in. 1) EST - is UTC-5 all year round, and is in use in only a few geographical places. 2) EST5EDT - is EST (UTC-5) in the 'winter', and 'EDT' (UTC-4) in the 'summer' (now, daylight savings time). > If you think sysinstall should produce "EST5EDT", you're expecting the > wrong thing. It might be a useful idea, with the current state alongside for daylight savings zones. > For quite some time, it's given the time zone abbreviation > appropriate to the chosen location for the current date and time. I don't know what the difference is between the 'New_York' and 'EST5EDT' files. I suppose I could look at the zone compiler for that. The more formal 'EST5EDT' seems to work fine for me. 87a75432ef636782207fa06d603585c0 /etc/localtime 3cf0ccc7d6b240390188367933c9cd90 /usr/share/zoneinfo/posixrules 3cf0ccc7d6b240390188367933c9cd90 /usr/share/zoneinfo/America/New_York 6fac20ee52a95b38ad0e1657f77aa4c4 /usr/share/zoneinfo/EST 87a75432ef636782207fa06d603585c0 /usr/share/zoneinfo/EST5EDT From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 00:55:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2AE3106566C; Wed, 9 Sep 2009 00:55:06 +0000 (UTC) (envelope-from jfb@mr-happy.com) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [IPv6:2001:470:b:28:f::1]) by mx1.freebsd.org (Postfix) with ESMTP id B4BAE8FC08; Wed, 9 Sep 2009 00:55:06 +0000 (UTC) Received: from crow.mr-happy.com (crow.mr-happy.com [10.1.0.2]) by vexbert.mr-paradox.net (Postfix) with ESMTP id AD23C84564; Tue, 8 Sep 2009 20:55:05 -0400 (EDT) Received: by crow.mr-happy.com (Postfix, from userid 16139) id B622745052; Tue, 8 Sep 2009 20:55:04 -0400 (EDT) Date: Tue, 8 Sep 2009 20:55:04 -0400 From: Jeff Blank To: Pawel Jakub Dawidek Message-ID: <20090909005504.GA12660@mr-happy.com> References: <20090908202553.GA1368@mr-happy.com> <20090908235731.GG1539@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <20090908235731.GG1539@garage.freebsd.pl> X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e X-Virus-Scanned: ClamAV 0.94.2/9785/Tue Sep 8 11:36:59 2009 on vexbert.mr-paradox.net X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: 8.0-BETA4 panic: ffs_sync: rofs mod X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 00:55:07 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Sep 09, 2009 at 01:57:31AM +0200, Pawel Jakub Dawidek wrote: > On Tue, Sep 08, 2009 at 04:25:53PM -0400, Jeff Blank wrote: > > Please let me know if I need to provide more details. > [...] > > fs = /old > > panic: ffs_sync: rofs mod > > I have no idea why UFS thinks file system is read-only. hmm, I do have it marked as read-only in /etc/fstab, but I'd been mounting it with '-o rw'. I just now commented out the fstab entry and mounted it 'mount /dev/oldbender /old' and created files, and that worked fine. > I'm not able to reproduce your problem. Doing some stress tests on UFS > on top of ZVOL seems to work for me. > Is there anything unusual in your setup? I don't think so. maybe swapping to gmirror, but that's probably it. > Maybe you could mail: > > # zpool status > # zpool list > # zfs get -r all attached. Jeff --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="zfs_output.txt" # zpool status pool: z0 state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM z0 ONLINE 0 0 0 mirror ONLINE 0 0 0 ad4p3 ONLINE 0 0 0 ad6p3 ONLINE 0 0 0 errors: No known data errors # zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT z0 141G 27.6G 113G 19% ONLINE - # zfs get -r all NAME PROPERTY VALUE SOURCE z0 type filesystem - z0 creation Thu Sep 3 23:16 2009 - z0 used 45.8G - z0 available 93.0G - z0 referenced 1.68G - z0 compressratio 1.02x - z0 mounted yes - z0 quota none default z0 reservation none default z0 recordsize 128K default z0 mountpoint legacy local z0 sharenfs off default z0 checksum on default z0 compression off default z0 atime on default z0 devices on default z0 exec on default z0 setuid on default z0 readonly off local z0 jailed off default z0 snapdir hidden default z0 aclmode groupmask default z0 aclinherit restricted default z0 canmount on default z0 shareiscsi off default z0 xattr off temporary z0 copies 1 default z0 version 3 - z0 utf8only off - z0 normalization none - z0 casesensitivity sensitive - z0 vscan off default z0 nbmand off default z0 sharesmb off default z0 refquota none default z0 refreservation none default z0 primarycache all default z0 secondarycache all default z0 usedbysnapshots 0 - z0 usedbydataset 1.68G - z0 usedbychildren 44.2G - z0 usedbyrefreservation 0 - z0/crash type filesystem - z0/crash creation Thu Sep 3 23:18 2009 - z0/crash used 342M - z0/crash available 9.67G - z0/crash referenced 342M - z0/crash compressratio 2.88x - z0/crash mounted yes - z0/crash quota 10G local z0/crash reservation none default z0/crash recordsize 128K default z0/crash mountpoint /var/crash local z0/crash sharenfs off default z0/crash checksum on default z0/crash compression on local z0/crash atime on default z0/crash devices on default z0/crash exec off local z0/crash setuid off local z0/crash readonly off inherited from z0 z0/crash jailed off default z0/crash snapdir hidden default z0/crash aclmode groupmask default z0/crash aclinherit restricted default z0/crash canmount on default z0/crash shareiscsi off default z0/crash xattr off temporary z0/crash copies 1 default z0/crash version 3 - z0/crash utf8only off - z0/crash normalization none - z0/crash casesensitivity sensitive - z0/crash vscan off default z0/crash nbmand off default z0/crash sharesmb off default z0/crash refquota none default z0/crash refreservation none default z0/crash primarycache all default z0/crash secondarycache all default z0/crash usedbysnapshots 0 - z0/crash usedbydataset 342M - z0/crash usedbychildren 0 - z0/crash usedbyrefreservation 0 - z0/distfiles type filesystem - z0/distfiles creation Thu Sep 3 23:19 2009 - z0/distfiles used 4.93G - z0/distfiles available 93.0G - z0/distfiles referenced 4.93G - z0/distfiles compressratio 1.00x - z0/distfiles mounted yes - z0/distfiles quota none default z0/distfiles reservation none default z0/distfiles recordsize 128K default z0/distfiles mountpoint /usr/local/distfiles local z0/distfiles sharenfs off default z0/distfiles checksum on default z0/distfiles compression off default z0/distfiles atime on default z0/distfiles devices on default z0/distfiles exec on default z0/distfiles setuid on default z0/distfiles readonly off inherited from z0 z0/distfiles jailed off default z0/distfiles snapdir hidden default z0/distfiles aclmode groupmask default z0/distfiles aclinherit restricted default z0/distfiles canmount on default z0/distfiles shareiscsi off default z0/distfiles xattr off temporary z0/distfiles copies 1 default z0/distfiles version 3 - z0/distfiles utf8only off - z0/distfiles normalization none - z0/distfiles casesensitivity sensitive - z0/distfiles vscan off default z0/distfiles nbmand off default z0/distfiles sharesmb off default z0/distfiles refquota none default z0/distfiles refreservation none default z0/distfiles primarycache all default z0/distfiles secondarycache all default z0/distfiles usedbysnapshots 0 - z0/distfiles usedbydataset 4.93G - z0/distfiles usedbychildren 0 - z0/distfiles usedbyrefreservation 0 - z0/homes type filesystem - z0/homes creation Thu Sep 3 23:19 2009 - z0/homes used 7.24G - z0/homes available 93.0G - z0/homes referenced 7.24G - z0/homes compressratio 1.00x - z0/homes mounted yes - z0/homes quota none default z0/homes reservation none default z0/homes recordsize 128K default z0/homes mountpoint /usr/local/homes local z0/homes sharenfs off default z0/homes checksum on default z0/homes compression off default z0/homes atime on default z0/homes devices on default z0/homes exec on default z0/homes setuid on default z0/homes readonly off inherited from z0 z0/homes jailed off default z0/homes snapdir hidden default z0/homes aclmode groupmask default z0/homes aclinherit restricted default z0/homes canmount on default z0/homes shareiscsi off default z0/homes xattr off temporary z0/homes copies 1 default z0/homes version 3 - z0/homes utf8only off - z0/homes normalization none - z0/homes casesensitivity sensitive - z0/homes vscan off default z0/homes nbmand off default z0/homes sharesmb off default z0/homes refquota none default z0/homes refreservation none default z0/homes primarycache all default z0/homes secondarycache all default z0/homes usedbysnapshots 0 - z0/homes usedbydataset 7.24G - z0/homes usedbychildren 0 - z0/homes usedbyrefreservation 0 - z0/mp3 type filesystem - z0/mp3 creation Thu Sep 3 23:19 2009 - z0/mp3 used 6.49G - z0/mp3 available 93.0G - z0/mp3 referenced 6.49G - z0/mp3 compressratio 1.00x - z0/mp3 mounted yes - z0/mp3 quota none default z0/mp3 reservation none default z0/mp3 recordsize 128K default z0/mp3 mountpoint /usr/local/mp3 local z0/mp3 sharenfs off default z0/mp3 checksum on default z0/mp3 compression off default z0/mp3 atime on default z0/mp3 devices on default z0/mp3 exec on default z0/mp3 setuid on default z0/mp3 readonly off inherited from z0 z0/mp3 jailed off default z0/mp3 snapdir hidden default z0/mp3 aclmode groupmask default z0/mp3 aclinherit restricted default z0/mp3 canmount on default z0/mp3 shareiscsi off default z0/mp3 xattr off temporary z0/mp3 copies 1 default z0/mp3 version 3 - z0/mp3 utf8only off - z0/mp3 normalization none - z0/mp3 casesensitivity sensitive - z0/mp3 vscan off default z0/mp3 nbmand off default z0/mp3 sharesmb off default z0/mp3 refquota none default z0/mp3 refreservation none default z0/mp3 primarycache all default z0/mp3 secondarycache all default z0/mp3 usedbysnapshots 0 - z0/mp3 usedbydataset 6.49G - z0/mp3 usedbychildren 0 - z0/mp3 usedbyrefreservation 0 - z0/obj type filesystem - z0/obj creation Thu Sep 3 23:20 2009 - z0/obj used 3.15G - z0/obj available 93.0G - z0/obj referenced 3.15G - z0/obj compressratio 1.00x - z0/obj mounted yes - z0/obj quota none default z0/obj reservation none default z0/obj recordsize 128K default z0/obj mountpoint /usr/obj local z0/obj sharenfs off default z0/obj checksum on default z0/obj compression off default z0/obj atime on default z0/obj devices on default z0/obj exec on default z0/obj setuid on default z0/obj readonly off inherited from z0 z0/obj jailed off default z0/obj snapdir hidden default z0/obj aclmode groupmask default z0/obj aclinherit restricted default z0/obj canmount on default z0/obj shareiscsi off default z0/obj xattr off temporary z0/obj copies 1 default z0/obj version 3 - z0/obj utf8only off - z0/obj normalization none - z0/obj casesensitivity sensitive - z0/obj vscan off default z0/obj nbmand off default z0/obj sharesmb off default z0/obj refquota none default z0/obj refreservation none default z0/obj primarycache all default z0/obj secondarycache all default z0/obj usedbysnapshots 0 - z0/obj usedbydataset 3.15G - z0/obj usedbychildren 0 - z0/obj usedbyrefreservation 0 - z0/ports type filesystem - z0/ports creation Thu Sep 3 23:20 2009 - z0/ports used 325M - z0/ports available 93.0G - z0/ports referenced 325M - z0/ports compressratio 1.20x - z0/ports mounted yes - z0/ports quota none default z0/ports reservation none default z0/ports recordsize 128K default z0/ports mountpoint /usr/ports local z0/ports sharenfs off default z0/ports checksum on default z0/ports compression on local z0/ports atime on default z0/ports devices on default z0/ports exec off local z0/ports setuid off local z0/ports readonly off inherited from z0 z0/ports jailed off default z0/ports snapdir hidden default z0/ports aclmode groupmask default z0/ports aclinherit restricted default z0/ports canmount on default z0/ports shareiscsi off default z0/ports xattr off temporary z0/ports copies 1 default z0/ports version 3 - z0/ports utf8only off - z0/ports normalization none - z0/ports casesensitivity sensitive - z0/ports vscan off default z0/ports nbmand off default z0/ports sharesmb off default z0/ports refquota none default z0/ports refreservation none default z0/ports primarycache all default z0/ports secondarycache all default z0/ports usedbysnapshots 0 - z0/ports usedbydataset 325M - z0/ports usedbychildren 0 - z0/ports usedbyrefreservation 0 - z0/tmp type filesystem - z0/tmp creation Thu Sep 3 23:17 2009 - z0/tmp used 7.56M - z0/tmp available 5.99G - z0/tmp referenced 7.56M - z0/tmp compressratio 3.33x - z0/tmp mounted yes - z0/tmp quota 6G local z0/tmp reservation none default z0/tmp recordsize 128K default z0/tmp mountpoint /tmp local z0/tmp sharenfs off default z0/tmp checksum on default z0/tmp compression on local z0/tmp atime on default z0/tmp devices on default z0/tmp exec on default z0/tmp setuid off local z0/tmp readonly off inherited from z0 z0/tmp jailed off default z0/tmp snapdir hidden default z0/tmp aclmode groupmask default z0/tmp aclinherit restricted default z0/tmp canmount on default z0/tmp shareiscsi off default z0/tmp xattr off temporary z0/tmp copies 1 default z0/tmp version 3 - z0/tmp utf8only off - z0/tmp normalization none - z0/tmp casesensitivity sensitive - z0/tmp vscan off default z0/tmp nbmand off default z0/tmp sharesmb off default z0/tmp refquota none default z0/tmp refreservation none default z0/tmp primarycache all default z0/tmp secondarycache all default z0/tmp usedbysnapshots 0 - z0/tmp usedbydataset 7.56M - z0/tmp usedbychildren 0 - z0/tmp usedbyrefreservation 0 - z0/ufs0 type volume - z0/ufs0 creation Tue Sep 8 20:47 2009 - z0/ufs0 used 18G - z0/ufs0 available 111G - z0/ufs0 referenced 6.79M - z0/ufs0 compressratio 1.00x - z0/ufs0 reservation none default z0/ufs0 volsize 18G - z0/ufs0 volblocksize 8K - z0/ufs0 checksum on default z0/ufs0 compression off default z0/ufs0 readonly off inherited from z0 z0/ufs0 shareiscsi off default z0/ufs0 copies 1 default z0/ufs0 refreservation 18G local z0/ufs0 primarycache all default z0/ufs0 secondarycache all default z0/ufs0 usedbysnapshots 0 - z0/ufs0 usedbydataset 6.79M - z0/ufs0 usedbychildren 0 - z0/ufs0 usedbyrefreservation 18.0G - z0/usr type filesystem - z0/usr creation Thu Sep 3 23:17 2009 - z0/usr used 259M - z0/usr available 93.0G - z0/usr referenced 259M - z0/usr compressratio 1.00x - z0/usr mounted yes - z0/usr quota none default z0/usr reservation none default z0/usr recordsize 128K default z0/usr mountpoint /usr local z0/usr sharenfs off default z0/usr checksum on default z0/usr compression off default z0/usr atime on default z0/usr devices on default z0/usr exec on default z0/usr setuid on default z0/usr readonly off inherited from z0 z0/usr jailed off default z0/usr snapdir hidden default z0/usr aclmode groupmask default z0/usr aclinherit restricted default z0/usr canmount on default z0/usr shareiscsi off default z0/usr xattr off temporary z0/usr copies 1 default z0/usr version 3 - z0/usr utf8only off - z0/usr normalization none - z0/usr casesensitivity sensitive - z0/usr vscan off default z0/usr nbmand off default z0/usr sharesmb off default z0/usr refquota none default z0/usr refreservation none default z0/usr primarycache all default z0/usr secondarycache all default z0/usr usedbysnapshots 0 - z0/usr usedbydataset 259M - z0/usr usedbychildren 0 - z0/usr usedbyrefreservation 0 - z0/usrlocal type filesystem - z0/usrlocal creation Thu Sep 3 23:19 2009 - z0/usrlocal used 3.08G - z0/usrlocal available 93.0G - z0/usrlocal referenced 3.08G - z0/usrlocal compressratio 1.00x - z0/usrlocal mounted yes - z0/usrlocal quota none default z0/usrlocal reservation none default z0/usrlocal recordsize 128K default z0/usrlocal mountpoint /usr/local local z0/usrlocal sharenfs off default z0/usrlocal checksum on default z0/usrlocal compression off default z0/usrlocal atime on default z0/usrlocal devices on default z0/usrlocal exec on default z0/usrlocal setuid on default z0/usrlocal readonly off inherited from z0 z0/usrlocal jailed off default z0/usrlocal snapdir hidden default z0/usrlocal aclmode groupmask default z0/usrlocal aclinherit restricted default z0/usrlocal canmount on default z0/usrlocal shareiscsi off default z0/usrlocal xattr off temporary z0/usrlocal copies 1 default z0/usrlocal version 3 - z0/usrlocal utf8only off - z0/usrlocal normalization none - z0/usrlocal casesensitivity sensitive - z0/usrlocal vscan off default z0/usrlocal nbmand off default z0/usrlocal sharesmb off default z0/usrlocal refquota none default z0/usrlocal refreservation none default z0/usrlocal primarycache all default z0/usrlocal secondarycache all default z0/usrlocal usedbysnapshots 0 - z0/usrlocal usedbydataset 3.08G - z0/usrlocal usedbychildren 0 - z0/usrlocal usedbyrefreservation 0 - z0/var type filesystem - z0/var creation Thu Sep 3 23:18 2009 - z0/var used 110M - z0/var available 93.0G - z0/var referenced 110M - z0/var compressratio 1.00x - z0/var mounted yes - z0/var quota none default z0/var reservation none default z0/var recordsize 128K default z0/var mountpoint /var local z0/var sharenfs off default z0/var checksum on default z0/var compression off default z0/var atime on default z0/var devices on default z0/var exec on default z0/var setuid on default z0/var readonly off inherited from z0 z0/var jailed off default z0/var snapdir hidden default z0/var aclmode groupmask default z0/var aclinherit restricted default z0/var canmount on default z0/var shareiscsi off default z0/var xattr off temporary z0/var copies 1 default z0/var version 3 - z0/var utf8only off - z0/var normalization none - z0/var casesensitivity sensitive - z0/var vscan off default z0/var nbmand off default z0/var sharesmb off default z0/var refquota none default z0/var refreservation none default z0/var primarycache all default z0/var secondarycache all default z0/var usedbysnapshots 0 - z0/var usedbydataset 110M - z0/var usedbychildren 0 - z0/var usedbyrefreservation 0 - z0/vartmp type filesystem - z0/vartmp creation Thu Sep 3 23:20 2009 - z0/vartmp used 77K - z0/vartmp available 6.00G - z0/vartmp referenced 77K - z0/vartmp compressratio 1.33x - z0/vartmp mounted yes - z0/vartmp quota 6G local z0/vartmp reservation 256M local z0/vartmp recordsize 128K default z0/vartmp mountpoint /var/tmp local z0/vartmp sharenfs off default z0/vartmp checksum on default z0/vartmp compression on local z0/vartmp atime on default z0/vartmp devices on default z0/vartmp exec on default z0/vartmp setuid off local z0/vartmp readonly off inherited from z0 z0/vartmp jailed off default z0/vartmp snapdir hidden default z0/vartmp aclmode groupmask default z0/vartmp aclinherit restricted default z0/vartmp canmount on default z0/vartmp shareiscsi off default z0/vartmp xattr off temporary z0/vartmp copies 1 default z0/vartmp version 3 - z0/vartmp utf8only off - z0/vartmp normalization none - z0/vartmp casesensitivity sensitive - z0/vartmp vscan off default z0/vartmp nbmand off default z0/vartmp sharesmb off default z0/vartmp refquota none default z0/vartmp refreservation none default z0/vartmp primarycache all default z0/vartmp secondarycache all default z0/vartmp usedbysnapshots 0 - z0/vartmp usedbydataset 77K - z0/vartmp usedbychildren 0 - z0/vartmp usedbyrefreservation 0 - --qDbXVdCdHGoSgWSk-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 00:55:43 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43A4A106566C for ; Wed, 9 Sep 2009 00:55:43 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id EDFAE8FC13 for ; Wed, 9 Sep 2009 00:55:42 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id C966B730DA; Wed, 9 Sep 2009 03:01:37 +0200 (CEST) Date: Wed, 9 Sep 2009 03:01:37 +0200 From: Luigi Rizzo To: current@freebsd.org, jeff@freebsd.org, re@freebsd.org Message-ID: <20090909010137.GA74897@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: clock error: callouts are run one tick late X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 00:55:43 -0000 RELENG_8/amd64 (can not try on i386) has the following problem: callout_reset(..., t, ...) processes the callout after t+1 ticks instead of the t ticks that one sees on RELENG_7 and earlier. I found it by pure chance, noticing that dummynet on RELENG_8 has a jitter that is two ticks instead of one tick. Other systems with rely on frequent callouts might see problems as well. An indirect way to see the problem is the following: kldload dummynet sysctl net.inet.ip.dummynet.tick_adjustment; \ sleep 1; sysctl net.inet.ip.dummynet.tick_adjustment on a working system, the variable should remain mostly unchanged; on a non-working system you see it growing at a rate HZ/2 I suspect the bug is introduced by the change in kern_timeout.c rev. 1.114 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_timeout.c.diff?r1=1.113;r2=1.114 which changes softclock() to stop before the current 'ticks' so processes everything one tick late. I understand the race described in the cvs log, but this does not seem a proper fix -- it violates POLA by changing the semantics of callout_reset(), and does not really fix the race, but just adds an extra uncertainty of 1 tick on when a given callout will be run If the problem is a race between hardclock() which updates 'ticks', and the various hardclock_cpu() instances which might arrive early, I would suggest two alternative options: 1. create a per-cpu 'ticks' (say a field cc_ticks in struct callout_cpu), increment it at the start of hardclock_cpu, and use cc->ticks instead of 'ticks' in the various callout functions involved with manipulation of the callwheel callout_tick(), softclock(), callout_reset_on() 2. start softclock() at cc->cc_softticks -1, i.e. ... CC_LOCK(cc) - while (cc->cc_softticks != ticks) { + while (cc->cc_softticks-1 != ticks) { ... so we can catch up any work leftover due to the race. I think option #1 is preferable as it should completely remove the race condition, though #2 might be reasonable as a quick fix should we decide to add it to 8.0 cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 00:59:47 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AAF910656AB; Wed, 9 Sep 2009 00:59:47 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) Received: from www.heimat.gr.jp (unknown [IPv6:2001:3e0:a84::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2DD938FC3E; Wed, 9 Sep 2009 00:59:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at heimat.gr.jp Received: from ra333.heimat.gr.jp.kankyo-u.ac.jp (ra333.heimat.gr.jp [IPv6:2001:3e0:a84:0:200:4cff:fe17:573c]) by www.heimat.gr.jp (8.14.3/8.14.3) with ESMTP id n890xMg9003749; Wed, 9 Sep 2009 09:59:22 +0900 (JST) (envelope-from nakaji@kankyo-u.ac.jp) From: NAKAJI Hiroyuki To: "Bjoern A. Zeeb" References: <20090829182437.GV37252@cicely7.cicely.de> <86ljkqk6vw.fsf@ra333.heimat.gr.jp> <20090907173139.GG15218@cicely7.cicely.de> <20090907175855.W68375@maildrop.int.zabbadoz.net> <86eiqijpd2.fsf@ra333.heimat.gr.jp> <20090908055055.C68375@maildrop.int.zabbadoz.net> Date: Wed, 09 Sep 2009 09:59:22 +0900 In-Reply-To: <20090908055055.C68375@maildrop.int.zabbadoz.net> (Bjoern A. Zeeb's message of "Tue, 8 Sep 2009 05:51:27 +0000 (UTC)") Message-ID: <86tyzdhr11.fsf@ra333.heimat.gr.jp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-6.1 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on www.heimat.gr.jp Cc: freebsd-current@FreeBSD.org, ticso@cicely.de Subject: Re: ELF interpreter /libexec/ld-elf.so.1 not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 00:59:47 -0000 >>>>> In <20090908055055.C68375@maildrop.int.zabbadoz.net> >>>>> "Bjoern A. Zeeb" wrote: > Good morning, Good morning from Japan, > >> It was comitted to HEAD, MFCed to stable/8 a few days ago and MFCed > >> to stable/7 earlier today. > > > > Thanks. Is it r196924? > > http://lists.freebsd.org/pipermail/svn-src-stable-7/2009-September/001900.html > Yes, exactly. I see. I'll test again. If I find a problem, I will post it to -stable. :) Thanks. -- NAKAJI Hiroyuki From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 01:10:10 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0250106566C; Wed, 9 Sep 2009 01:10:10 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id A59D98FC19; Wed, 9 Sep 2009 01:10:10 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id ECCB77310A; Wed, 9 Sep 2009 03:16:06 +0200 (CEST) Date: Wed, 9 Sep 2009 03:16:06 +0200 From: Luigi Rizzo To: current@freebsd.org, jeff@freebsd.org, re@freebsd.org Message-ID: <20090909011606.GA77031@onelab2.iet.unipi.it> References: <20090909010137.GA74897@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090909010137.GA74897@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: clock error: callouts are run one tick late X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 01:10:11 -0000 On Wed, Sep 09, 2009 at 03:01:37AM +0200, Luigi Rizzo wrote: > RELENG_8/amd64 (can not try on i386) has the following problem: > > callout_reset(..., t, ...) > > processes the callout after t+1 ticks instead of the t ticks > that one sees on RELENG_7 and earlier. > > I found it by pure chance, noticing that dummynet on RELENG_8 > has a jitter that is two ticks instead of one tick. > Other systems with rely on frequent callouts might see > problems as well. > > An indirect way to see the problem is the following: > > kldload dummynet > > sysctl net.inet.ip.dummynet.tick_adjustment; \ > sleep 1; sysctl net.inet.ip.dummynet.tick_adjustment > > on a working system, the variable should remain mostly unchanged; > on a non-working system you see it growing at a rate HZ/2 > > I suspect the bug is introduced by the change in kern_timeout.c rev. 1.114 > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_timeout.c.diff?r1=1.113;r2=1.114 > > which changes softclock() to stop before the current 'ticks' > so processes everything one tick late. > > I understand the race described in the cvs log, but this does > not seem a proper fix -- it violates POLA by changing the semantics > of callout_reset(), and does not really fix the race, but just adds > an extra uncertainty of 1 tick on when a given callout will be run > > If the problem is a race between hardclock() which updates 'ticks', > and the various hardclock_cpu() instances which might arrive early, > I would suggest two alternative options: > > 1. create a per-cpu 'ticks' (say a field cc_ticks in struct callout_cpu), > increment it at the start of hardclock_cpu, and use cc->ticks > instead of 'ticks' in the various callout functions involved > with manipulation of the callwheel > callout_tick(), softclock(), callout_reset_on() > > 2. start softclock() at cc->cc_softticks -1, i.e. > > ... > CC_LOCK(cc) > - while (cc->cc_softticks != ticks) { > + while (cc->cc_softticks-1 != ticks) { > ... #2 also need this change in callout_tick() mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET); - for (; (cc->cc_softticks - ticks) < 0; cc->cc_softticks++) { + for (; (cc->cc_softticks - ticks) <= 0; cc->cc_softticks++) { bucket = cc->cc_softticks & callwheelmask; Just tested it, it seems to fix the problem. cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 01:50:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DFE11065670 for ; Wed, 9 Sep 2009 01:50:31 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id C8F838FC12 for ; Wed, 9 Sep 2009 01:50:30 +0000 (UTC) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n891oTxl071218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Sep 2009 18:50:30 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4AA709E5.2000607@errno.com> Date: Tue, 08 Sep 2009 18:50:29 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Sergey Vinogradov References: <4AA65ABE.4000207@lazybytes.org> In-Reply-To: <4AA65ABE.4000207@lazybytes.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: ath(4) Atheros AR9285 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 01:50:31 -0000 Sergey Vinogradov wrote: > Hi, > Just wanted to know, if there will be any Atheros AR9285 support in > ath(4) driver in nearest future? I've got my ASUS Eee 1005HA with one of > these wireless adapters, and it doesn't seem to be working. > I have no plans to do anything. I asked for a card for a long time but never got one. Now I've got zero time. Sam From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 05:42:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57763106566B; Wed, 9 Sep 2009 05:42:58 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206049004.chello.pl [87.206.49.4]) by mx1.freebsd.org (Postfix) with ESMTP id 97B9E8FC12; Wed, 9 Sep 2009 05:42:56 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id AF2AD45E49; Wed, 9 Sep 2009 07:42:52 +0200 (CEST) Received: from localhost (chello087206049004.chello.pl [87.206.49.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 7639B45E11; Wed, 9 Sep 2009 07:42:47 +0200 (CEST) Date: Wed, 9 Sep 2009 07:42:49 +0200 From: Pawel Jakub Dawidek To: Tobias Lott Message-ID: <20090909054249.GH1539@garage.freebsd.pl> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zGQnqpIoxlsbsOfg" Content-Disposition: inline In-Reply-To: <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Problems with ZFS on AMD64 (and i386 now) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 05:42:58 -0000 --zGQnqpIoxlsbsOfg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 09, 2009 at 12:19:42AM +0200, Tobias Lott wrote: > Hey Everyone >=20 > I've managed to get some Output for this, using BETA2 LiveCD (gonna try > using BETA4 CD Tomorrow). >=20 > 'zfs import -f poolname' triggered this, Booting kernel.old (BETA3) > and today built BETA4 Kernel Panic mounting zfs Volumes. > Booting single user mode I get output of zfs list and so on but > mounting whatever volume also Panics. Why -f? Were there a poblem in importing pool? > Stack output, if there's more you need I'll gladly help > http://i27.tinypic.com/2d78qpd.jpg > http://i31.tinypic.com/oqhv2w.jpg > http://i28.tinypic.com/oktsag.jpg Could you also provide top part of the backtrace? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --zGQnqpIoxlsbsOfg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKp0BZForvXbEpPzQRAuTrAJ97Q5uW8gCyrpjrlgiBbbu2v0tqhQCfa3pz TjO7DfZhhshfMTV1c99Oi0M= =4fxk -----END PGP SIGNATURE----- --zGQnqpIoxlsbsOfg-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 07:02:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F20B1065679; Wed, 9 Sep 2009 07:02:37 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5128FC0A; Wed, 9 Sep 2009 07:02:36 +0000 (UTC) Received: from smoochies.rachie.is-a-geek.net (mailhub.lan.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id AFE747E818; Tue, 8 Sep 2009 23:02:48 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Wed, 9 Sep 2009 09:02:33 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA4; KDE/4.2.4; i386; ; ) References: <20090908202553.GA1368@mr-happy.com> <20090908235731.GG1539@garage.freebsd.pl> <20090909005504.GA12660@mr-happy.com> In-Reply-To: <20090909005504.GA12660@mr-happy.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909090902.34055.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Pawel Jakub Dawidek , Jeff Blank Subject: Re: 8.0-BETA4 panic: ffs_sync: rofs mod X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 07:02:37 -0000 On Wednesday 09 September 2009 02:55:04 Jeff Blank wrote: > On Wed, Sep 09, 2009 at 01:57:31AM +0200, Pawel Jakub Dawidek wrote: > > On Tue, Sep 08, 2009 at 04:25:53PM -0400, Jeff Blank wrote: > > > Please let me know if I need to provide more details. > > > > [...] > > > > > fs = /old > > > panic: ffs_sync: rofs mod > > > > I have no idea why UFS thinks file system is read-only. > > hmm, I do have it marked as read-only in /etc/fstab, but I'd been > mounting it with '-o rw'. This problem has also been seen on -questions [1] and I forgot to follow up after time issues. According to the poster it's easy to reproduce: - have a mountpoint in /etc/fstab with ro options - unmount the mountpoint - remount using -o rw The behavior does not occur if one uses mount -u -o rw without unmounting. I think this is a too easy way to panic the kernel. [1] -- Mel From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 05:31:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D142E1065670 for ; Wed, 9 Sep 2009 05:31:56 +0000 (UTC) (envelope-from koleman@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id 6152A8FC13 for ; Wed, 9 Sep 2009 05:31:56 +0000 (UTC) Received: by fxm6 with SMTP id 6so2993916fxm.43 for ; Tue, 08 Sep 2009 22:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer; bh=lNDAOVDj71okTaElLke8CS4owURDHrheQmkjEVR59DI=; b=WHRL+GgIs4UrxH6rH8A7MMvsR5o5eqJKNKpQI9HiwFqa9faydPFEgKx+PHGeP9cMna woJgIN30+MKIpom5bs7SEs7K+htvAcemk0tDwUqZ6xwy01lOdDElH6aWxsmzUx3voF/l HPODIj+xM11odkxyIk3k8I+mqqHZurZOT5ZtM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer; b=kLikhSwzLXxIJ4+j3Bpb3alykwXaGqP2Z9YeaUeYo3wY5ID7SEEWxFjfIgwkJlPTxe 3UFsF3BUIdB4G4BtT7eFhtewACRCzBZzboJakLmyu8MIFsScsZfj+bL2P8NJ5OH0NIRJ s5JORh+i6mjP5CkUh96gQbmu2Nh4Ksl0ggqkI= Received: by 10.223.60.134 with SMTP id p6mr6651172fah.95.1252474315528; Tue, 08 Sep 2009 22:31:55 -0700 (PDT) Received: from ?80.186.94.122? (80-186-94-122.elisa-mobile.fi [80.186.94.122]) by mx.google.com with ESMTPS id z15sm1121775fkz.4.2009.09.08.22.31.52 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Sep 2009 22:31:54 -0700 (PDT) From: "=?ISO-8859-1?B?QW50dGkgS29sZWhtYWluZW4=?=" To: freebsd-current@freebsd.org Date: Wed, 09 Sep 2009 08:31:48 +0200 Message-Id: <1252477908753@koleman_gmail.com> Mime-Version: 1.0 X-Mailer: EMCL4 v1.41.0 X-Mailman-Approved-At: Wed, 09 Sep 2009 07:02:45 +0000 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: Base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: problems with usb if you unload and reload kernel modules X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 05:31:56 -0000 From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 07:48:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A17A106566C for ; Wed, 9 Sep 2009 07:48:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swipnet.se [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 2028E8FC16 for ; Wed, 9 Sep 2009 07:48:16 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=4TrS-n8VG_gA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=3S_yhkK6x--KoIuU5HkA:9 a=_pveyqdUjF068mghGs8rp7SnAKQA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1134386452; Wed, 09 Sep 2009 09:48:14 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 9 Sep 2009 09:48:39 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <1252477908753@koleman_gmail.com> In-Reply-To: <1252477908753@koleman_gmail.com> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909090948.40826.hselasky@c2i.net> Cc: Antti Kolehmainen Subject: Re: problems with usb if you unload and reload kernel modules X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 07:48:17 -0000 On Wednesday 09 September 2009 08:31:48 Antti Kolehmainen wrote: Please be more specific. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 08:13:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82ADC1065693; Wed, 9 Sep 2009 08:13:51 +0000 (UTC) (envelope-from tlott@gamesnet.de) Received: from spirit.gamesnet.de (cl-858.dus-01.de.sixxs.net [IPv6:2a01:198:200:359::2]) by mx1.freebsd.org (Postfix) with ESMTP id 404AC8FC16; Wed, 9 Sep 2009 08:13:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by spirit.gamesnet.de (Postfix) with ESMTP id 628C03044FA; Wed, 9 Sep 2009 10:13:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at gamesnet.de Received: from spirit.gamesnet.de ([127.0.0.1]) by localhost (spirit.gamesnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RPFW1DoQdCC; Wed, 9 Sep 2009 10:13:47 +0200 (CEST) Received: from sub.han.vpn.gamesnet.de (sub.han.vpn.gamesnet.de [192.168.1.101]) by spirit.gamesnet.de (Postfix) with ESMTPSA id A93B33044F2; Wed, 9 Sep 2009 10:13:47 +0200 (CEST) Date: Wed, 9 Sep 2009 10:13:46 +0200 From: Tobias Lott To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20090909101346.01887a02@sub.han.vpn.gamesnet.de> In-Reply-To: <20090909054249.GH1539@garage.freebsd.pl> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> <20090909054249.GH1539@garage.freebsd.pl> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.6; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: Problems with ZFS on AMD64 (and i386 now) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 08:13:51 -0000 On Wed, 9 Sep 2009 07:42:49 +0200 Pawel Jakub Dawidek wrote: > On Wed, Sep 09, 2009 at 12:19:42AM +0200, Tobias Lott wrote: > > Hey Everyone > > > > I've managed to get some Output for this, using BETA2 LiveCD (gonna > > try using BETA4 CD Tomorrow). > > > > 'zfs import -f poolname' triggered this, Booting kernel.old (BETA3) > > and today built BETA4 Kernel Panic mounting zfs Volumes. > > Booting single user mode I get output of zfs list and so on but > > mounting whatever volume also Panics. > > Why -f? Were there a poblem in importing pool? > > > Stack output, if there's more you need I'll gladly help > > http://i27.tinypic.com/2d78qpd.jpg > > http://i31.tinypic.com/oqhv2w.jpg > > http://i28.tinypic.com/oktsag.jpg > > Could you also provide top part of the backtrace? > Oh yeah my bad http://i29.tinypic.com/nqwxo2.jpg http://i26.tinypic.com/209hanm.jpg -- Tobias Lott From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 08:26:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9C3E106566B for ; Wed, 9 Sep 2009 08:26:31 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id EAFC28FC17 for ; Wed, 9 Sep 2009 08:26:30 +0000 (UTC) Received: (qmail 27330 invoked from network); 9 Sep 2009 08:26:28 -0000 Received: from unknown (HELO ale.andxor.it) (192.168.2.5) by andxor.it with SMTP; 9 Sep 2009 08:26:28 -0000 Message-ID: <4AA766B4.4080500@FreeBSD.org> Date: Wed, 09 Sep 2009 10:26:28 +0200 From: Alex Dupre User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: Sergey Vinogradov References: <4AA65ABE.4000207@lazybytes.org> <4AA668E0.1010305@FreeBSD.org> <4AA6ACF1.3040501@lazybytes.org> In-Reply-To: <4AA6ACF1.3040501@lazybytes.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ath(4) Atheros AR9285 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 08:26:31 -0000 Sergey Vinogradov ha scritto: > Well, despite the fact that "device ath", and all related stuff are > included in GENERIC kernel in 8.0-BETA4, I have no ath0 interface. > "dmesg | grep -i ath" gives nothing (well, as a matter of fact it gives > "alc0: ... ", but alc0 doesn't work > either, link handling is broken as I understand). Is there something I'm > doing wrong, or something I can do to help the development? :) Well, I have a board with an AR9280 (0x002a) and works fine OOTB. I had no experience with AR9285 (0x002b). #define AR9280_DEVID_PCIE 0x002a /* AR9280 PCI-E Merlin */ #define AR9285_DEVID_PCIE 0x002b /* AR9285 PCI-E Kite */ -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 08:45:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7159E1065672 for ; Wed, 9 Sep 2009 08:45:32 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout4.freenet.de (mout4.freenet.de [IPv6:2001:748:100:40::2:6]) by mx1.freebsd.org (Postfix) with ESMTP id 0ECB38FC19 for ; Wed, 9 Sep 2009 08:45:32 +0000 (UTC) Received: from [195.4.92.23] (helo=13.mx.freenet.de) by mout4.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1MlIny-0006II-RS; Wed, 09 Sep 2009 10:45:30 +0200 Received: from ted91.t.pppool.de ([89.55.237.145]:39307 helo=ernst.jennejohn.org) by 13.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1MlIny-0008Ch-G4; Wed, 09 Sep 2009 10:45:30 +0200 Date: Wed, 9 Sep 2009 10:45:28 +0200 From: Gary Jennejohn To: Lars Engels Message-ID: <20090909104528.20b28e65@ernst.jennejohn.org> In-Reply-To: <20090908201713.GD41185@e.0x20.net> References: <20090908201713.GD41185@e.0x20.net> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: CFH: fix multimedia/pwcbsd with usb2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 08:45:32 -0000 On Tue, 8 Sep 2009 22:17:13 +0200 Lars Engels wrote: > could someone with some more USB and C knowledge than me take a look at > multimedia/pwcbsd? > I'd really like to get the port fixed before the ports freeze starts. > Here is the compile output: > The patches under ~gj/work on freefall at least allow it to compile. I can't test whether it works, however. Let me know when you have them so I can delete them. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 10:07:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E09421065670 for ; Wed, 9 Sep 2009 10:07:09 +0000 (UTC) (envelope-from ziggi@yandex.ru) Received: from forward11.yandex.ru (forward11.yandex.ru [95.108.130.93]) by mx1.freebsd.org (Postfix) with ESMTP id 976028FC0C for ; Wed, 9 Sep 2009 10:07:09 +0000 (UTC) Received: from smtp11.yandex.ru (smtp11.yandex.ru [95.108.130.67]) by forward11.yandex.ru (Yandex) with ESMTP id B91D9F48E05; Wed, 9 Sep 2009 14:07:08 +0400 (MSD) Received: from eee.home (168-86-52-95.baltnet.ru [95.52.86.168]) by smtp11.yandex.ru (Yandex) with ESMTPA id 54F8C6730078; Wed, 9 Sep 2009 14:07:08 +0400 (MSD) Message-ID: <4AA77E4B.5060006@yandex.ru> Date: Wed, 09 Sep 2009 13:07:07 +0300 From: Borodin Oleg User-Agent: Thunderbird 2.0.0.22 (X11/20090806) MIME-Version: 1.0 To: sam@errno.com References: <4AA41025.5080908@yandex.ru> <4AA44B53.8060702@errno.com> In-Reply-To: <4AA44B53.8060702@errno.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: quoted-printable X-Yandex-TimeMark: 1252490828 X-Yandex-Spam: 1 X-Yandex-Front: smtp11.yandex.ru Cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant not found AP without SSID in beacon packet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 10:07:10 -0000 Sam Leffler =D0=C9=DB=C5=D4: > Borodin Oleg wrote: >> >> Hi! >> >> wpa_supplicant "not found" AP without SSID in beacon packets. With sam= e >> device and configuration, but FreeBSD7.2 - work without problems. >> >> > > You seem to have disabled scan_ssid in your wpa_supplicant.conf file.=20 > It appears this causes wpa_supplicant to not supply the ssid when=20 > scanning so the net80211 layer never sends directed ProbeRequest=20 > frames and then ap does not respond. Try enabling scan_ssid for WNET1 = > and verify the directed probe request frames are sent. > > Sam > _______________________________________________ > Of course, I tried to turn on and off scan_ssid. No results. I do not know much logic WiFI, perhaps the problem with disassembly=20 beacon packet of access point? Or, more likely to parse the answer to the AP on ProbeRequest from FBSD? What is?... wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id=20 133, len 30 --- Best regards, Borodin Oleg Kaliningrad,Russia ziggi@inbox.ru From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 11:56:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00F95106566B for ; Wed, 9 Sep 2009 11:56:03 +0000 (UTC) (envelope-from raul@pop.isdefe.es) Received: from mail1.isdefe.es (mail1.isdefe.es [194.15.213.239]) by mx1.freebsd.org (Postfix) with ESMTP id B85088FC14 for ; Wed, 9 Sep 2009 11:56:02 +0000 (UTC) Received: from mail1.isdefe.es (mail1.isdefe.es [127.0.0.1]) by localhost.isdefe.es (Postfix) with ESMTP id 33903316742; Wed, 9 Sep 2009 13:55:34 +0200 (CEST) Received: from [10.200.104.66] (unknown [10.200.104.66]) by mail1.isdefe.es (Postfix) with ESMTP id 26CF3316741; Wed, 9 Sep 2009 13:55:34 +0200 (CEST) Message-ID: <4AA797D1.9050409@pop.isdefe.es> Date: Wed, 09 Sep 2009 13:56:01 +0200 From: Raul User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Chris Ruiz References: <54854a7a0907150322n52a3595el5352a3987d2c75ac@mail.gmail.com> <58c737d70907151035ya9a829eyf4945d1fadc4ce0e@mail.gmail.com> <4A5EFFF7.4060708@pop.isdefe.es> In-Reply-To: <4A5EFFF7.4060708@pop.isdefe.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Tulloch , freebsd-current@freebsd.org Subject: Boot-time hang with the CISS driver on HP 385 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 11:56:03 -0000 I haven't had too much spare time to put on it so no idea how this boot hangs have been evolved. I've tried once again with yesterday's RELENG_8 sources with the same results except for the message from the kernel (safe boot): .... ciss0: PERFORMANT Transport ciss0: can't allocate interrupt panic: mtx_unlock() of spin mutex (null) @ /usr/src/sys/dev/ciss/ciss.c:1903 cpuid = 0 KBD: enter: panic .... Looking at bios, ciss has irq 7 and that interrupt is shared with iLO and bge0 ???. Trying to disable them, from bios, doesn't help. RELENG_7_2 run like a charm on that boxes. I've two of that boxes ready to test whatever you ask :). Regards, Raul From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 13:24:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C7061065676; Wed, 9 Sep 2009 13:24:25 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id F2F778FC0C; Wed, 9 Sep 2009 13:24:24 +0000 (UTC) Received: from [192.168.1.4] (adsl-146-128-114.bna.bellsouth.net [70.146.128.114]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n89DOMlf051469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Sep 2009 09:24:23 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Alexander Motin In-Reply-To: <1252440109.85394.2430.camel@balrog.2hip.net> References: <1252225381.00160049.1252212601@10.7.7.3> <4AA68C8A.4060405@FreeBSD.org> <1252440109.85394.2430.camel@balrog.2hip.net> Content-Type: text/plain Organization: FreeBSD Date: Wed, 09 Sep 2009 08:24:17 -0500 Message-Id: <1252502657.85394.3498.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Harald Schmalzbauer , freebsd-current@freebsd.org Subject: Re: Funding ODD support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 13:24:25 -0000 On Tue, 2009-09-08 at 15:01 -0500, Robert Noland wrote: > On Tue, 2009-09-08 at 19:55 +0300, Alexander Motin wrote: > > Harald Schmalzbauer wrote: > > > I'm looking for somebody who has time and knowledge to fix ODD support > > > in FreeBSD. > > > I'm willing to sponsor a decent ammount. > > > My problem is that I can't use FreeBSD for any task in which CD or DVD > > > is involved. > > > What I want is read/write support for any ATAPI/S-ATA ODD regarding > > > ISO9660 and audio. Of course I'd love to have UDF support also, but for > > > the beginning I'd be glad if FreeBSD could boot with an inserted audio > > > CD. This has been a problem for more than two years now, and disabling > > > DMA support for ata devices isn't a satisfying solution. > > > > > > So if you think ypu can fix this and make growisofs and cdrtools working > > > with ATAPI and SATA devices, please contact me. > > > If we have working ODD support in 8.0-release I'll donate 100 extra bucks. > > > > Funding is good, but could you first once more repeat what is your > > problem? Which controller do you use? Which drive? Which disks and which > > applications? Have you tried to use different controllers, drives, > > disks, applications? I am asking because there quite a lot of people > > successfully using ODD on FreeBSD. > > FWIW, some of the recent changes do seem to have broken things a bit for > me... But I can't quite put my finger on where the breakage is. Some > apps seem to work, depending on media, while other don't (that used to). > For example I can burn a data DVD using tkdvd, but not brasero. brasero > does seem to be able to burn data cds, though I'm getting horrible > throughput which I don't understand. (I seem to max at about 4x writing > cds on a 48x cd burner, IIRC). I haven't found any tool that is able to > write a DL dvd, currently. Ok, update... After some prodding, I installed k3b which did successfully burn a DL DVD. It uses growisofs on the backend, which I did try a week or so ago and it wasn't working. Tkdvd also uses growisofs, so I presume that it would work now as well. brasero still wasn't working yesterday, at least for DL, but I have been trying to periodically rebuild it with and without libburn, so it might be a bit confused now. At any rate I assume that the cam/ata fixes in my latest kernel got growisofs working correctly again. robert. > robert. -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 14:30:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D618210656A6 for ; Wed, 9 Sep 2009 14:30:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 69A288FC08 for ; Wed, 9 Sep 2009 14:30:46 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=QYI-qAVWAz4A:10 a=p7f755yT8wqfGVF+fg83Lg==:17 a=n_Us5D14OKZnVfoTeY0A:9 a=K08Wsr6wO5W3h5bamnPTMff7jaMA:4 Received: from [212.4.54.130] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1316994089; Wed, 09 Sep 2009 16:30:45 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 9 Sep 2009 16:31:00 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: In-Reply-To: X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909091631.01446.hselasky@c2i.net> Cc: James Butler Subject: Re: Fwd: Can't boot 8.0-BETA4 from USB stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 14:30:47 -0000 On Tuesday 08 September 2009 23:45:00 James Butler wrote: > I have tried on all the ports at the back of the box, but I just > remembered there's another at the front which I will try this evening. > What do you mean by "dummy USB device"? Just having something else > plugged in at boot? I will also try another USB drive tonight. Yes. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 14:44:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75A2C106568D for ; Wed, 9 Sep 2009 14:44:02 +0000 (UTC) (envelope-from universite@ukr.net) Received: from mary-teresa.otrada.od.ua (universite.broker.freenet6.net [IPv6:2001:5c0:1400:b::27e9]) by mx1.freebsd.org (Postfix) with ESMTP id EDB538FC13 for ; Wed, 9 Sep 2009 14:43:59 +0000 (UTC) Received: from phenom (mary-teresa.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by mary-teresa.otrada.od.ua (8.14.3/8.14.3) with ESMTP id n89EhtIj005155 for ; Wed, 9 Sep 2009 17:43:55 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: mary-teresa.otrada.od.ua: Host mary-teresa.otrada.od.ua [10.0.0.10] claimed to be phenom X-AntiVirus: Checked by Dr.Web [version: 5.0, engine: 5.00.0.12182, virus records: 632302, updated: 8.09.2009] Message-ID: <4AA7BF29.9050801@ukr.net> Date: Wed, 09 Sep 2009 17:43:53 +0300 From: "Vladislav V. Prodan" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua Subject: kern/138666: Do not working multicast through igmpproxy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 14:44:02 -0000 >Number: 138666 >Category: kern >Synopsis: Do not working multicast through igmpproxy >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 09 14:40:01 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Vladislav V. Prodan >Release: FreeBSD 8.0-BETA4 #0: Wed Sep 9 00:53:41 EEST 2009 amd64 >Organization: >Environment: FreeBSD mary-teresa.otrada.od.ua 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Wed Sep 9 00:53:41 EEST 2009 vlad11@mary-teresa.otrada.od.ua:/usr/obj/usr/src/sys/mary-teresa.17 amd64 >Description: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff803fbed5 stack pointer = 0x28:0xffffff8000041ab0 frame pointer = 0x28:0xffffff8000041ad0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock) trap number = 9 panic: general protection fault cpuid = 0 Uptime: 2h38m8s Physical memory: 6098 MB Dumping 1653 MB: 1638 1622 1606 1590 1574 1558 1542 1526 1510 1494 1478 1462 1446 1430 1414 1398 1382 1366 1350 1334 1318 1302 1286 1270 1254 1238 1222 1206 1190 1174 1158 1142 1126 1110 1094 1078 1062 1046 1030 1014 998 982 966 950 934 918 902 886 870 854 838 822 806 790 774 758 742 726 710 694 678 662 646 630 614 598 582 566 550 534 518 502 486 470 454 438 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko 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/accf_http.ko...Reading symbols from /boot/kernel/accf_http.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_http.ko #0 doadump () at pcpu.h:223 223 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff803a5219 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff803a566c in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xffffffff8065e30d in trap_fatal (frame=0x9, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:852 #4 0xffffffff8065ee4a in trap (frame=0xffffff8000041a00) at /usr/src/sys/amd64/amd64/trap.c:639 #5 0xffffffff80645463 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #6 0xffffffff803fbed5 in m_freem (mb=0xc9e5894807b70f55) at /usr/src/sys/kern/uipc_mbuf.c:160 #7 0xffffffff804d9e92 in expire_mfc (rt=0xffffff01420d4b00) at /usr/src/sys/netinet/ip_mroute.c:1031 #8 0xffffffff804db344 in expire_upcalls (unused=Variable "unused" is not available. ) at /usr/src/sys/netinet/ip_mroute.c:1457 #9 0xffffffff803b7dc1 in softclock (arg=Variable "arg" is not available. ) at /usr/src/sys/kern/kern_timeout.c:411 #10 0xffffffff8037f380 in intr_event_execute_handlers (p=Variable "p" is not available. ) at /usr/src/sys/kern/kern_intr.c:1165 #11 0xffffffff803808fe in ithread_loop (arg=0xffffff0001392660) at /usr/src/sys/kern/kern_intr.c:1178 #12 0xffffffff8037d387 in fork_exit (callout=0xffffffff80380870 , arg=0xffffff0001392660, frame=0xffffff8000041c80) at /usr/src/sys/kern/kern_fork.c:843 #13 0xffffffff8064593e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:561 #14 0x0000000000000000 in ?? () #15 0x0000000000000000 in ?? () #16 0x0000000000000001 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () ---Type to continue, or q to quit--- #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000c6d000 in ?? () #39 0x000000000000000b in ?? () #40 0xffffffff808cf500 in affinity () #41 0xffffffff808cf500 in affinity () #42 0xffffff000150d720 in ?? () #43 0xffffff8000041240 in ?? () #44 0xffffff80000411f8 in ?? () #45 0xffffff00013a7390 in ?? () #46 0xffffffff803c8159 in sched_switch (td=0xffffff0001392660, newtd=0xffffffff80380870, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1858 Previous frame inner to this frame (corrupt stack?) Igmpproxy (/usr/ports/net/igmpproxy) logs: Sep 9 16:56:18 mary-teresa igmpproxy: Debu: Packet from 10.0.0.1: proto: 2 hdrlen: 24 iplen: 8 or 2048 Sep 9 16:56:18 mary-teresa igmpproxy: Note: RECV V2 member report from 10.0.0.1 to 224.0.0.2 (ip_hl 24, data 8) Sep 9 16:56:18 mary-teresa igmpproxy: Note: The IGMP message was from myself. Ignoring. Sep 9 16:56:19 mary-teresa igmpproxy: Debu: Packet from 10.0.0.10: proto: 2 hdrlen: 24 iplen: 8 or 2048 Sep 9 16:56:19 mary-teresa igmpproxy: Note: RECV Leave message from 10.0.0.10 to 224.0.0.2 (ip_hl 24, data 8) Sep 9 16:56:19 mary-teresa igmpproxy: Debu: Got leave message from 10.0.0.10 to 239.0.1.41. Starting last member detection. Sep 9 16:56:19 mary-teresa igmpproxy: Debu: SENT Membership query from 10.0.0.1 to 239.0.1.41 Sep 9 16:56:19 mary-teresa igmpproxy: Debu: Sent membership query from 10.0.0.1 to 239.0.1.41. Delay: 10 Sep 9 16:56:19 mary-teresa igmpproxy: Debu: Created timeout 14 (#1) - delay 4 secs Sep 9 16:56:19 mary-teresa igmpproxy: Debu: (Id:12, Time:6) Sep 9 16:56:19 mary-teresa igmpproxy: Debu: (Id:14, Time:4) Sep 9 16:56:19 mary-teresa igmpproxy: Debu: (Id:13, Time:111) Sep 9 16:56:24 mary-teresa igmpproxy: Debu: About to call timeout 12 (#0) Sep 9 16:56:24 mary-teresa igmpproxy: Debu: Aging routes in table. Sep 9 16:56:24 mary-teresa igmpproxy: Debu: Current routing table (Age active routes); ----------------------------------------------------- Sep 9 16:56:24 mary-teresa igmpproxy: Debu: No routes in table... Sep 9 16:56:24 mary-teresa igmpproxy: Debu: ----------------------------------------------------- Sep 9 16:56:28 mary-teresa igmpproxy: Debu: About to call timeout 14 (#0) Sep 9 16:56:32 mary-teresa igmpproxy: Debu: Route activate request from 10.0.0.10 to 239.192.152.143, downIf -1 Sep 9 16:56:32 mary-teresa igmpproxy: Debu: No table entry for 239.192.152.143 [From: 10.0.0.10]. Inserting route. Sep 9 16:56:32 mary-teresa igmpproxy: Debu: No existing route for 239.192.152.143. Create new. Sep 9 16:56:32 mary-teresa igmpproxy: Debu: No routes in table. Insert at beginning. Sep 9 16:56:32 mary-teresa igmpproxy: Info: Inserted route table entry for 239.192.152.143 on VIF #-1 Sep 9 16:56:32 mary-teresa igmpproxy: Debu: No downstream listeners for group 239.192.152.143. No join sent. Sep 9 16:56:32 mary-teresa igmpproxy: Debu: Current routing table (Insert Route); ----------------------------------------------------- Sep 9 16:56:32 mary-teresa igmpproxy: Debu: #0: Dst: 239.192.152.143, Age:2, St: I, OutVifs: 0x00000000 Sep 9 16:56:32 mary-teresa igmpproxy: Debu: ----------------------------------------------------- Sep 9 16:56:32 mary-teresa igmpproxy: Note: New origin for route 239.192.152.143 is 10.0.0.10, flood -1 Sep 9 16:56:32 mary-teresa igmpproxy: Debu: Current routing table (Activate Route); ----------------------------------------------------- Sep 9 16:56:32 mary-teresa igmpproxy: Debu: #0: Dst: 239.192.152.143, Age:2, St: A, OutVifs: 0x00000000 Sep 9 16:56:32 mary-teresa igmpproxy: Debu: #0: Origin: 10.0.0.10 floodIf -1 pktcnt 0 Sep 9 16:56:32 mary-teresa igmpproxy: Debu: ----------------------------------------------------- 239.192.152.143 - multicast TV 10.0.0.1 - freebsd, local network interface 10.0.0.10 - windows XP, running TV-player kernel mrouting included: options MROUTING # Multicast routing >How-To-Repeat: 1\ install Igmpproxy (/usr/ports/net/igmpproxy) 2\ run Igmpproxy 3\ a couple of times to switch channels 4\ after 5 minutes will be a stable kernel panic I suspect the problem in the routes, both for work with local interfaces, and for multicast. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 14:44:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B251106566C; Wed, 9 Sep 2009 14:44:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0C63E8FC20; Wed, 9 Sep 2009 14:44:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n89Eiapp004172; Wed, 9 Sep 2009 10:44:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n89EiaTE004165; Wed, 9 Sep 2009 14:44:36 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 9 Sep 2009 14:44:36 GMT Message-Id: <200909091444.n89EiaTE004165@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 14:44:37 -0000 TB --- 2009-09-09 13:45:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-09 13:45:00 - starting HEAD tinderbox run for i386/i386 TB --- 2009-09-09 13:45:00 - cleaning the object tree TB --- 2009-09-09 13:45:50 - cvsupping the source tree TB --- 2009-09-09 13:45:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2009-09-09 13:47:09 - building world TB --- 2009-09-09 13:47:09 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-09 13:47:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-09 13:47:09 - TARGET=i386 TB --- 2009-09-09 13:47:09 - TARGET_ARCH=i386 TB --- 2009-09-09 13:47:09 - TZ=UTC TB --- 2009-09-09 13:47:09 - __MAKE_CONF=/dev/null TB --- 2009-09-09 13:47:09 - cd /src TB --- 2009-09-09 13:47:09 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 9 13:47:10 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/share/man/man4/man4.i386/apm.4 > apm.4.gz gzip -cn /src/share/man/man4/man4.i386/ce.4 > ce.4.gz gzip -cn /src/share/man/man4/man4.i386/cp.4 > cp.4.gz gzip -cn /src/share/man/man4/man4.i386/CPU_ELAN.4 > CPU_ELAN.4.gz gzip -cn /src/share/man/man4/man4.i386/cs.4 > cs.4.gz gzip -cn /src/share/man/man4/man4.i386/ct.4 > ct.4.gz gzip -cn /src/share/man/man4/man4.i386/ctau.4 > ctau.4.gz make: don't know how to make dpms.4. Stop *** Error code 2 Stop in /src/share/man/man4. *** Error code 1 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-09 14:44:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-09 14:44:36 - ERROR: failed to build world TB --- 2009-09-09 14:44:36 - 2365.28 user 377.45 system 3575.71 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 14:51:12 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3089A106568F; Wed, 9 Sep 2009 14:51:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D53B98FC0A; Wed, 9 Sep 2009 14:51:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n89EpBv0048620; Wed, 9 Sep 2009 10:51:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n89EpBUd048609; Wed, 9 Sep 2009 14:51:11 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 9 Sep 2009 14:51:11 GMT Message-Id: <200909091451.n89EpBUd048609@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 14:51:12 -0000 TB --- 2009-09-09 13:45:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-09 13:45:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-09-09 13:45:00 - cleaning the object tree TB --- 2009-09-09 13:46:10 - cvsupping the source tree TB --- 2009-09-09 13:46:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-09-09 13:51:57 - building world TB --- 2009-09-09 13:51:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-09 13:51:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-09 13:51:57 - TARGET=pc98 TB --- 2009-09-09 13:51:57 - TARGET_ARCH=i386 TB --- 2009-09-09 13:51:57 - TZ=UTC TB --- 2009-09-09 13:51:57 - __MAKE_CONF=/dev/null TB --- 2009-09-09 13:51:57 - cd /src TB --- 2009-09-09 13:51:57 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 9 13:51:58 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/share/man/man4/man4.i386/apm.4 > apm.4.gz gzip -cn /src/share/man/man4/man4.i386/ce.4 > ce.4.gz gzip -cn /src/share/man/man4/man4.i386/cp.4 > cp.4.gz gzip -cn /src/share/man/man4/man4.i386/CPU_ELAN.4 > CPU_ELAN.4.gz gzip -cn /src/share/man/man4/man4.i386/cs.4 > cs.4.gz gzip -cn /src/share/man/man4/man4.i386/ct.4 > ct.4.gz gzip -cn /src/share/man/man4/man4.i386/ctau.4 > ctau.4.gz make: don't know how to make dpms.4. Stop *** Error code 2 Stop in /src/share/man/man4. *** Error code 1 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-09 14:51:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-09 14:51:11 - ERROR: failed to build world TB --- 2009-09-09 14:51:11 - 2369.03 user 390.11 system 3970.46 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 15:28:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0020D1065670 for ; Wed, 9 Sep 2009 15:28:58 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id B463D8FC21 for ; Wed, 9 Sep 2009 15:28:58 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlP6P-000CT5-AC for freebsd-current@freebsd.org; Wed, 09 Sep 2009 17:28:57 +0200 Date: Wed, 9 Sep 2009 17:28:57 +0200 From: Kurt Jaeger To: freebsd-current@freebsd.org Message-ID: <20090909152857.GD48206@home.opsec.eu> References: <1252225381.00160049.1252212601@10.7.7.3> <4AA68C8A.4060405@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AA68C8A.4060405@FreeBSD.org> Subject: Re: Funding ODD support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:28:59 -0000 Hi! > Funding is good, but could you first once more repeat what is your > problem? Example: Yesterday, I burned FreeNAS-amd64-embedded-0.7RC1.4735.img using burncd -f /dev/acd0 data FreeNAS-amd64-embedded-0.7RC1.4735.img fixate on a FreeBSD amd64 7.2-RELEASE to a CD. Guess what happened ? My computer crashed during/after fixate 8-( More details available on request. Reason (probably): That file is no ISO-File. Fine, but this should not kill my computer. Yes, I'm willing to fund a part of this effort (100-200 EUR). -- pi@opsec.eu +49 171 3101372 11 years to go ! From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 15:36:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E73FA1065676 for ; Wed, 9 Sep 2009 15:36:20 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-yw0-f180.google.com (mail-yw0-f180.google.com [209.85.211.180]) by mx1.freebsd.org (Postfix) with ESMTP id 9CDAC8FC16 for ; Wed, 9 Sep 2009 15:36:20 +0000 (UTC) Received: by ywh10 with SMTP id 10so9158712ywh.7 for ; Wed, 09 Sep 2009 08:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lUI8rW/nxgaHr0gl4nsHdDC8OT6deUtPp4f85vs4AFg=; b=J2bJ2cnKjzhE7Vb39djBSpYe3Le2pKPbA6T1NBAnQ3IQ+Um90Dn9i/PrhF7eSKSnSh 968nCaPaL7xkbHj6h16hSrhyQvDXjIumbDVThEJPkPIOkBW5+CuV84rFWBbiUwpkiJun 7RDeMuOtOyrzqk3USHplISEl8IryeQWeEXAh4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=x1cxL3q1F5XITiracILxsEVUbUT3iNs4EDyD7L9Q56+wmViqgmyN+0BQ9FLf0Rt9H0 yraLpga/QP0jxBTsdFGuHmyPBQ8HYTu9ynvPdUkRpWb3awIyzHaB6KHTCiYpw27jRpIW q4bMyj2rRjTG3suAho4nEg0xA2Tz8aucQHXlA= MIME-Version: 1.0 Received: by 10.101.88.14 with SMTP id q14mr345580anl.38.1252508856497; Wed, 09 Sep 2009 08:07:36 -0700 (PDT) In-Reply-To: <7147C6D9FE26411197548D67E5025D75@multiplay.co.uk> References: <7147C6D9FE26411197548D67E5025D75@multiplay.co.uk> Date: Wed, 9 Sep 2009 17:07:36 +0200 Message-ID: From: Jacques Fourie To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stuart cur , freebsd-current@freebsd.org Subject: Re: 8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:36:21 -0000 On Tue, Sep 8, 2009 at 7:13 PM, Steven Hartland wr= ote: > I suspect its the same reason for issues with had with the subjects: > FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade > kern/134658: [bce] bce driver fails on PowerEdge m610 blade. > Quote: "David Christensen" > > I've enquired about this recently but havent seen a response as > yet. > > =A0 Regards > =A0 Steve > >> Sorry, this is the 5709S and I haven't had an opportunity to >> implement this PHY yet. =A0Unfortunately it's more than just a >> change to miidevs since the SerDes is actually an IEEE clause >> 45 compliant device (instead of the more common Clause 22 devices found = in >> 1GbE controllers). =A0The registers are diffrerent so the effort is more >> substantial. =A0No estimate >> yet on when I can get to it. > > ----- Original Message ----- From: "stuart cur" > > To: > Sent: Tuesday, September 08, 2009 5:32 PM > Subject: 8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64 > > >> In 8.0-B4 for amd64, bge does not recognize that there is an active >> ethernet connection on bge0. =A0Switching the cable to bge1 works correc= tly. >> >> This seems to be the same issue as reported on July 21 by Oyvind Rakvag, >> but I saw no response to that report. >> >> Attached are the dmesg.boot, /var/log/messages, and output of pciconf -l= v >> from the very first boot. >> >> stu > > > >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. and t= he > person or entity to whom it is addressed. In the event of misdirection, t= he > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > I experienced a similar issue with two 5787M based devices. If I disable gigabit advertisements for auto negotiation everything worked OK. With gigabit advertisements enabled, the auto negotiation got stuck in the next-page-wait state. The problem only occurs on the bge0 device. The bge1 device works with the gigabit advertisements enabled but ifconfig reports that the link is up at 100baseTX while it seems to be 1000baseT. Regards, Jacques From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 15:46:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52D17106566B for ; Wed, 9 Sep 2009 15:46:24 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 73DE58FC0C for ; Wed, 9 Sep 2009 15:46:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA27433; Wed, 09 Sep 2009 18:46:17 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4AA7CDC8.1060806@icyb.net.ua> Date: Wed, 09 Sep 2009 18:46:16 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: Kurt Jaeger References: <1252225381.00160049.1252212601@10.7.7.3> <4AA68C8A.4060405@FreeBSD.org> <20090909152857.GD48206@home.opsec.eu> In-Reply-To: <20090909152857.GD48206@home.opsec.eu> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Funding ODD support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:46:24 -0000 on 09/09/2009 18:28 Kurt Jaeger said the following: [snip] > on a FreeBSD amd64 7.2-RELEASE to a CD. Guess what happened ? My > computer crashed during/after fixate 8-( > > More details available on request. Hmm, I'd think that if one is interested in having a problem fixed the he'd be pro-active in providing details about the problem. Of course, I mean useful details like stack trace and other crash dump info. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 16:32:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9591A1065698 for ; Wed, 9 Sep 2009 16:32:12 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from www61.your-server.de (www61.your-server.de [213.133.104.61]) by mx1.freebsd.org (Postfix) with ESMTP id DC5AE8FC13 for ; Wed, 9 Sep 2009 16:32:11 +0000 (UTC) Received: from [217.7.243.216] (helo=firewall.demig.intra) by www61.your-server.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MlPqP-0004Qe-FF for freebsd-current@freebsd.org; Wed, 09 Sep 2009 18:16:29 +0200 Received: from [192.168.148.83] (ws-pr-3a.demig.intra [192.168.148.83]) by firewall.demig.intra (8.14.3/8.14.0) with ESMTP id n89GFsMa028480 for ; Wed, 9 Sep 2009 18:15:54 +0200 (CEST) (envelope-from nkoch@demig.de) Message-ID: <4AA7D4BA.40002@demig.de> Date: Wed, 09 Sep 2009 18:15:54 +0200 From: Norbert Koch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.64 on 192.168.148.235 X-Authenticated-Sender: webmaster@demig.de X-Virus-Scanned: Clear (ClamAV 0.95.1/9789/Wed Sep 9 17:39:23 2009) Subject: lock order reversal etc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 16:32:12 -0000 Hello. Is this the right mailing list to post kernel stack traces from Freebsd-8-BETA4? If yes, see below, otherwise just ignore this message. Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-BETA4 #0: Wed Sep 9 09:07:30 CEST 2009 root@entw-pr2.demig.intra:/usr/obj/usr/src/sys/ENTW-PR2 WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz (2407.32-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 1035853824 (987 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xfd000000-0xfdffffff,0xc0000000-0xcfffffff,0xfc000000-0xfcffffff irq 16 at device 0.0 on pci1 uhci0: port 0xdc00-0xdc1f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f00 usbus0: on uhci0 uhci1: port 0xe000-0xe01f irq 17 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f00 usbus1: on uhci1 ehci0: mem 0xfebffc00-0xfebfffff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 pci0: at device 27.0 (no driver attached) pcib2: irq 16 at device 28.0 on pci0 pci4: on pcib2 pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 re0: port 0xa800-0xa8ff mem 0xfe9ff000-0xfe9fffff irq 19 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1d:60:76:0d:a3 re0: [FILTER] pcib4: irq 16 at device 28.4 on pci0 pci2: on pcib4 atapci0: port 0x9c00-0x9c07,0x9880-0x9883,0x9800-0x9807,0x9480-0x9483,0x9400-0x940f mem 0xfe8fe000-0xfe8fffff irq 16 at device 0.0 on pci2 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI v1.00 controller with 2 3Gbps ports, PM supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] uhci2: port 0xd480-0xd49f irq 23 at device 29.0 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0f00 usbus3: on uhci2 uhci3: port 0xd800-0xd81f irq 19 at device 29.1 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0f00 usbus4: on uhci3 uhci4: port 0xd880-0xd89f irq 18 at device 29.2 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x0f00 usbus5: on uhci4 ehci1: mem 0xfebff800-0xfebffbff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: on ehci1 pcib5: at device 30.0 on pci0 pci5: on pcib5 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xbc00-0xbc7f mem 0xfeaffc00-0xfeaffc7f irq 21 at device 0.0 on pci5 miibus1: on xl0 ukphy0: PHY 24 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:0a:5e:04:dc:62 xl0: [ITHREAD] atapci1: port 0xb880-0xb887,0xb800-0xb803,0xb480-0xb487,0xb400-0xb403,0xb080-0xb08f mem 0xfeaf8000-0xfeafbfff irq 22 at device 1.0 on pci5 atapci1: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ata6: on atapci1 ata6: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci2: port 0xec00-0xec07,0xe880-0xe883,0xe800-0xe807,0xe480-0xe483,0xe400-0xe40f,0xe080-0xe08f irq 19 at device 31.2 on pci0 atapci2: [ITHREAD] ata7: on atapci2 ata7: [ITHREAD] ata8: on atapci2 ata8: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci3: port 0xd400-0xd407,0xd080-0xd083,0xd000-0xd007,0xcc00-0xcc03,0xc880-0xc88f,0xc800-0xc80f irq 19 at device 31.5 on pci0 atapci3: [ITHREAD] ata9: on atapci3 ata9: [ITHREAD] ata10: on atapci3 ata10: [ITHREAD] acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] ACPI Warning: \\_SB_.PCI0.SBRG.FDC_._FDE: Return type mismatch - found Package, expected Buffer 20090521 nspredef-1051 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 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 Generic PS/2 mouse, device ID 0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 27, should be 1A 20090521 tbutils-275 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xd2000-0xd27ff,0xd2800-0xd4fff 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 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 acd0: DVDROM at ata4-master PIO4 ad10: 239372MB at ata5-master UDMA100 ad12: 239372MB at ata6-master UDMA100 ar0: 239372MB status: READY ar0: disk0 READY (master) using ad10 at ata5-master ar0: disk1 READY (mirror) using ad12 at ata6-master SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered GEOM: ad10: geometry does not match label (255h,63s != 16h,63s). GEOM: ad10: media size does not match label. GEOM: ad12: geometry does not match label (255h,63s != 16h,63s). GEOM: ad12: media size does not match label. Root mount waiting for: usbus6 usbus2 uhub2: 4 ports with 4 removable, self powered uhub6: 6 ports with 6 removable, self powered Trying to mount root from ufs:/dev/ar0a uma_zalloc_arg: zone "64" with the following non-sleepable locks held: exclusive sleep mutex jail mutex (jail mutex) r = 0 (0xc0b91328) locked @ /usr/src/sys/modules/syscons/daemon/../../../dev/syscons/daemon/daemon_saver.c:355 KDB: stack backtrace: db_trace_self_wrapper(c0abf50f,e69b391c,c07ab3b5,c4a0580a,163,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c4a0580a,163,ffffffff,c0d261c4,e69b3954,...) at kdb_backtrace+0x29 _witness_debugger(c0ac198e,e69b3968,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0ae4b92,c0add27b,e69b3984,...) at witness_warn+0x1fd uma_zalloc_arg(c148b000,0,2,2,14,...) at uma_zalloc_arg+0x34 malloc(29,c0b92dd0,2,163,c46562e4,...) at malloc+0xe4 daemon_init(c0d61940,c0aba83e,e69b3a28,c46f5600,c4a06cc0,...) at daemon_init+0x7b splash_test(7b,c46f5600,c4a06cc0,c46f5600,e69b3a50,...) at splash_test+0x91 splash_register(c4a06c40,0,0,76,0,...) at splash_register+0x48 module_register_init(c4a06cc0,0,c0ab8be2,e4,0,...) at module_register_init+0xa7 linker_load_module(0,e69b3c48,c0ab8be2,3f7,0,...) at linker_load_module+0x9fa kern_kldload(c4656240,c43d9c00,e69b3c70,0,33d,...) at kern_kldload+0xca kldload(c4656240,e69b3cf8,4,c,c0b8eb80,...) at kldload+0x74 syscall(e69b3d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (304, FreeBSD ELF32, kldload), eip = 0x280d6ddb, esp = 0xbfbfe94c, ebp = 0xbfbfee38 --- IPv4 address: "192.168.1.191" is not on the network pid 1275 (xfce4-settings-help), uid 1000: exited on signal 11 (core dumped) lock order reversal: 1st 0xc4afca2c filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1088 2nd 0xc4be3488 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4091 KDB: stack backtrace: db_trace_self_wrapper(c0abf50f,e6975a2c,c07ab3b5,c079c13b,c0ac23e2,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c079c13b,c0ac23e2,c4123168,c4126290,e6975a88,...) at kdb_backtrace+0x29 _witness_debugger(c0ac23e2,c4be3488,c0ab4f66,c4126290,c0ac96be,...) at _witness_debugger+0x25 witness_checkorder(c4be3488,9,c0ac96be,ffb,c4be34a4,...) at witness_checkorder+0x839 __lockmgr_args(c4be3488,80400,c4be34a4,0,0,...) at __lockmgr_args+0x7a7 ffs_lock(e6975b98,4,0,80400,c4be3430,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0bae360,e6975b98,c0ab7180,c0bc5660,c4be3430,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c4be3430,80400,c0ac96be,ffb,e6975bf4,...) at _vn_lock+0x5e vfs_knllock(c4be3430,0,c0ab7180,696,c4e7d110,...) at vfs_knllock+0x29 knlist_remove_kq(0,e6975c14,c07f69f9,c4dcdd78,c4e7d110,...) at knlist_remove_kq+0x85 knlist_remove(c4dcdd78,c4e7d110,0,e6975c40,c0739c35,...) at knlist_remove+0x1b filt_vfsdetach(c4e7d110,0,c0ab7180,777,d,...) at filt_vfsdetach+0x39 knote_fdclose(c4686b40,4cd,c0ab6cc3,440,c4afca2c,...) at knote_fdclose+0xf5 kern_close(c4686b40,4cd,e6975d2c,c0a2e883,c4686b40,...) at kern_close+0xd2 close(c4686b40,e6975cf8,4,c0ac2cbd,c0b8cae8,...) at close+0x1a syscall(e6975d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x2837b3d3, esp = 0xbfbfe5bc, ebp = 0xbfbfe5d8 --- IPv4 address: "192.168.1.191" is not on the network IPv4 address: "192.168.1.191" is not on the network lock order reversal: 1st 0xd82d03f0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 2nd 0xc4f64800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper(c0abf50f,e6a5b850,c07ab3b5,c079c13b,c0ac23e2,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c079c13b,c0ac23e2,c4122e90,c41262f8,e6a5b8ac,...) at kdb_backtrace+0x29 _witness_debugger(c0ac23e2,c4f64800,c0ae35e8,c41262f8,c0ae3281,...) at _witness_debugger+0x25 witness_checkorder(c4f64800,9,c0ae3281,11d,0,...) at witness_checkorder+0x839 _sx_xlock(c4f64800,0,c0ae3281,11d,c512fb54,...) at _sx_xlock+0x85 ufsdirhash_acquire(d82d0390,de0b7800,200,de0b783c,e6a5b97c,...) at ufsdirhash_acquire+0x35 ufsdirhash_add(c512fb54,e6a5ba0c,83c,e6a5b968,e6a5b96c,...) at ufsdirhash_add+0x13 ufs_direnter(c5167218,0,e6a5ba0c,e6a5bba0,0,...) at ufs_direnter+0x729 ufs_rename(e6a5bc1c,0,c51b7b84,e6a5bbc8,0,...) at ufs_rename+0x717 VOP_RENAME_APV(c0bae360,e6a5bc1c,0,1,e6a5bba0,...) at VOP_RENAME_APV+0xa5 kern_renameat(c4a2f900,ffffff9c,2992b3a0,ffffff9c,29922880,...) at kern_renameat+0x307 kern_rename(c4a2f900,2992b3a0,29922880,0,e6a5bd2c,...) at kern_rename+0x36 rename(c4a2f900,e6a5bcf8,8,c0addc93,c0b8d840,...) at rename+0x29 syscall(e6a5bd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (128, FreeBSD ELF32, rename), eip = 0x2954475b, esp = 0xbfbf98dc, ebp = 0xbfbf9988 --- IPv4 address: "192.168.1.191" is not on the network lock order reversal: 1st 0xc464337c ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 2nd 0xd81d14b0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6177 3rd 0xc673a7ac ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self_wrapper(c0abf50f,e6b103cc,c07ab3b5,c079c13b,c0ac23fb,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c079c13b,c0ac23fb,c4122e90,c4126290,e6b10428,...) at kdb_backtrace+0x29 _witness_debugger(c0ac23fb,c673a7ac,c0ab4f66,c4126290,c0ac96be,...) at _witness_debugger+0x25 witness_checkorder(c673a7ac,9,c0ac96be,823,0,...) at witness_checkorder+0x839 __lockmgr_args(c673a7ac,80100,c673a7c8,0,0,...) at __lockmgr_args+0x7a7 ffs_lock(e6b10538,c07ab15b,c0ac8bb1,80100,c673a754,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0bae360,e6b10538,c4c08524,c0bc5660,c673a754,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c673a754,80100,c0ac96be,823,4,...) at _vn_lock+0x5e vget(c673a754,80100,c4c08480,50,0,...) at vget+0xb9 vfs_hash_get(c46e1508,18ef074,80000,c4c08480,e6b10694,...) at vfs_hash_get+0xe6 ffs_vgetf(c46e1508,18ef074,80000,e6b10694,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c4643324,0,c0ae2efa,146,0,...) at softdep_sync_metadata+0x5ba ffs_syncvnode(c4643324,1,c0abaa2c,c0ab45da,3,...) at ffs_syncvnode+0x3e2 ffs_truncate(c4643324,600,0,880,c465d280,...) at ffs_truncate+0x66a ufs_direnter(c4643324,c673a754,e6b10a1c,e6b10c00,d82ec1d0,...) at ufs_direnter+0x8f6 ufs_mkdir(e6b10c28,e6b10c3c,0,0,e6b10b6c,...) at ufs_mkdir+0x8a7 VOP_MKDIR_APV(c0bae360,e6b10c28,e6b10c00,e6b10b6c,0,...) at VOP_MKDIR_APV+0xa5 kern_mkdirat(c4c08480,ffffff9c,804c2e8,0,41fd,...) at kern_mkdirat+0x22b kern_mkdir(c4c08480,804c2e8,0,41fd,e6b10d2c,...) at kern_mkdir+0x2e mkdir(c4c08480,e6b10cf8,8,c0ac2cbd,c0b8d920,...) at mkdir+0x29 syscall(e6b10d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (136, FreeBSD ELF32, mkdir), eip = 0x2816c973, esp = 0xbfbfe5cc, ebp = 0xbfbfe748 --- -- *********************************************************************** * demig Prozessautomatisierung GmbH * demig Anlagentechnik GmbH * * * * * Anschrift: Haardtstrasse 40 * Haardtstrasse 40 * * D-57076 Siegen * D-57076 Siegen * * Registergericht: Siegen HRB 2819 * Siegen HRB 5532 * * Geschaeftsfuehrer: Joachim Herbst, * Joachim Herbst, * * Winfried Held * Winfried Held * * Telefon: +49 271 772020 * +49 271 772020 * * Telefax: +49 271 74704 * +49 271 74704 * * E-Mail: info@demig.de * at@demig.de * * http://www.demig.de * http://www.demig.de * *********************************************************************** From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 15:58:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDEFD106566B for ; Wed, 9 Sep 2009 15:58:13 +0000 (UTC) (envelope-from pilists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8AA508FC15 for ; Wed, 9 Sep 2009 15:58:13 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlPYj-000CZo-W9 for freebsd-current@freebsd.org; Wed, 09 Sep 2009 17:58:13 +0200 Date: Wed, 9 Sep 2009 17:58:13 +0200 From: Kurt Jaeger To: freebsd-current@freebsd.org Message-ID: <20090909155813.GF48206@home.opsec.eu> References: <1252225381.00160049.1252212601@10.7.7.3> <4AA68C8A.4060405@FreeBSD.org> <20090909152857.GD48206@home.opsec.eu> <4AA7CDC8.1060806@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AA7CDC8.1060806@icyb.net.ua> X-Mailman-Approved-At: Wed, 09 Sep 2009 17:38:10 +0000 Subject: Re: Funding ODD support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:58:14 -0000 Hi! > on 09/09/2009 18:28 Kurt Jaeger said the following: > [snip] > > on a FreeBSD amd64 7.2-RELEASE to a CD. Guess what happened ? My > > computer crashed during/after fixate 8-( > > > > More details available on request. > > Hmm, I'd think that if one is interested in having a problem fixed the he'd be > pro-active in providing details about the problem. > Of course, I mean useful details like stack trace and other crash dump info. This is my desktop machine @work (running X11), so if it crashes, I need it to boot because the next customer who calls wants me to help him 8-) Right now, it's hanging again in disk-IO, and it's not the IMG vrs. ISO problem 8-( I can still type as I'm logged in on my home machine. What can I type on the problem host to provide you or send-pr with that data ? It's a hang: # burncd -f /dev/acd0 data FreeNAS-amd64-LiveCD-0.7RC1.4735.iso fixate next writeable LBA 0 writing from file FreeNAS-amd64-LiveCD-0.7RC1.4735.iso size 74482 KB written this track 74482 KB (100%) total 74482 KB fixating CD, please wait.. load: 0.08 cmd: burncd 22142 [g_waitidle] 0.00u 0.06s 0% 920k load: 0.08 cmd: burncd 22142 [g_waitidle] 0.00u 0.06s 0% 920k [...] For very short times, writes are going through (from time to time). Here's what ps ax told me: 22142 p3 T+ 0:00.07 burncd -f /dev/acd0 data FreeNAS-amd64-LiveCD-0.7RC1. A kill -9 is still @work 8-( -- pi@opsec.eu +49 171 3101372 11 years to go ! From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 18:16:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0686C106566C for ; Wed, 9 Sep 2009 18:16:22 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.freebsd.org (Postfix) with ESMTP id BD6598FC15 for ; Wed, 9 Sep 2009 18:16:21 +0000 (UTC) Received: by mail.0x20.net (Postfix, from userid 1002) id 7192E398B3; Wed, 9 Sep 2009 20:16:20 +0200 (CEST) Date: Wed, 9 Sep 2009 20:16:20 +0200 From: Lars Engels To: Gary Jennejohn Message-ID: <20090909181620.GA19090@e.0x20.net> References: <20090908201713.GD41185@e.0x20.net> <20090909104528.20b28e65@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <20090909104528.20b28e65@ernst.jennejohn.org> X-Editor: VIM - Vi IMproved 7.2 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: Mutt/1.5.19 (2009-01-05) Cc: current@freebsd.org Subject: Re: CFH: fix multimedia/pwcbsd with usb2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 18:16:22 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 09, 2009 at 10:45:28AM +0200, Gary Jennejohn wrote: > On Tue, 8 Sep 2009 22:17:13 +0200 > Lars Engels wrote: >=20 > > could someone with some more USB and C knowledge than me take a look at > > multimedia/pwcbsd? > > I'd really like to get the port fixed before the ports freeze starts. > > Here is the compile output: > >=20 >=20 > The patches under ~gj/work on freefall at least allow it to compile. I > can't test whether it works, however. >=20 > Let me know when you have them so I can delete them. Gary, thanks a lot for the patches! pwcbsd compiles and my cam is showing wonderful pictures (as long as I am not in front of it ;-) ). I just commited the new port version, so have fun with your cams, everbody! Lars --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqn8PQACgkQKc512sD3afj9/wCghnTuT+7Uhuecp2MM1Upk0Ugn SGEAoJKrVGjnSnmrufXJuIp3V3kvVSio =FhdE -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 18:20:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD5411065692 for ; Wed, 9 Sep 2009 18:20:58 +0000 (UTC) (envelope-from alleepsilonkleinereins@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8A18FC08 for ; Wed, 9 Sep 2009 18:20:58 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so1237181fga.13 for ; Wed, 09 Sep 2009 11:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=nc2q94iikJcJ5YDE+E/nS8HYG7/KunTT9eweAvPzhOE=; b=vMFq0Yv7NwbPf/YosQLb11qcqhiS0/3Shrprgl8Pz0cMXIkkxw3SrzEe9q3tOp+2n1 2ZLK+JoGwPc6pbETb+IiwK4fpMiWUSADNsRfbzkvWbIx0fBKVuEkPTjBTgC31nMuAlpa hY9Fol1SQVzhHAPJE/r+dRNj4oezSii0nYCUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=BF9t2AWYuuW76DUOGM5Ph77LJL/+mqANA/Dy6mirM+gCPUEPcQOCrYO/2ZSkjpLuI5 FBuWlWgkzhrQSuKHwpm5Q3f6xaR8+lUqQ6bvCtoPHRuzo4XqR8iF9+AN46Y+mqkEA8Ey YQdsgjE6rh7jHikkqzdD9pLq/e3emZxtDMGy0= Received: by 10.86.220.11 with SMTP id s11mr332457fgg.47.1252518580390; Wed, 09 Sep 2009 10:49:40 -0700 (PDT) Received: from felix.eh.com ([85.13.9.227]) by mx.google.com with ESMTPS id 4sm571282fge.8.2009.09.09.10.49.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Sep 2009 10:49:39 -0700 (PDT) Message-ID: <4AA7EAB2.5040403@googlemail.com> Date: Wed, 09 Sep 2009 19:49:38 +0200 From: Felix Stolba User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: FreeBSD Current References: <179b97fb0905301355n2a422e05j665fc3a551ce06f1@mail.gmail.com> In-Reply-To: <179b97fb0905301355n2a422e05j665fc3a551ce06f1@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Brandon Gooch , bzeeb+freebsd+lor@zabbadoz.net Subject: Re: LOR acpi_ibm module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 18:20:58 -0000 Brandon Gooch schrieb: > lock order reversal: > 1st 0xffffffff807cf200 sysctl lock (sysctl lock) @ > /usr/src/sys/kern/kern_sysctl.c:1608 > 2nd 0xffffffff80bf1de0 ACPI IBM extras (ACPI IBM extras) @ > /usr/src/sys/modules/acpi/acpi_ibm/../../../dev/acpi_support/acpi_ibm.c:481 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > _sx_xlock() at _sx_xlock+0x54 > acpi_ibm_sysctl() at acpi_ibm_sysctl+0x4f > sysctl_root() at sysctl_root+0xe3 > userland_sysctl() at userland_sysctl+0x158 > __sysctl() at __sysctl+0xaa > syscall() at syscall+0x1dd > Xfast_syscall() at Xfast_syscall+0xd0 > --- syscall (202, FreeBSD ELF64, __sysctl), rip = 0x80073769c, rsp = > 0x7fffffffda58, rbp = 0x4 --- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > I'm getting the same LOR at boot in 9.0-current (source from 7th of september). From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 18:25:22 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 3E9CA106566B; Wed, 9 Sep 2009 18:25:22 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 9 Sep 2009 14:25:13 -0400 User-Agent: KMail/1.6.2 References: <179b97fb0905301355n2a422e05j665fc3a551ce06f1@mail.gmail.com> <4AA7EAB2.5040403@googlemail.com> In-Reply-To: <4AA7EAB2.5040403@googlemail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909091425.15003.jkim@FreeBSD.org> Cc: Brandon Gooch , bzeeb+freebsd+lor@zabbadoz.net, Felix Stolba Subject: Re: LOR acpi_ibm module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 18:25:22 -0000 On Wednesday 09 September 2009 01:49 pm, Felix Stolba wrote: > Brandon Gooch schrieb: > > lock order reversal: > > 1st 0xffffffff807cf200 sysctl lock (sysctl lock) @ > > /usr/src/sys/kern/kern_sysctl.c:1608 > > 2nd 0xffffffff80bf1de0 ACPI IBM extras (ACPI IBM extras) @ > > /usr/src/sys/modules/acpi/acpi_ibm/../../../dev/acpi_support/acpi > >_ibm.c:481 KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > _witness_debugger() at _witness_debugger+0x2e > > witness_checkorder() at witness_checkorder+0x81e > > _sx_xlock() at _sx_xlock+0x54 > > acpi_ibm_sysctl() at acpi_ibm_sysctl+0x4f > > sysctl_root() at sysctl_root+0xe3 > > userland_sysctl() at userland_sysctl+0x158 > > __sysctl() at __sysctl+0xaa > > syscall() at syscall+0x1dd > > Xfast_syscall() at Xfast_syscall+0xd0 > > --- syscall (202, FreeBSD ELF64, __sysctl), rip = 0x80073769c, > > rsp = 0x7fffffffda58, rbp = 0x4 --- > > I'm getting the same LOR at boot in 9.0-current (source from 7th of > september). It is generally harmless but really annoying. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 18:51:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78AFD106566B; Wed, 9 Sep 2009 18:51:19 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id DC0FD8FC2A; Wed, 9 Sep 2009 18:51:18 +0000 (UTC) Received: by ewy4 with SMTP id 4so3031968ewy.36 for ; Wed, 09 Sep 2009 11:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VedFD33rWqfVFULdxITIYXKR50PJg8Z0A6DMkTqb5LI=; b=a+d5qwbeUU/JTvA2Xobmb+ddJw2i6TS9oNdl+0Zg7cavDNRD3odHb+lpLjTltzfSbf MoPtk+89/iYNMjRWHX2cVa96gzOrDUyslgFHEI3jAPWde/9T+oym96W2uaotI/Hoovr/ 38x01Dg+b+6GzvUAiH5f7WY8AWfUie640CCL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kpc1gPzzEqCPyq7M1lDy8lz5ezZXOIOQYptLwSnCHUqttobgo1aVzunuHE+EVsBNaD oJgy6fqa7HLfZBwZPxxKrmfjs5OPJcHgjoXVa0iMzRtfJCxa+9ZShO1CJxqwWUKY93RG h7Q91cQa5PkTXz/tn9vSZ6hwP9z/rHCyM6bbw= MIME-Version: 1.0 Received: by 10.211.145.11 with SMTP id x11mr562981ebn.74.1252522277718; Wed, 09 Sep 2009 11:51:17 -0700 (PDT) In-Reply-To: <200909091425.15003.jkim@FreeBSD.org> References: <179b97fb0905301355n2a422e05j665fc3a551ce06f1@mail.gmail.com> <4AA7EAB2.5040403@googlemail.com> <200909091425.15003.jkim@FreeBSD.org> Date: Wed, 9 Sep 2009 13:51:17 -0500 Message-ID: <179b97fb0909091151g502c846fq5070f84381f9efa5@mail.gmail.com> From: Brandon Gooch To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bzeeb+freebsd+lor@zabbadoz.net, Felix Stolba , freebsd-current@freebsd.org Subject: Re: LOR acpi_ibm module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 18:51:19 -0000 On Wed, Sep 9, 2009 at 1:25 PM, Jung-uk Kim wrote: > On Wednesday 09 September 2009 01:49 pm, Felix Stolba wrote: >> Brandon Gooch schrieb: >> > lock order reversal: >> > =A01st 0xffffffff807cf200 sysctl lock (sysctl lock) @ >> > /usr/src/sys/kern/kern_sysctl.c:1608 >> > =A02nd 0xffffffff80bf1de0 ACPI IBM extras (ACPI IBM extras) @ >> > /usr/src/sys/modules/acpi/acpi_ibm/../../../dev/acpi_support/acpi >> >_ibm.c:481 KDB: stack backtrace: >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> > _witness_debugger() at _witness_debugger+0x2e >> > witness_checkorder() at witness_checkorder+0x81e >> > _sx_xlock() at _sx_xlock+0x54 >> > acpi_ibm_sysctl() at acpi_ibm_sysctl+0x4f >> > sysctl_root() at sysctl_root+0xe3 >> > userland_sysctl() at userland_sysctl+0x158 >> > __sysctl() at __sysctl+0xaa >> > syscall() at syscall+0x1dd >> > Xfast_syscall() at Xfast_syscall+0xd0 >> > --- syscall (202, FreeBSD ELF64, __sysctl), rip =3D 0x80073769c, >> > rsp =3D 0x7fffffffda58, rbp =3D 0x4 --- >> >> I'm getting the same LOR at boot in 9.0-current (source from 7th of >> september). > > It is generally harmless but really annoying. > > Jung-uk Kim > I haven't been running a kernel with WITNESS (or any debugging) for a couple of weeks, so I forgot about it. Originally, I wondered if this locking problem(?) was causing a strange issue when I invoked a script via devd (a call to a script to handle ACPI events through acpi_ibm.ko), in this case, an ACPI screen brightness function: Occasionally, the screen brightness would not adjust when I used the Fn keys, only to eventually, "pop" all of the requests I sent off of the devd command table, usually with a long delay. If I started devd in foreground mode and watched the command output in the terminal, commands were "pushed" and "popped" immediately; all was well. I was never able to put it all together, and it was only a minor annoyance, after all. -Brandon From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 19:04:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E56BD1065694; Wed, 9 Sep 2009 19:04:53 +0000 (UTC) (envelope-from universite@ukr.net) Received: from mary-teresa.otrada.od.ua (universite.broker.freenet6.net [IPv6:2001:5c0:1400:b::27e9]) by mx1.freebsd.org (Postfix) with ESMTP id 4811A8FC23; Wed, 9 Sep 2009 19:04:53 +0000 (UTC) Received: from phenom (mary-teresa.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by mary-teresa.otrada.od.ua (8.14.3/8.14.3) with ESMTP id n89J4kaK018512; Wed, 9 Sep 2009 22:04:46 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: mary-teresa.otrada.od.ua: Host mary-teresa.otrada.od.ua [10.0.0.10] claimed to be phenom X-AntiVirus: Checked by Dr.Web [version: 5.0, engine: 5.00.0.12182, virus records: 632302, updated: 8.09.2009] Message-ID: <4AA7FC4B.6090601@ukr.net> Date: Wed, 09 Sep 2009 22:04:43 +0300 From: "Vladislav V. Prodan" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua Cc: "Li, Qing" Subject: misc/138676: after buildworld not work local routes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 19:04:54 -0000 >Number: 138676 >Category: misc >Synopsis: after buildworld not work local routes >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 09 19:00:04 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Vladislav V. Prodan >Release: FreeBSD 8.0-BETA4 #0: Wed Sep 9 00:53:41 EEST 2009 amd64 >Organization: >Environment: FreeBSD mary-teresa.otrada.od.ua 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Wed Sep 9 00:53:41 EEST 2009 vlad11@mary-teresa.otrada.od.ua:/usr/obj/usr/src/sys/mary-teresa.17 amd64 >Description: home PC --> FreeBSD [ squid --> apache ] These url are on the external interface of the server. http://otrada.od.ua/blog/ http://otrada.od.ua/phpmyadmin/ http://otrada.od.ua/cacti/ After upgrade the system now gives the squid: (51) Network is unreachable In logs: sep 9 18:39:10 128 10.0.0.10 TCP_MISS/503 1317 GET http://otrada.od.ua/blog/ - DIRECT/otrada.od.ua text/html sep 9 18:39:18 126 10.0.0.10 TCP_MISS/503 1329 GET http://otrada.od.ua/phpmyadmin/ - DIRECT/otrada.od.ua text/html sep 9 18:39:39 117 10.0.0.10 TCP_MISS/503 1319 GET http://otrada.od.ua/cacti/ - DIRECT/otrada.od.ua text/html Out all three url normally give details. At queries from outside, all url are working properly. similar problem was previously: http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001581.html >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 19:08:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BFE11065670; Wed, 9 Sep 2009 19:08:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2BDA08FC08; Wed, 9 Sep 2009 19:08:55 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CC9BD46B2C; Wed, 9 Sep 2009 15:08:54 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 1FC708A01B; Wed, 9 Sep 2009 15:08:54 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 9 Sep 2009 14:53:50 -0400 User-Agent: KMail/1.9.7 References: <179b97fb0905301355n2a422e05j665fc3a551ce06f1@mail.gmail.com> <4AA7EAB2.5040403@googlemail.com> <200909091425.15003.jkim@FreeBSD.org> In-Reply-To: <200909091425.15003.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909091453.50771.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 09 Sep 2009 15:08:54 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Brandon Gooch , bzeeb+freebsd+lor@zabbadoz.net, Felix Stolba , Jung-uk Kim Subject: Re: LOR acpi_ibm module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 19:08:55 -0000 On Wednesday 09 September 2009 2:25:13 pm Jung-uk Kim wrote: > On Wednesday 09 September 2009 01:49 pm, Felix Stolba wrote: > > Brandon Gooch schrieb: > > > lock order reversal: > > > 1st 0xffffffff807cf200 sysctl lock (sysctl lock) @ > > > /usr/src/sys/kern/kern_sysctl.c:1608 > > > 2nd 0xffffffff80bf1de0 ACPI IBM extras (ACPI IBM extras) @ > > > /usr/src/sys/modules/acpi/acpi_ibm/../../../dev/acpi_support/acpi > > >_ibm.c:481 KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > _witness_debugger() at _witness_debugger+0x2e > > > witness_checkorder() at witness_checkorder+0x81e > > > _sx_xlock() at _sx_xlock+0x54 > > > acpi_ibm_sysctl() at acpi_ibm_sysctl+0x4f > > > sysctl_root() at sysctl_root+0xe3 > > > userland_sysctl() at userland_sysctl+0x158 > > > __sysctl() at __sysctl+0xaa > > > syscall() at syscall+0x1dd > > > Xfast_syscall() at Xfast_syscall+0xd0 > > > --- syscall (202, FreeBSD ELF64, __sysctl), rip = 0x80073769c, > > > rsp = 0x7fffffffda58, rbp = 0x4 --- > > > > I'm getting the same LOR at boot in 9.0-current (source from 7th of > > september). > > It is generally harmless but really annoying. Actually, we can just remove the pointless locking from attach to fix this I think. You don't need locking in attach while you are adding the sysctls, etc. since no other threads can "get" to the acpi_ibm data yet. This patch should fix the LOR: Index: acpi_ibm.c =================================================================== --- acpi_ibm.c (revision 196974) +++ acpi_ibm.c (working copy) @@ -356,8 +356,6 @@ } sc->ec_handle = acpi_get_handle(sc->ec_dev); - ACPI_SERIAL_BEGIN(ibm); - /* Get the sysctl tree */ sc->sysctl_ctx = device_get_sysctl_ctx(dev); sc->sysctl_tree = device_get_sysctl_tree(dev); @@ -404,8 +402,6 @@ "Thermal zones"); } - ACPI_SERIAL_END(ibm); - /* Handle notifies */ AcpiInstallNotifyHandler(sc->handle, ACPI_DEVICE_NOTIFY, acpi_ibm_notify, dev); -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 19:08:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0703106566C; Wed, 9 Sep 2009 19:08:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3978FC0A; Wed, 9 Sep 2009 19:08:56 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 30C8146B38; Wed, 9 Sep 2009 15:08:56 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 795568A01F; Wed, 9 Sep 2009 15:08:55 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 9 Sep 2009 14:55:41 -0400 User-Agent: KMail/1.9.7 References: <3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200909091455.42039.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 09 Sep 2009 15:08:55 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Attilio Rao , Kostik Belousov , freebsd-emulation@freebsd.org, pluknet Subject: Re: acquiring duplicate lock of same type: "ftlk" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 19:08:57 -0000 On Tuesday 08 September 2009 3:42:13 pm pluknet wrote: > 2009/9/8 Attilio Rao : > > 2009/9/8 Kostik Belousov : > >> On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote: > >>> lock order reversal: > >>> =A01st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup.= c:497 > >>> =A02nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:2= 92 > >>> KDB: stack backtrace: > >>> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,..= =2E) > >>> at db_trace_self_wrapper+0x26 > >>> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at > >>> kdb_backtrace+0x29 > >>> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) at > >>> _witness_debugger+0x25 > >>> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at=20 witness_checkorder+0x839 > >>> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85 > >>> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f > >>> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a > >>> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at=20 pfs_lookup+0x3dd > >>> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,...) > >>> at VOP_CACHEDLOOKUP_APV+0xc5 > >>> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at > >>> vfs_cache_lookup+0xd6 > >>> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at > >>> VOP_LOOKUP_APV+0xe5 > >>> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b > >>> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f > >>> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at=20 kern_alternate > >>> _path+0x1cd > >>> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at > >>> linux_emul_convpath+0x3c > >>> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at=20 linux_open+0x41 > >>> syscall(e8214d38) at syscall+0x2b4 > >>> Xint0x80_syscall() at Xint0x80_syscall+0x20 > >>> --- syscall (5, Linux ELF, linux_open), eip =3D 0x2889115e, esp =3D > >>> 0xbfbfbd1c, ebp =3D 0xbfbfbd6c --- > >>> acquiring duplicate lock of same type: "ftlk" > >>> [...] > >> > >> The second LOR actually exposes the right order. It would be interesti= ng > >> to look up the point where the other order is established. > > > > You would manually patch the witness static table with this order and > > the opposite will show, when happening. > > >=20 > I've patched witness order table, and still no opposite case, > nor any pseudofs related LORs at all. > { "pseudofs", &lock_class_lockmgr }, > { "allproc", &lock_class_sx }, > { NULL, NULL }, >=20 > Seen orders with pseudofs: > "ufs","pseudofs" > "pseudofs","allproc" > "pseudofs","process lock" > "pseudofs","vnode interlock" > "pseudofs","struct mount mtx" > "pseudofs","UMA zone" > "pseudofs","sleep mtxpool" > "pseudofs","Name Cache" > "pseudofs","vnode_free_list" > "pseudofs","pfs_node" > "pseudofs","pfs_vncache" >=20 > Something else? What are the seen orders with "allproc"? =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 19:08:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D10E1065676 for ; Wed, 9 Sep 2009 19:08:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F19698FC0C for ; Wed, 9 Sep 2009 19:08:57 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A0CE346B46; Wed, 9 Sep 2009 15:08:57 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id CD11B8A020; Wed, 9 Sep 2009 15:08:56 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 9 Sep 2009 15:07:32 -0400 User-Agent: KMail/1.9.7 References: <4AA7D4BA.40002@demig.de> In-Reply-To: <4AA7D4BA.40002@demig.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909091507.32600.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 09 Sep 2009 15:08:56 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Norbert Koch Subject: Re: lock order reversal etc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 19:08:58 -0000 On Wednesday 09 September 2009 12:15:54 pm Norbert Koch wrote: > Hello. > > Is this the right mailing list to post > kernel stack traces from Freebsd-8-BETA4? > If yes, see below, otherwise just ignore this message. > > uma_zalloc_arg: zone "64" with the following non-sleepable locks held: > exclusive sleep mutex jail mutex (jail mutex) r = 0 (0xc0b91328) locked > @ > /usr/src/sys/modules/syscons/daemon/../../../dev/syscons/daemon/daemon_saver.c:355 > KDB: stack backtrace: > db_trace_self_wrapper(c0abf50f,e69b391c,c07ab3b5,c4a0580a,163,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c4a0580a,163,ffffffff,c0d261c4,e69b3954,...) at > kdb_backtrace+0x29 > _witness_debugger(c0ac198e,e69b3968,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c0ae4b92,c0add27b,e69b3984,...) at witness_warn+0x1fd > uma_zalloc_arg(c148b000,0,2,2,14,...) at uma_zalloc_arg+0x34 > malloc(29,c0b92dd0,2,163,c46562e4,...) at malloc+0xe4 > daemon_init(c0d61940,c0aba83e,e69b3a28,c46f5600,c4a06cc0,...) at > daemon_init+0x7b > splash_test(7b,c46f5600,c4a06cc0,c46f5600,e69b3a50,...) at splash_test+0x91 > splash_register(c4a06c40,0,0,76,0,...) at splash_register+0x48 Try this patch for this one: Index: daemon_saver.c =================================================================== --- daemon_saver.c (revision 196974) +++ daemon_saver.c (working copy) @@ -351,11 +351,23 @@ static int daemon_init(video_adapter_t *adp) { + size_t hostlen; mtx_lock(&prison0.pr_mtx); - messagelen = strlen(prison0.pr_hostname) + 3 + strlen(ostype) + 1 + - strlen(osrelease); - message = malloc(messagelen + 1, M_DEVBUF, M_WAITOK); + for (;;) { + hostlen = strlen(prison0.pr_hostname); + mtx_unlock(&prison0.pr_mtx); + + messagelen = hostlen + 3 + strlen(ostype) + 1 + + strlen(osrelease); + message = malloc(messagelen + 1, M_DEVBUF, M_WAITOK); + mtx_lock(&prison0.pr_mtx); + if (hostlen < strlen(prison0.pr_hostname)) { + free(message, M_DEVBUF); + continue; + } + break; + } sprintf(message, "%s - %s %s", prison0.pr_hostname, ostype, osrelease); mtx_unlock(&prison0.pr_mtx); blanked = 0; > lock order reversal: > 1st 0xc4afca2c filedesc structure (filedesc structure) @ > /usr/src/sys/kern/kern_descrip.c:1088 > 2nd 0xc4be3488 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4091 > KDB: stack backtrace: This is the right order. I think several of these have been fixed, but there still might be some place that uses UFS -> filedesc. You can try hardcoding that order into witness to find it. > lock order reversal: > 1st 0xd82d03f0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 > 2nd 0xc4f64800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 This is known to be harmless. > lock order reversal: > 1st 0xc464337c ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 > 2nd 0xd81d14b0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6177 > 3rd 0xc673a7ac ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 > KDB: stack backtrace: > db_trace_self_wrapper(c0abf50f,e6b103cc,c07ab3b5,c079c13b,c0ac23fb,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c079c13b,c0ac23fb,c4122e90,c4126290,e6b10428,...) at > kdb_backtrace+0x29 > _witness_debugger(c0ac23fb,c673a7ac,c0ab4f66,c4126290,c0ac96be,...) at > _witness_debugger+0x25 > witness_checkorder(c673a7ac,9,c0ac96be,823,0,...) at > witness_checkorder+0x839 > __lockmgr_args(c673a7ac,80100,c673a7c8,0,0,...) at __lockmgr_args+0x7a7 > ffs_lock(e6b10538,c07ab15b,c0ac8bb1,80100,c673a754,...) at ffs_lock+0x8a > VOP_LOCK1_APV(c0bae360,e6b10538,c4c08524,c0bc5660,c673a754,...) at > VOP_LOCK1_APV+0xb5 > _vn_lock(c673a754,80100,c0ac96be,823,4,...) at _vn_lock+0x5e > vget(c673a754,80100,c4c08480,50,0,...) at vget+0xb9 > vfs_hash_get(c46e1508,18ef074,80000,c4c08480,e6b10694,...) at > vfs_hash_get+0xe6 > ffs_vgetf(c46e1508,18ef074,80000,e6b10694,1,...) at ffs_vgetf+0x49 > softdep_sync_metadata(c4643324,0,c0ae2efa,146,0,...) at > softdep_sync_metadata+0x5ba > ffs_syncvnode(c4643324,1,c0abaa2c,c0ab45da,3,...) at ffs_syncvnode+0x3e2 > ffs_truncate(c4643324,600,0,880,c465d280,...) at ffs_truncate+0x66a > ufs_direnter(c4643324,c673a754,e6b10a1c,e6b10c00,d82ec1d0,...) at > ufs_direnter+0x8f6 > ufs_mkdir(e6b10c28,e6b10c3c,0,0,e6b10b6c,...) at ufs_mkdir+0x8a7 > VOP_MKDIR_APV(c0bae360,e6b10c28,e6b10c00,e6b10b6c,0,...) at > VOP_MKDIR_APV+0xa5 > kern_mkdirat(c4c08480,ffffff9c,804c2e8,0,41fd,...) at kern_mkdirat+0x22b > kern_mkdir(c4c08480,804c2e8,0,41fd,e6b10d2c,...) at kern_mkdir+0x2e > mkdir(c4c08480,e6b10cf8,8,c0ac2cbd,c0b8d920,...) at mkdir+0x29 > syscall(e6b10d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 This is probably harmless. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 19:14:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 133AB106568B; Wed, 9 Sep 2009 19:14:47 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id D52438FC17; Wed, 9 Sep 2009 19:14:46 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n89JEjh8028185; Wed, 9 Sep 2009 12:14:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Sep 2009 12:14:05 -0700 Message-ID: In-Reply-To: <4AA7FC4B.6090601@ukr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: misc/138676: after buildworld not work local routes Thread-Index: AcoxgGl3fFVgb6TdSu6Qmv4F21vCRwAAS9lA References: <4AA7FC4B.6090601@ukr.net> From: "Li, Qing" To: "Vladislav V. Prodan" , , Cc: Subject: RE: misc/138676: after buildworld not work local routes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 19:14:47 -0000 Thanks for the report. I will work you off list for now. -- Qing > -----Original Message----- > From: Vladislav V. Prodan [mailto:universite@ukr.net] > Sent: Wednesday, September 09, 2009 12:05 PM > To: freebsd-current@freebsd.org; freebsd-net@freebsd.org > Cc: Li, Qing > Subject: misc/138676: after buildworld not work local routes >=20 > >Number: 138676 > >Category: misc > >Synopsis: after buildworld not work local routes > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-bugs > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed Sep 09 19:00:04 UTC 2009 > >Closed-Date: > >Last-Modified: > >Originator: Vladislav V. Prodan > >Release: FreeBSD 8.0-BETA4 #0: Wed Sep 9 00:53:41 EEST 2009 > amd64 > >Organization: > >Environment: > FreeBSD mary-teresa.otrada.od.ua 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Wed > Sep > 9 00:53:41 EEST 2009 > vlad11@mary-teresa.otrada.od.ua:/usr/obj/usr/src/sys/mary-teresa.17 > amd64 >=20 > >Description: > home PC --> FreeBSD [ squid --> apache ] >=20 > These url are on the external interface of the server. > http://otrada.od.ua/blog/ > http://otrada.od.ua/phpmyadmin/ > http://otrada.od.ua/cacti/ >=20 > After upgrade the system now gives the squid: > (51) Network is unreachable >=20 > In logs: > sep 9 18:39:10 128 10.0.0.10 TCP_MISS/503 1317 GET > http://otrada.od.ua/blog/ - DIRECT/otrada.od.ua text/html > sep 9 18:39:18 126 10.0.0.10 TCP_MISS/503 1329 GET > http://otrada.od.ua/phpmyadmin/ - DIRECT/otrada.od.ua text/html > sep 9 18:39:39 117 10.0.0.10 TCP_MISS/503 1319 GET > http://otrada.od.ua/cacti/ - DIRECT/otrada.od.ua text/html >=20 > Out all three url normally give details. > At queries from outside, all url are working properly. >=20 > similar problem was previously: > http://lists.freebsd.org/pipermail/freebsd-current/2008- > December/001581.html > >How-To-Repeat: >=20 > >Fix: >=20 >=20 > >Release-Note: > >Audit-Trail: > >Unformatted: >=20 >=20 >=20 >=20 From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 19:25:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D56271065695; Wed, 9 Sep 2009 19:25:52 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id C4FDA8FC16; Wed, 9 Sep 2009 19:25:51 +0000 (UTC) Received: by bwz2 with SMTP id 2so1906645bwz.43 for ; Wed, 09 Sep 2009 12:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SaukS2BB07lu+4iTWwCp+3OfNRiwJn4crwtyZFbu9OI=; b=enMZv1DMzMWrYosysDpCcOtfRUU6cXZH/QHls/wiGVbAUWPqXLlxZClFyqYyrNoRp4 wx/4LyAljI9qB+wdxKqa5uQ1ecEb9MO6zvgs8X1y4Zt/0eQIf1QEjVDsMTJpHujPtMfA 5XWNp7KNXIQ8b+ldbFBbsD/aUwn1XHXlLEwG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dL8MA03uaJhBH3Zx/XFoWJL4KS+DDPrIErFiDFO1C2AcXxzTMBsu9/IizFw9jsl23Y FNfISmIloD91HT0luvxsdQ2NIpCJbNsRlQ+yGEgpZvFHlD+oW66MNeOT3JEdoSZCPjOp oPrRiV9Hu1NNg4QtmXwlGs4P12SuDjlBrO7w8= MIME-Version: 1.0 Received: by 10.204.15.7 with SMTP id i7mr96894bka.126.1252524350370; Wed, 09 Sep 2009 12:25:50 -0700 (PDT) In-Reply-To: <200909091455.42039.jhb@freebsd.org> References: <3bbf2fe10909080213i588493darf8dd1e1ff768cb0a@mail.gmail.com> <200909091455.42039.jhb@freebsd.org> Date: Wed, 9 Sep 2009 23:25:50 +0400 Message-ID: From: pluknet To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Attilio Rao , Kostik Belousov , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: acquiring duplicate lock of same type: "ftlk" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 19:25:52 -0000 2009/9/9 John Baldwin : > On Tuesday 08 September 2009 3:42:13 pm pluknet wrote: >> 2009/9/8 Attilio Rao : >> > 2009/9/8 Kostik Belousov : >> >> On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote: >> >>> lock order reversal: >> >>> =A01st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_lookup= .c:497 >> >>> =A02nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.c:= 292 >> >>> KDB: stack backtrace: >> >>> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf,.= ..) >> >>> at db_trace_self_wrapper+0x26 >> >>> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at >> >>> kdb_backtrace+0x29 >> >>> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...) = at >> >>> _witness_debugger+0x25 >> >>> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at > witness_checkorder+0x839 >> >>> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85 >> >>> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f >> >>> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a >> >>> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at > pfs_lookup+0x3dd >> >>> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,..= .) >> >>> at VOP_CACHEDLOOKUP_APV+0xc5 >> >>> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at >> >>> vfs_cache_lookup+0xd6 >> >>> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at >> >>> VOP_LOOKUP_APV+0xe5 >> >>> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b >> >>> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f >> >>> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at > kern_alternate >> >>> _path+0x1cd >> >>> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at >> >>> linux_emul_convpath+0x3c >> >>> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at > linux_open+0x41 >> >>> syscall(e8214d38) at syscall+0x2b4 >> >>> Xint0x80_syscall() at Xint0x80_syscall+0x20 >> >>> --- syscall (5, Linux ELF, linux_open), eip =3D 0x2889115e, esp =3D >> >>> 0xbfbfbd1c, ebp =3D 0xbfbfbd6c --- >> >>> acquiring duplicate lock of same type: "ftlk" >> >>> [...] >> >> >> >> The second LOR actually exposes the right order. It would be interest= ing >> >> to look up the point where the other order is established. >> > >> > You would manually patch the witness static table with this order and >> > the opposite will show, when happening. >> > >> >> I've patched witness order table, and still no opposite case, >> nor any pseudofs related LORs at all. >> =A0 =A0 =A0 =A0 { "pseudofs", &lock_class_lockmgr }, >> =A0 =A0 =A0 =A0 { "allproc", &lock_class_sx }, >> =A0 =A0 =A0 =A0 { NULL, NULL }, >> >> Seen orders with pseudofs: >> "ufs","pseudofs" >> "pseudofs","allproc" >> "pseudofs","process lock" >> "pseudofs","vnode interlock" >> "pseudofs","struct mount mtx" >> "pseudofs","UMA zone" >> "pseudofs","sleep mtxpool" >> "pseudofs","Name Cache" >> "pseudofs","vnode_free_list" >> "pseudofs","pfs_node" >> "pseudofs","pfs_vncache" >> >> Something else? > > What are the seen orders with "allproc"? > sysctl debug.witness.fullgraph | grep allproc "proctree","allproc" "allproc","allprison" "allproc","process lock" "allproc","user map" "allproc","fdesc" "allproc","filedesc structure" "sysctl lock","allproc" "pseudofs","allproc" Also, if it matters, I saw this LOR today: lock order reversal: 1st 0xc7f01164 ufs (ufs) @ /usr/RELENG_8/src/sys/kern/vfs_mount.c:1054 2nd 0xc7fb5058 pseudofs (pseudofs) @ /usr/RELENG_8/src/sys/fs/pseudofs/pseudofs_vncache.c:193 KDB: stack backtrace: db_trace_self_wrapper(c0c7545b,eab2c850,c08c0f75,c08b1cfb,c0c783a3,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08b1cfb,c0c783a3,c612fbe8,c61281a0,eab2c8ac,...) at kdb_backtrace+0x29 _witness_debugger(c0c783a3,c7fb5058,c0c679b8,c61281a0,c0c6803f,...) at _witness_debugger+0x25 witness_checkorder(c7fb5058,9,c0c6803f,c1,c7fb5074,...) at witness_checkorder+0x839 __lockmgr_args(c7fb5058,80400,c7fb5074,0,0,...) at __lockmgr_args+0x7a7 vop_stdlock(eab2c9b4,c087030a,c7fb50a8,80400,c7fb5000,...) at vop_stdlock+0= x62 VOP_LOCK1_APV(c0d55580,eab2c9b4,c0911dcf,c0d92080,c7fb5000,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c7fb5000,80400,c0c6803f,c1,c0f3339c,...) at _vn_lock+0x5e pfs_vncache_alloc(c6764c94,eab2cc30,c7d1cb00,186a0,eab2cc60,...) at pfs_vncache_alloc+0x232 pfs_root(c6764c94,80000,eab2cc30,42c,0,...) at pfs_root+0x2d vfs_donmount(c7ba76c0,0,c6b66500,c6b66500,bfbfdc89,...) at vfs_donmount+0x1= 4c2 nmount(c7ba76c0,eab2ccf8,c,c7ba76c0,c0d5a638,...) at nmount+0x75 syscall(eab2cd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip =3D 0x280e876b, esp =3D 0xbfbfdc5c, ebp =3D 0xbfbfe1b8 --- --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 19:41:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C86961065695; Wed, 9 Sep 2009 19:41:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 96A5D8FC17; Wed, 9 Sep 2009 19:41:04 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 45CFE46B03; Wed, 9 Sep 2009 15:41:04 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 62B3B8A01B; Wed, 9 Sep 2009 15:41:03 -0400 (EDT) From: John Baldwin To: pluknet Date: Wed, 9 Sep 2009 15:40:57 -0400 User-Agent: KMail/1.9.7 References: <200909091455.42039.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200909091540.57890.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 09 Sep 2009 15:41:03 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Attilio Rao , Kostik Belousov , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: acquiring duplicate lock of same type: "ftlk" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 19:41:04 -0000 On Wednesday 09 September 2009 3:25:50 pm pluknet wrote: > 2009/9/9 John Baldwin : > > On Tuesday 08 September 2009 3:42:13 pm pluknet wrote: > >> 2009/9/8 Attilio Rao : > >> > 2009/9/8 Kostik Belousov : > >> >> On Mon, Sep 07, 2009 at 10:15:48PM +0400, pluknet wrote: > >> >>> lock order reversal: > >> >>> =A01st 0xc75365b8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_look= up.c:497 > >> >>> =A02nd 0xc088ea3c allproc (allproc) @ /usr/src/sys/kern/kern_proc.= c:292 > >> >>> KDB: stack backtrace: > >> >>> db_trace_self_wrapper(c07fd8ea,e82148e4,c060a145,c05fac1b,c08008bf= ,...) > >> >>> at db_trace_self_wrapper+0x26 > >> >>> kdb_backtrace(c05fac1b,c08008bf,c58eabe8,c58e30d0,e8214940,...) at > >> >>> kdb_backtrace+0x29 > >> >>> _witness_debugger(c08008bf,c088ea3c,c07f981d,c58e30d0,c07f96f0,...= ) at > >> >>> _witness_debugger+0x25 > >> >>> witness_checkorder(c088ea3c,1,c07f96f0,124,0,...) at > > witness_checkorder+0x839 > >> >>> _sx_slock(c088ea3c,0,c07f96f0,124,c73c4980,...) at _sx_slock+0x85 > >> >>> pfind(514,c72ba1a0,4,c07f8d78,c5fe1b40,...) at pfind+0x2f > >> >>> pfs_visible(0,0,c07f042d,7c,c7536560,...) at pfs_visible+0x3a > >> >>> pfs_lookup(e8214a40,c082715e,c7536560,c7536560,e8214bf8,...) at > > pfs_lookup+0x3dd > >> >>> VOP_CACHEDLOOKUP_APV(c0843960,e8214a40,e8214bf8,e8214be4,c73c4e80,= =2E..) > >> >>> at VOP_CACHEDLOOKUP_APV+0xc5 > >> >>> vfs_cache_lookup(e8214acc,c08087d0,c0875a00,200000,e8214bcc,...) at > >> >>> vfs_cache_lookup+0xd6 > >> >>> VOP_LOOKUP_APV(c0843960,e8214acc,e8214bf8,1f1,e8214be4,...) at > >> >>> VOP_LOOKUP_APV+0xe5 > >> >>> lookup(e8214bcc,c5fd1800,0,c5,c5ef77f8,...) at lookup+0x63b > >> >>> namei(e8214bcc,c5c1500d,3f3,e8214c20,c5c1500d,...) at namei+0x57f > >> >>> kern_alternate_path(c5fe1b40,c0b4921c,2879f478,0,e8214c74,...) at > > kern_alternate > >> >>> _path+0x1cd > >> >>> linux_emul_convpath(c5fe1b40,2879f478,0,e8214c74,0,...) at > >> >>> linux_emul_convpath+0x3c > >> >>> linux_open(c5fe1b40,e8214cf8,e8214d18,e8214d1c,c0b4b58c,...) at > > linux_open+0x41 > >> >>> syscall(e8214d38) at syscall+0x2b4 > >> >>> Xint0x80_syscall() at Xint0x80_syscall+0x20 > >> >>> --- syscall (5, Linux ELF, linux_open), eip =3D 0x2889115e, esp =3D > >> >>> 0xbfbfbd1c, ebp =3D 0xbfbfbd6c --- > >> >>> acquiring duplicate lock of same type: "ftlk" > >> >>> [...] > >> >> > >> >> The second LOR actually exposes the right order. It would be intere= sting > >> >> to look up the point where the other order is established. > >> > > >> > You would manually patch the witness static table with this order and > >> > the opposite will show, when happening. > >> > > >> > >> I've patched witness order table, and still no opposite case, > >> nor any pseudofs related LORs at all. > >> =A0 =A0 =A0 =A0 { "pseudofs", &lock_class_lockmgr }, > >> =A0 =A0 =A0 =A0 { "allproc", &lock_class_sx }, > >> =A0 =A0 =A0 =A0 { NULL, NULL }, > >> > >> Seen orders with pseudofs: > >> "ufs","pseudofs" > >> "pseudofs","allproc" > >> "pseudofs","process lock" > >> "pseudofs","vnode interlock" > >> "pseudofs","struct mount mtx" > >> "pseudofs","UMA zone" > >> "pseudofs","sleep mtxpool" > >> "pseudofs","Name Cache" > >> "pseudofs","vnode_free_list" > >> "pseudofs","pfs_node" > >> "pseudofs","pfs_vncache" > >> > >> Something else? > > > > What are the seen orders with "allproc"? > > >=20 > sysctl debug.witness.fullgraph | grep allproc > "proctree","allproc" > "allproc","allprison" > "allproc","process lock" > "allproc","user map" > "allproc","fdesc" > "allproc","filedesc structure" > "sysctl lock","allproc" > "pseudofs","allproc" Ok, there is probably an order of "allproc" -> "filedesc" -> "ufs" -> "psuedofs". There might even be a "filedesc" -> "psuedofs" that could cause this. > Also, if it matters, I saw this LOR today: >=20 > lock order reversal: > 1st 0xc7f01164 ufs (ufs) @ /usr/RELENG_8/src/sys/kern/vfs_mount.c:1054 > 2nd 0xc7fb5058 pseudofs (pseudofs) @ > /usr/RELENG_8/src/sys/fs/pseudofs/pseudofs_vncache.c:193 I think this backs up my theory. I think the LOR is probably harmless, but there's not an easy way to shut it up I believe. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 20:18:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CE5D1065670; Wed, 9 Sep 2009 20:18:45 +0000 (UTC) (envelope-from universite@ukr.net) Received: from mary-teresa.otrada.od.ua (universite.broker.freenet6.net [IPv6:2001:5c0:1400:b::27e9]) by mx1.freebsd.org (Postfix) with ESMTP id 6A85C8FC08; Wed, 9 Sep 2009 20:18:44 +0000 (UTC) Received: from phenom (mary-teresa.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by mary-teresa.otrada.od.ua (8.14.3/8.14.3) with ESMTP id n89KIbvt023232; Wed, 9 Sep 2009 23:18:37 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: mary-teresa.otrada.od.ua: Host mary-teresa.otrada.od.ua [10.0.0.10] claimed to be phenom X-AntiVirus: Checked by Dr.Web [version: 5.0, engine: 5.00.0.12182, virus records: 632302, updated: 8.09.2009] Message-ID: <4AA80D9A.2000609@ukr.net> Date: Wed, 09 Sep 2009 23:18:34 +0300 From: "Vladislav V. Prodan" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Li, Qing" , freebsd-current@freebsd.org References: <4AA7FC4B.6090601@ukr.net> <4AA802EF.6090402@ukr.net> <4AA809BF.9050506@ukr.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: misc/138676: after buildworld not work local routes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 20:18:45 -0000 Li, Qing пишет: > Okay, perhaps I didn't understand your issue correctly. In > http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001581.html > the errors are route insertion related. Those routes are not > visible inside the kernel. Now these routes show up in the > table but Squid reports > " After upgrade the system now gives the squid: > (51) Network is unreachable" > Which IP address is not reachable? Do not operate sites on IP 89.209.81.54, when you walk through the squid. If you go to the sites, bypassing squid, then everything works. It seems, squid does not "see" the table of the form: Destination Gateway Flags Refs Use Netif Expire 89.209.81.54 link#4 UHS 0 30161 lo0 From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 20:18:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B631810657AE for ; Wed, 9 Sep 2009 20:18:55 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 6C3B88FC19 for ; Wed, 9 Sep 2009 20:18:55 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 0BC001E0037F; Wed, 9 Sep 2009 22:18:54 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n89KFvHv095785; Wed, 9 Sep 2009 22:15:57 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id n89KFvIP095784; Wed, 9 Sep 2009 22:15:57 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Wed, 9 Sep 2009 22:15:56 +0200 To: Ryan Stone Message-ID: <20090909201556.GA95426@triton8.kn-bremen.de> References: <52d4a3890908250321u746e5757u136030bcbc19208d@mail.gmail.com> <4A93BF0C.8040601@web.de> <20090826221001.GA1070@triton8.kn-bremen.de> <4A96C8D9.6070804@web.de> <20090829211848.GA59305@triton8.kn-bremen.de> <4A9B800F.1040209@web.de> <20090831212723.GA32448@triton8.kn-bremen.de> <20090901201248.GA60123@triton8.kn-bremen.de> <20090907205955.GA91866@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Juergen Lock , Avi Kivity , qemu-devel@nongnu.org, freebsd-current@freebsd.org, Jan Kiszka , Mohammed Gamal Subject: Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 20:18:55 -0000 On Mon, Sep 07, 2009 at 10:17:23PM -0400, Ryan Stone wrote: > I'm not entirely clear on why it's done this way, but the timer is run at > twice hz for statistics-gathering purposes*. CPU usage statistics gathering > is driven off of the timer interrupt. Running the timer at twice hz may be > an attempt to eliminate clock-aliasing problems; if so, it's a poor way of > doing so. In any case, seeing interrupts come in at twice hz is expected > behaviour. This means that the guest will be requesting a timer interrupt > rate of twice the granularity that the host's scheduler can support; this > may be the cause of your other timing problems(although I have a hard time > imagining how). > Yes, this is the first issue I reported, and it causes e.g. a FreeBSD 7 guest on a 7 host to sleep ~4s on a `time sleep 2'. (unless when I disable apic as I said.) > This timer is twice hz behaviour has existed at least since FreeBSD 6.1, so > I can't explain why you see the new behaviour between 7 and 8. You do have > hz set to 1000 on both the guest and host when running 7? > Yes, and the behaviour on 8 is in addition to the guest expecting clock irqs at 2000 Hz, i.e. on 8 the guest gets only around 500 Hz with -clock unix instead of ~1000 Hz on a 7 host, and `time sleep 2' then consequently sleeps ~8s. > * Actually, from looking at the code the behaviour is dynamic. If hz >= > 1500, the timer interrupt rate is set to hz. If 750 <= hz < 1500, the timer > interrupt rate is set to 2 * hz. If hz < 750, the timer interrupt rate is > set to 4 * hz. Aha, so another way to get around the first issue would be to run at least the host with HZ=2000... Worth a try, tho I suspect it won't help the additional rate halving on 8, unless maybe to use even HZ=4000. Oh well... Juergen From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 20:20:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 047DA1065679; Wed, 9 Sep 2009 20:20:32 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC058FC1E; Wed, 9 Sep 2009 20:20:31 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-217-45.belrs3.nsw.optusnet.com.au [122.106.217.45]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n89KKSUO026920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2009 06:20:29 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n89KKSh9061658; Thu, 10 Sep 2009 06:20:28 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n89KKSsx061657; Thu, 10 Sep 2009 06:20:28 +1000 (EST) (envelope-from peter) Date: Thu, 10 Sep 2009 06:20:28 +1000 From: Peter Jeremy To: Kostik Belousov Message-ID: <20090909202028.GA61633@server.vk2pj.dyndns.org> References: <20090824193344.GA34949@server.vk2pj.dyndns.org> <20090829233454.GA13036@server.vk2pj.dyndns.org> <20090830144452.GK1881@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <20090830144452.GK1881@deviant.kiev.zoral.com.ua> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: sshd failing in jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 20:20:32 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable My apologies for the delay. Without warning, my ISP decided to disable the domain I was using for email and I have been busy repairing the damage. =20 On 2009-Aug-30 17:44:52 +0300, Kostik Belousov wrote: >On Sun, Aug 30, 2009 at 09:34:54AM +1000, Peter Jeremy wrote: >> Turns out this is a bug in the 32-bit select(2) wrapper on 64-bit >> kernels. The userland fd_set arguments are not wrapped but passed >> directly to kern_select(). Unfortunately, fd_set is (effectively) an >> array of longs which means kern_select() assumes fd_set is a multiple >> of 8-bytes whilst userland assumes it is a multiple of 4 bytes. As a >> result, the kernel can over-write an extra 4 bytes of user memory. In >> the case of sshd, this causes part of the RSA host key to be trashed >> when privilege separation mode is enabled. >>=20 >> This bug also affects linux emulation on amd64 and potentially affects >> any other 64-bit kernels with 32-bit emulation modes. I have raised >> amd64/138318 to cover it. > >I do not think that we can go the proposed route, since changing the >type of __fd_mask changes the type of fd_set. The later would not >affect the kernel ABI, but definitely changes the ABI of any code that >passes fd_sets. I agree it was something of a hack. >Also, looking closely at the issue you found, I think that copyin >is the same problematic as copyout, since we can end up reading >one more word then userspace supplied. This is not a problem only >because most user code keeps fd_sets on stack. Agreed. I was aware that copyin() could read an extra 4 bytes but did not work through the full implications of this - it is possible that select(2) could unexpectedly return EFAULT. >Could you test that the patch below fixes real sshd issue. At least, >it passes your select test from the PR. It works OK for me. Please feel free to commit it. --=20 Peter Jeremy --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqoDgwACgkQ/opHv/APuIdOAgCcD0iiHpCleOtsOOiEaJ8gvzVi +OIAnj9X0EaQrJsXE8nGWjMO45c4UxSG =Khz+ -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 20:39:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D961106568F for ; Wed, 9 Sep 2009 20:39:06 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id 998058FC1D for ; Wed, 9 Sep 2009 20:39:05 +0000 (UTC) Received: by ewy4 with SMTP id 4so3133332ewy.36 for ; Wed, 09 Sep 2009 13:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=y+M4z4N3vf96/fv8gpvrJAmlu7+9eOztvcEwti9h5mQ=; b=OVyd0XafBrGahKMK/xVesZ/fGQfc5DqK7L2eJfR7X9pOi2PlbUjMWwti2MLkKv1nKo FD6mo5MV+jxsrApdA3trDq2XKb+o6XMa2oo/fNTYPeNIIn3bYkF3oYJPvj1R9UNGx3P9 RBZREY795gE7qOh58xhabH8526HnlbddtBdo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wwjgeUAXH9hs0C9MZZ+qqcwxnJaY599xWuToyG5oIorjE7OFOnGz5c+6eBeQiR3g7g qIsNrBt4/a/6GXgOyQRZztNnCDt7ugfx0O3M3u63f2olRdsk3Kl2e3to2edZ4/UdBrW6 6zzzlmVMPundTOs/ABWouQ24T4v49f6k54ha4= MIME-Version: 1.0 Received: by 10.210.60.2 with SMTP id i2mr5150621eba.13.1252528744629; Wed, 09 Sep 2009 13:39:04 -0700 (PDT) In-Reply-To: <20090909201556.GA95426@triton8.kn-bremen.de> References: <52d4a3890908250321u746e5757u136030bcbc19208d@mail.gmail.com> <20090826221001.GA1070@triton8.kn-bremen.de> <4A96C8D9.6070804@web.de> <20090829211848.GA59305@triton8.kn-bremen.de> <4A9B800F.1040209@web.de> <20090831212723.GA32448@triton8.kn-bremen.de> <20090901201248.GA60123@triton8.kn-bremen.de> <20090907205955.GA91866@triton8.kn-bremen.de> <20090909201556.GA95426@triton8.kn-bremen.de> Date: Wed, 9 Sep 2009 16:39:04 -0400 Message-ID: From: Ryan Stone To: Juergen Lock Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Mohammed Gamal , freebsd-current@freebsd.org, Jan Kiszka , qemu-devel@nongnu.org, Avi Kivity Subject: Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 20:39:06 -0000 Luigi Rizzo recently posted a thread to current ( http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html) that would explain the new problem on FreeBSD 8. He posted a patch that you can try. From owner-freebsd-current@FreeBSD.ORG Wed Sep 9 20:58:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC9961065694 for ; Wed, 9 Sep 2009 20:58:51 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 771D98FC08 for ; Wed, 9 Sep 2009 20:58:51 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CB70273106; Wed, 9 Sep 2009 22:46:16 +0200 (CEST) Date: Wed, 9 Sep 2009 22:46:16 +0200 From: Luigi Rizzo To: Juergen Lock Message-ID: <20090909204616.GB93761@onelab2.iet.unipi.it> References: <52d4a3890908250316l4de68725xa9d780e7d5b37205@mail.gmail.com> <52d4a3890908250321u746e5757u136030bcbc19208d@mail.gmail.com> <4A93BF0C.8040601@web.de> <20090826221001.GA1070@triton8.kn-bremen.de> <4A96C8D9.6070804@web.de> <20090829211848.GA59305@triton8.kn-bremen.de> <4A9B800F.1040209@web.de> <20090831212723.GA32448@triton8.kn-bremen.de> <20090901201248.GA60123@triton8.kn-bremen.de> <20090907205955.GA91866@triton8.kn-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090907205955.GA91866@triton8.kn-bremen.de> User-Agent: Mutt/1.4.2.3i Cc: Mohammed Gamal , freebsd-current@freebsd.org, Jan Kiszka , qemu-devel@nongnu.org, Avi Kivity Subject: Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 20:58:51 -0000 On Mon, Sep 07, 2009 at 10:59:55PM +0200, Juergen Lock wrote: > [I'm copying freebsd-current@FreeBSD.org because ppl there might know > more about this...] > > qemu on FreeBSD hosts used to be able to run a (FreeBSD at least) guest > with the same HZ as the host (like, 1000) with (mostly) proper timing > once, but no longer. :( It seems there are two problems involved: > > a) use of apic seems to cause the clock irq rate to be doubled to 2 * HZ > (can anyone explain why?), i.e. a FreeBSD 7 guest on a FreeBSD 7 host > only gets proper timing after setting hint.apic.0.disabled=1 via the > loader. (as can be verified by `vmstat -i' and `time sleep 2' in an > installed guest or via the fixit->cdrom/dvd shell on a FreeBSD livefs > or dvd1 iso.) > > b) qemu running on FreeBSD 8 hosts (and most likely head) has the > additional problem of running its timers only at HZ/2 when using > setitimer(2) (called `-clock unix' in qemu), as seen below. (as also this problem in 8.x is caused by the bug i described here yesterday: http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html In qeumu, the setitimer call (in file vl.c) has a timeout of 1 tick which maps to callout_reset(..., 1, ...) and because (due to the bug) 8.x processes callouts 1 tick late, this effectively halves the clock rate. > seen below, timer_settime(2) aka `-clock dynticks' in qemu behaves > even worse, but that is similarly true on FreeBSD 7 which is why > I removed the patch that enabled that from our qemu port(s) a few > days ago.) And the only reason FreeBSD 8 guests are usually less > affected by these problems is they now reduce their HZ to 100 when > they detect being run in a VM. (which makes sense for other reasons > as well, don't get me wrong... but of course doesn't help when the > host is running with HZ=100 too.) cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 03:44:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4332C106566B for ; Thu, 10 Sep 2009 03:44:21 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1A1448FC15 for ; Thu, 10 Sep 2009 03:44:21 +0000 (UTC) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n8A3iJBR078621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Sep 2009 20:44:19 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4AA87613.9040600@errno.com> Date: Wed, 09 Sep 2009 20:44:19 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Borodin Oleg References: <4AA41025.5080908@yandex.ru> <4AA44B53.8060702@errno.com> <4AA77E4B.5060006@yandex.ru> In-Reply-To: <4AA77E4B.5060006@yandex.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant not found AP without SSID in beacon packet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 03:44:21 -0000 Borodin Oleg wrote: > Sam Leffler ÐÉÛÅÔ: >> Borodin Oleg wrote: >>> >>> Hi! >>> >>> wpa_supplicant "not found" AP without SSID in beacon packets. With same >>> device and configuration, but FreeBSD7.2 - work without problems. >>> >>> >> >> You seem to have disabled scan_ssid in your wpa_supplicant.conf file. >> It appears this causes wpa_supplicant to not supply the ssid when >> scanning so the net80211 layer never sends directed ProbeRequest >> frames and then ap does not respond. Try enabling scan_ssid for WNET1 >> and verify the directed probe request frames are sent. >> >> Sam >> _______________________________________________ >> > Of course, I tried to turn on and off scan_ssid. No results. If you don't show what you do then I cannot tell. You don't include the wlan debug msgs that show the directed ProbeRequest frames so I cannot be sure they are going out. If they are not sent then the ap will not respond. If you set scan_ssid and you're not seeing the ProbeRequest frames then you'll need to figure out why. > I do not know much logic WiFI, perhaps the problem with disassembly > beacon packet of access point? > > Or, more likely to parse the answer to the AP on ProbeRequest from FBSD? > > What is?... > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id > 133, len 30 This just means the beacon frame included an IE that was not handled. You appear to have to have enabled "elemid" debug msgs. Sam From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 04:37:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CE671065670 for ; Thu, 10 Sep 2009 04:37:15 +0000 (UTC) (envelope-from sweetnavelorange@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 02AFA8FC14 for ; Thu, 10 Sep 2009 04:37:14 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 4so1982922eyf.9 for ; Wed, 09 Sep 2009 21:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=l08s3ku55FQeTnD2x3OTSsxCnRPnRR+t627iVBz4UY0=; b=vZ6oJ8dTFIFAqHUmhv6EeH2IcDuFsfeHFOZcVZQv7uZAPh8rhCdZC9qJbpw/Itg8PC +N7cHmbbhR3A/C2n5yiDmWjQ/pU8WYhHu9j9+5UXG1jNJ0ErjI2yn5sp+vPeqGyQnyQd jiPYlixfxKg8g3kAz3wDiLn/+AqWUuSdWltZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Ud/fvDauj9IMrBqVw3Z0vnjXPQ8Q/MGfzuW7EYGUBUK5rvTasnBrFgmVDHGZJb0KoR 1j21qwFLLQAtOeI0U3hVSWYn3L03+rDMZ2j3pUBHhQIBh6U02Ug2XbhzSwNFxG7pP+4z xISonL73kvTJbn9jBpQJAscpW2OOjiahFLHaY= MIME-Version: 1.0 Received: by 10.216.29.201 with SMTP id i51mr222849wea.214.1252557433991; Wed, 09 Sep 2009 21:37:13 -0700 (PDT) In-Reply-To: <200909091631.01446.hselasky@c2i.net> References: <200909091631.01446.hselasky@c2i.net> Date: Thu, 10 Sep 2009 16:37:13 +1200 Message-ID: From: James Butler To: Hans Petter Selasky , FreeBSD CURRENT Mailing List Content-Type: text/plain; charset=UTF-8 Cc: Subject: Re: Fwd: Can't boot 8.0-BETA4 from USB stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 04:37:15 -0000 2009/9/10 Hans Petter Selasky : > On Tuesday 08 September 2009 23:45:00 James Butler wrote: >> I have tried on all the ports at the back of the box, but I just >> remembered there's another at the front which I will try this evening. >> What do you mean by "dummy USB device"? Just having something else >> plugged in at boot? I will also try another USB drive tonight. > > Yes. > OK, I tried all the available ports and various combinations of flash drives, all with the same result. I sometimes get this message from one drive: probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error probe0:umass-sim0:0:0:0): SCS Status: Check Condition probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) Is there anything else worth trying? Thanks, James From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 07:10:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40A48106566C for ; Thu, 10 Sep 2009 07:10:43 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id C893F8FC18 for ; Thu, 10 Sep 2009 07:10:42 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=QYI-qAVWAz4A:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=Ibob-NzIbugKaX7lp8oA:9 a=BQZWId0mLCRiPjeQkZPsZalkYBcA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1302613562; Thu, 10 Sep 2009 09:10:41 +0200 From: Hans Petter Selasky To: James Butler Date: Thu, 10 Sep 2009 09:11:09 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200909091631.01446.hselasky@c2i.net> In-Reply-To: X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909100911.10237.hselasky@c2i.net> Cc: FreeBSD CURRENT Mailing List Subject: Re: Fwd: Can't boot 8.0-BETA4 from USB stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 07:10:43 -0000 On Thursday 10 September 2009 06:37:13 James Butler wrote: > Is there anything else worth trying? Another brand of memory sticks? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 07:45:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC2B3106566B; Thu, 10 Sep 2009 07:45:33 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from www61.your-server.de (www61.your-server.de [213.133.104.61]) by mx1.freebsd.org (Postfix) with ESMTP id A964F8FC12; Thu, 10 Sep 2009 07:45:33 +0000 (UTC) Received: from [217.7.243.216] (helo=firewall.demig.intra) by www61.your-server.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MleLT-0004Yu-T9; Thu, 10 Sep 2009 09:45:32 +0200 Received: from [192.168.148.83] (ws-pr-3a.demig.intra [192.168.148.83]) by firewall.demig.intra (8.14.3/8.14.0) with ESMTP id n8A7jH0O046522; Thu, 10 Sep 2009 09:45:17 +0200 (CEST) (envelope-from nkoch@demig.de) Message-ID: <4AA8AE8D.7080307@demig.de> Date: Thu, 10 Sep 2009 09:45:17 +0200 From: Norbert Koch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: John Baldwin References: <4AA7D4BA.40002@demig.de> <200909091507.32600.jhb@freebsd.org> In-Reply-To: <200909091507.32600.jhb@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 192.168.148.235 X-Authenticated-Sender: webmaster@demig.de X-Virus-Scanned: Clear (ClamAV 0.95.1/9791/Thu Sep 10 03:03:33 2009) Cc: freebsd-current@freebsd.org Subject: Re: lock order reversal etc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 07:45:34 -0000 John Baldwin schrieb: > Try this patch for this one: > > Index: daemon_saver.c > =================================================================== > --- daemon_saver.c (revision 196974) > +++ daemon_saver.c (working copy) > @@ -351,11 +351,23 @@ > static int > daemon_init(video_adapter_t *adp) > { > + size_t hostlen; > > mtx_lock(&prison0.pr_mtx); > - messagelen = strlen(prison0.pr_hostname) + 3 + strlen(ostype) + 1 + > - strlen(osrelease); > - message = malloc(messagelen + 1, M_DEVBUF, M_WAITOK); > + for (;;) { > + hostlen = strlen(prison0.pr_hostname); > + mtx_unlock(&prison0.pr_mtx); > + > + messagelen = hostlen + 3 + strlen(ostype) + 1 + > + strlen(osrelease); > + message = malloc(messagelen + 1, M_DEVBUF, M_WAITOK); > + mtx_lock(&prison0.pr_mtx); > + if (hostlen < strlen(prison0.pr_hostname)) { > + free(message, M_DEVBUF); > + continue; > + } > + break; > + } > sprintf(message, "%s - %s %s", prison0.pr_hostname, ostype, osrelease); > mtx_unlock(&prison0.pr_mtx); > blanked = 0; > That works for me. Thank you. From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 09:13:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 809CA1065672; Thu, 10 Sep 2009 09:13:36 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id 402428FC08; Thu, 10 Sep 2009 09:13:35 +0000 (UTC) Received: from a91-153-125-115.elisa-laajakaista.fi (a91-153-125-115.elisa-laajakaista.fi [91.153.125.115]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id 4F6B8139CD2; Thu, 10 Sep 2009 12:13:29 +0300 (EEST) Date: Thu, 10 Sep 2009 12:13:29 +0300 From: Jaakko Heinonen To: Mel Flynn Message-ID: <20090910091329.GA2726@a91-153-125-115.elisa-laajakaista.fi> References: <20090908202553.GA1368@mr-happy.com> <20090908235731.GG1539@garage.freebsd.pl> <20090909005504.GA12660@mr-happy.com> <200909090902.34055.mel.flynn+fbsd.current@mailing.thruhere.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200909090902.34055.mel.flynn+fbsd.current@mailing.thruhere.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org, Pawel Jakub Dawidek , Jeff Blank Subject: Re: 8.0-BETA4 panic: ffs_sync: rofs mod X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 09:13:36 -0000 On 2009-09-09, Mel Flynn wrote: > This problem has also been seen on -questions [1] and I forgot to follow > up after time issues. According to the poster it's easy to reproduce: > - have a mountpoint in /etc/fstab with ro options > - unmount the mountpoint > - remount using -o rw This has been also reported as PR kern/133614. I have tried to reproduce the problem earlier but I didn't succeed until now. Here's how to reproduce it: 1. Have mountd(8) running 2. # mdconfig -a -t vnode -f ufsimg 3. # mount -o ro,rw /dev/md0 /mnt 4. # touch /mnt/foo && sync This is what's going on: Initial nmount() is done with "ro" and "rw" options. The mount point will have "ro", "rw" and "noro" string mount options after nmount(). MNT_RDONLY flag is not set. Then mountd(8) calls nmount() with "update" and "export" string options. This results FFS code to re-mount the file system as read-only because the "ro" string option is active for the mount point. ffs_mount() sets MNT_RDONLY and FFS fs_ronly flags. MNT_RDONLY gets later cleared in vfs_domount() because vfs_export() fails with ENOENT but the fs_ronly flag stays enabled. The most obvious problem seems to be that both "ro" and "rw" options are allowed to enter to mount point options concurrently. I don't have yet a fix to propose. -- Jaakko From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 14:09:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C59BA106566B for ; Thu, 10 Sep 2009 14:09:55 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5341F8FC17 for ; Thu, 10 Sep 2009 14:09:55 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 4so58363eyf.9 for ; Thu, 10 Sep 2009 07:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=3WP7YrBhZYrF76xmYFCiprowaGUdlgVI7sItsfbXly8=; b=Nd3bejI09XS6bV6t+5NXTa8B6FKx+DWIKwQ6zYyGymigP+zS17o6EYuWia2iq7swgt d84/A1dxDAbe7gf9chQ7KeqnF4hOiY+hOlszeWZ0GOVG+JUK3ag9cd7NE4te4Lo2Zwjw 960wbXQ9Oj1+n1Vznj4Ja72h0o3a+UiihQ1ow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NzdUhwnwVod/cCkrzH9Eb/1tzUqglbpoDssqZEss2jVUcWc0FucujS5TdXUnZb6trr YGj4fO60g2fU2UfhsJ6LgTVFoD+bmW+fWjeNVGIKeSMIf7OKkHWvZSMbC9TNgkRIwBYy W0eAEJ6WVKuD+52MDE9gP4O8uE/FSAg8fCse8= MIME-Version: 1.0 Received: by 10.211.129.8 with SMTP id g8mr1741935ebn.71.1252591794291; Thu, 10 Sep 2009 07:09:54 -0700 (PDT) In-Reply-To: <25cb30907080133l656fb10s6221607f00b3d193@mail.gmail.com> References: <25cb30907080133l656fb10s6221607f00b3d193@mail.gmail.com> Date: Thu, 10 Sep 2009 09:09:54 -0500 Message-ID: <179b97fb0909100709t33d372dfre14d00e93a935bcb@mail.gmail.com> From: Brandon Gooch To: chflags@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: regression in atkbd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 14:09:55 -0000 On Wed, Jul 8, 2009 at 3:33 AM, Kevin Foo wrote: > Hi hackers, > > Did anyone experience issue with atkbd on 8.0? I encountered issue with > keyboard and touchpad on HP presario V3400 when trying to upgrade from > 7.2-RELEASE to 8.0 prior to and on BETA1.The keyboard and touchpad are > working fine on 7.2. On 8.0 prior to BETA1, I managed to obtain dmesg via > ssh despite having a non-operational keyboard. The laptop was totally > inaccessible on 8.0 BETA1 as it freezed after the line atkbdc0. No > information could be obtained. > > Any ideas? Thanks. > > /boot/device.hints (default, no changes made) > hint.atkbdc.0.at="isa" > hint.atkbdc.0.port="0x060" > hint.atkbd.0.at="atkbdc" > hint.atkbd.0.irq="1" > hint.psm.0.at="atkbdc" > hint.psm.0.irq="12" > > 1) FreeBSD 8.0-BETA1 amd64 as of today with GENERIC kernel:- > <---snip---< > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > system hangs...... > > > 2) FreeBSD 8.0-CURRENT amd64 prior to BETA1 custom kernel without > debug/invariant/witness:- > <---snip---< > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0047 > atkbd: unable to set the command byte. > kbd0 at atkbd0 > kbd0: atkbd0, generic (0), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 55 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: unable to allocate IRQ > psmcpnp0: irq 12 on acpi0 > psm0: current command byte:0047 > psm0: unable to set the command byte. > <---snip---< > Full verbosed dmesg at http://ms.shit.la/FreeBSD/dmesg.8.txt > > > 3) FreeBSD 7.2-RELEASE-p2 amd64:- > <---snip---< > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0047 > atkbd: keyboard ID 0x41ab (2) > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to vector 57 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: unable to allocate IRQ > psmcpnp0: irq 12 on acpi0 > psm0: current command byte:0047 > psm0: irq 12 on atkbdc0 > ioapic0: routing intpin 12 (ISA IRQ 12) to vector 58 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse, device ID 3-00, 3 buttons > psm0: config:00000000, flags:00000008, packet size:4 > psm0: syncmask:08, syncbits:00 > <---snip---< > Full verbosed dmesg at http://ms.shit.la/FreeBSD/dmesg.7.txt > > -- > Regards > Kevin Foo > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > What does your /boot/loader.conf look like? I had a similar issue when: 1. booting GENERIC kernel but without debugging and WITNESS compiled in and 2. my /boot/loader.conf contained the leftover entry 'ukbd_load="YES"' from when I was using my custom, modular kernel If either one of those or both was not true, I was able to boot as usual. Strange. I never investigated any further... -Brandon From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 12:48:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEAE01065672 for ; Thu, 10 Sep 2009 12:48:02 +0000 (UTC) (envelope-from luckrill@gmail.com) Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by mx1.freebsd.org (Postfix) with ESMTP id A3AC58FC12 for ; Thu, 10 Sep 2009 12:48:02 +0000 (UTC) Received: by pzk29 with SMTP id 29so53308pzk.14 for ; Thu, 10 Sep 2009 05:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=oKIzlONZEpBv49zGv5k4tKmbPi79gAEj2oCUxSpJSr0=; b=R9x9xikFpsI1z6FAeJmp/4ei/2bfrBFwod1llrhMB5LaoFrNU0Q68coKgBxOeJXyCs 0KejAz0kzMIWYCR/G+B3GIexi9eE+VVWrWCiIZwHBXAAI+VTZHm3if0frrNHenUoKv/D q8yj/SMIR11VRUuWhq6qyUNKvazc5uvDSgqpI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=THlPN0DWX88NPlZFy3jIcrdqTo2jzemYZr3vZk3IIz8S3D7NTYB4PCepfaad62Lb2L R8rDSVNe5F+Y+rQHiHyxO8cWjmgXacx92Pv2TCj7PHWIKi30MgtALxEpYCYff9wAiS/s k2/B1tlcgq2m1vWsulk/6ADSNn1Bga4WitW9M= MIME-Version: 1.0 Received: by 10.115.24.10 with SMTP id b10mr887515waj.127.1252586879847; Thu, 10 Sep 2009 05:47:59 -0700 (PDT) Date: Thu, 10 Sep 2009 20:47:59 +0800 Message-ID: From: Rill To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 10 Sep 2009 15:12:37 +0000 Subject: 8.0-BETA4 bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 12:48:02 -0000 today meet two bugs: 1, Install gnome2 filed from packages I install freebsd with 8.0-BETA4-i386-dvd1.iso Then I install kde4 and gnome2 from packages. My step is: First: I install kde4 from packages, It's succeed. Second: I install gnome2 from packages, It's failed and meet following message: screensaver-gnome-hacks-5.08_1 Loading of dependent package xscreensaver-gnome-hacks-5.08_1 failed Loading of dependent package gnome-screensaver-2.26.1_1 failed But, if I install gnome2 first, then install kde4, this time all will be succeed. This bug I have also meet on FreeBSD7.2 and FreeBSD8.0-BETA. 2, compile /usr/ports/textproc/docbook-utils filed: the following is bug message: jade:../../doc/refentry/jw.sgml:79:88:E: element "SBR" undefined jade:../../doc/refentry/jw.sgml:81:25:E: element "GROUP" undefined jade:../../doc/refentry/jw.sgml:82:12:E: element "ARG" undefined jade:../../doc/refentry/jw.sgml:82:20:E: element "OPTION" undefined jade:I: maximum number of errors (200) reached; change with -E option gmake[2]: *** [api.html] Error 1 gmake[2]: Leaving directory `/usr/ports/textproc/docbook-utils/work/docbook-utils-0.6.14/doc/HTML' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/textproc/docbook-utils/work/docbook-utils-0.6.14/doc' gmake: *** [all-recursive] Error 1 *** Error code 1 Stop in /usr/ports/textproc/docbook-utils. My system is: WinXP + VMware6.0 + FreeBSD8.0-BETA4 -- jiang zhixiang From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 17:50:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0BB8106566B for ; Thu, 10 Sep 2009 17:50:18 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 606728FC19 for ; Thu, 10 Sep 2009 17:50:18 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 4CFAA1E0038A; Thu, 10 Sep 2009 19:50:17 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n8AHkfHE030922; Thu, 10 Sep 2009 19:46:41 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id n8AHketJ030921; Thu, 10 Sep 2009 19:46:40 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Thu, 10 Sep 2009 19:46:40 +0200 To: Luigi Rizzo Message-ID: <20090910174640.GA30706@triton8.kn-bremen.de> References: <52d4a3890908250321u746e5757u136030bcbc19208d@mail.gmail.com> <4A93BF0C.8040601@web.de> <20090826221001.GA1070@triton8.kn-bremen.de> <4A96C8D9.6070804@web.de> <20090829211848.GA59305@triton8.kn-bremen.de> <4A9B800F.1040209@web.de> <20090831212723.GA32448@triton8.kn-bremen.de> <20090901201248.GA60123@triton8.kn-bremen.de> <20090907205955.GA91866@triton8.kn-bremen.de> <20090909204616.GB93761@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090909204616.GB93761@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Juergen Lock , Avi Kivity , qemu-devel@nongnu.org, freebsd-current@freebsd.org, Jan Kiszka , Mohammed Gamal Subject: Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 17:50:19 -0000 On Wed, Sep 09, 2009 at 10:46:16PM +0200, Luigi Rizzo wrote: > On Mon, Sep 07, 2009 at 10:59:55PM +0200, Juergen Lock wrote: > > [I'm copying freebsd-current@FreeBSD.org because ppl there might know > > more about this...] > > > > qemu on FreeBSD hosts used to be able to run a (FreeBSD at least) guest > > with the same HZ as the host (like, 1000) with (mostly) proper timing > > once, but no longer. :( It seems there are two problems involved: > > > > a) use of apic seems to cause the clock irq rate to be doubled to 2 * HZ > > (can anyone explain why?), i.e. a FreeBSD 7 guest on a FreeBSD 7 host > > only gets proper timing after setting hint.apic.0.disabled=1 via the > > loader. (as can be verified by `vmstat -i' and `time sleep 2' in an > > installed guest or via the fixit->cdrom/dvd shell on a FreeBSD livefs > > or dvd1 iso.) > > > > b) qemu running on FreeBSD 8 hosts (and most likely head) has the > > additional problem of running its timers only at HZ/2 when using > > setitimer(2) (called `-clock unix' in qemu), as seen below. (as also > > this problem in 8.x is caused by the bug i described here yesterday: > > http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html > > In qeumu, the setitimer call (in file vl.c) has a timeout of 1 tick > which maps to callout_reset(..., 1, ...) and because (due to the bug) > 8.x processes callouts 1 tick late, this effectively halves the clock rate. > Thanx for the pointer! The proposed patch in that post didn't make a different here tho, guest still sees only half host HZ clock irq rate. (i.e. ~500 Hz.) Here is the patch I used, to make sure I patched what you meant... Index: sys/kern/kern_timeout.c @@ -323,7 +323,7 @@ softclock(void *arg) steps = 0; cc = (struct callout_cpu *)arg; CC_LOCK(cc); - while (cc->cc_softticks != ticks) { + while (cc->cc_softticks-1 != ticks) { /* * cc_softticks may be modified by hard clock, so cache * it while we work on a given bucket. > > seen below, timer_settime(2) aka `-clock dynticks' in qemu behaves > > even worse, but that is similarly true on FreeBSD 7 which is why > > I removed the patch that enabled that from our qemu port(s) a few > > days ago.) And the only reason FreeBSD 8 guests are usually less > > affected by these problems is they now reduce their HZ to 100 when > > they detect being run in a VM. (which makes sense for other reasons > > as well, don't get me wrong... but of course doesn't help when the > > host is running with HZ=100 too.) > > cheers > luigi Cheers, Juergen From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 17:50:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48AD21065672 for ; Thu, 10 Sep 2009 17:50:22 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id CA20A8FC1C for ; Thu, 10 Sep 2009 17:50:21 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 4so115856eyf.9 for ; Thu, 10 Sep 2009 10:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=QAiULUPxfv9T0ro9cDR3XGnooDiZ7E04DxnY2u7F/wg=; b=qdZc8TViHJA36IFw3W9uJVS9pkv2js0MYrgj/pEvbrnTNnrnZFOfXeBqRyKql0bIKu ZdqLEMAzP/a2Be86xgNgPko/kk1nY30bZQMPLb7REBZ1yfgrwdc1xRNeGxo0h9EGtMDh 8Zi0S53ejGtnrsS7eDs/CVn80LIC+IkgQfvgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ITvPkC3BafU0Gwz25BaOuAD7gIrcTvPcrBzuYyM5JrwK/uc1hNsbvWLY2hD00FYDKm l/zzfCGUHJdcklxP4x7mai/q4aYttcvSX6JwVzrjbfVqlK84JWaEhp5zz7bAWSicTXB9 9oHr5QwQNTUlSWxPKgpkEcyyT/KBPb6SdVN7A= MIME-Version: 1.0 Sender: sektie@gmail.com Received: by 10.211.154.18 with SMTP id g18mr2121444ebo.70.1252605020474; Thu, 10 Sep 2009 10:50:20 -0700 (PDT) In-Reply-To: References: <200909091631.01446.hselasky@c2i.net> Date: Thu, 10 Sep 2009 10:50:20 -0700 X-Google-Sender-Auth: 3df10334c9adb1b0 Message-ID: From: Randi Harper To: James Butler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD CURRENT Mailing List , Hans Petter Selasky Subject: Re: Fwd: Can't boot 8.0-BETA4 from USB stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 17:50:22 -0000 On Wed, Sep 9, 2009 at 9:37 PM, James Butler wrote: > 2009/9/10 Hans Petter Selasky : > > On Tuesday 08 September 2009 23:45:00 James Butler wrote: > >> I have tried on all the ports at the back of the box, but I just > >> remembered there's another at the front which I will try this evening. > >> What do you mean by "dummy USB device"? Just having something else > >> plugged in at boot? I will also try another USB drive tonight. > > > > Yes. > > > > OK, I tried all the available ports and various combinations of flash > drives, all with the same result. I sometimes get this message from > one drive: > > probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > probe0:umass-sim0:0:0:0): SCS Status: Check Condition > probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 > probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have > changed > probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) > > Is there anything else worth trying? > > Thanks, > James > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > It's worth noting that some USB flash drives (particularly old or low-quality ones) take longer to detect than others, as was found with sysinstall/USB installs. I don't really know of a way around this other than using a different USB flash drive. -- randi From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 19:02:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D757B106566C for ; Thu, 10 Sep 2009 19:02:01 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 958B98FC12 for ; Thu, 10 Sep 2009 19:02:01 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 70927730DA; Thu, 10 Sep 2009 21:08:00 +0200 (CEST) Date: Thu, 10 Sep 2009 21:08:00 +0200 From: Luigi Rizzo To: Juergen Lock Message-ID: <20090910190800.GA14191@onelab2.iet.unipi.it> References: <4A93BF0C.8040601@web.de> <20090826221001.GA1070@triton8.kn-bremen.de> <4A96C8D9.6070804@web.de> <20090829211848.GA59305@triton8.kn-bremen.de> <4A9B800F.1040209@web.de> <20090831212723.GA32448@triton8.kn-bremen.de> <20090901201248.GA60123@triton8.kn-bremen.de> <20090907205955.GA91866@triton8.kn-bremen.de> <20090909204616.GB93761@onelab2.iet.unipi.it> <20090910174640.GA30706@triton8.kn-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090910174640.GA30706@triton8.kn-bremen.de> User-Agent: Mutt/1.4.2.3i Cc: Mohammed Gamal , freebsd-current@freebsd.org, Jan Kiszka , qemu-devel@nongnu.org, Avi Kivity Subject: Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 19:02:01 -0000 On Thu, Sep 10, 2009 at 07:46:40PM +0200, Juergen Lock wrote: > On Wed, Sep 09, 2009 at 10:46:16PM +0200, Luigi Rizzo wrote: > > On Mon, Sep 07, 2009 at 10:59:55PM +0200, Juergen Lock wrote: > > > [I'm copying freebsd-current@FreeBSD.org because ppl there might know > > > more about this...] > > > > > > qemu on FreeBSD hosts used to be able to run a (FreeBSD at least) guest > > > with the same HZ as the host (like, 1000) with (mostly) proper timing > > > once, but no longer. :( It seems there are two problems involved: > > > > > > a) use of apic seems to cause the clock irq rate to be doubled to 2 * HZ > > > (can anyone explain why?), i.e. a FreeBSD 7 guest on a FreeBSD 7 host > > > only gets proper timing after setting hint.apic.0.disabled=1 via the > > > loader. (as can be verified by `vmstat -i' and `time sleep 2' in an > > > installed guest or via the fixit->cdrom/dvd shell on a FreeBSD livefs > > > or dvd1 iso.) > > > > > > b) qemu running on FreeBSD 8 hosts (and most likely head) has the > > > additional problem of running its timers only at HZ/2 when using > > > setitimer(2) (called `-clock unix' in qemu), as seen below. (as also > > > > this problem in 8.x is caused by the bug i described here yesterday: > > > > http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html > > > > In qeumu, the setitimer call (in file vl.c) has a timeout of 1 tick > > which maps to callout_reset(..., 1, ...) and because (due to the bug) > > 8.x processes callouts 1 tick late, this effectively halves the clock rate. > > > Thanx for the pointer! > > The proposed patch in that post didn't make a different here tho, > guest still sees only half host HZ clock irq rate. (i.e. ~500 Hz.) > > Here is the patch I used, to make sure I patched what you meant... > > Index: sys/kern/kern_timeout.c > @@ -323,7 +323,7 @@ softclock(void *arg) > steps = 0; > cc = (struct callout_cpu *)arg; > CC_LOCK(cc); > - while (cc->cc_softticks != ticks) { > + while (cc->cc_softticks-1 != ticks) { > /* > * cc_softticks may be modified by hard clock, so cache > * it while we work on a given bucket. > as mentioned in the followup message in that thread, you also need this change in callout_tick() mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET); - for (; (cc->cc_softticks - ticks) < 0; cc->cc_softticks++) { + for (; (cc->cc_softticks - ticks) <= 0; cc->cc_softticks++) { bucket = cc->cc_softticks & callwheelmask; cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 20:45:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCE111065679 for ; Thu, 10 Sep 2009 20:45:47 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC4F8FC12 for ; Thu, 10 Sep 2009 20:45:47 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 5A5991E005A0; Thu, 10 Sep 2009 22:45:46 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n8AKiXZ2002264; Thu, 10 Sep 2009 22:44:33 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id n8AKiVRq002263; Thu, 10 Sep 2009 22:44:31 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Thu, 10 Sep 2009 22:44:31 +0200 To: Luigi Rizzo Message-ID: <20090910204431.GA2102@triton8.kn-bremen.de> References: <20090826221001.GA1070@triton8.kn-bremen.de> <4A96C8D9.6070804@web.de> <20090829211848.GA59305@triton8.kn-bremen.de> <4A9B800F.1040209@web.de> <20090831212723.GA32448@triton8.kn-bremen.de> <20090901201248.GA60123@triton8.kn-bremen.de> <20090907205955.GA91866@triton8.kn-bremen.de> <20090909204616.GB93761@onelab2.iet.unipi.it> <20090910174640.GA30706@triton8.kn-bremen.de> <20090910190800.GA14191@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090910190800.GA14191@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Juergen Lock , Avi Kivity , qemu-devel@nongnu.org, freebsd-current@freebsd.org, Jan Kiszka , Mohammed Gamal Subject: Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 20:45:48 -0000 On Thu, Sep 10, 2009 at 09:08:00PM +0200, Luigi Rizzo wrote: > On Thu, Sep 10, 2009 at 07:46:40PM +0200, Juergen Lock wrote: > > On Wed, Sep 09, 2009 at 10:46:16PM +0200, Luigi Rizzo wrote: > > > On Mon, Sep 07, 2009 at 10:59:55PM +0200, Juergen Lock wrote: > > > > [I'm copying freebsd-current@FreeBSD.org because ppl there might know > > > > more about this...] > > > > > > > > qemu on FreeBSD hosts used to be able to run a (FreeBSD at least) guest > > > > with the same HZ as the host (like, 1000) with (mostly) proper timing > > > > once, but no longer. :( It seems there are two problems involved: > > > > > > > > a) use of apic seems to cause the clock irq rate to be doubled to 2 * HZ > > > > (can anyone explain why?), i.e. a FreeBSD 7 guest on a FreeBSD 7 host > > > > only gets proper timing after setting hint.apic.0.disabled=1 via the > > > > loader. (as can be verified by `vmstat -i' and `time sleep 2' in an > > > > installed guest or via the fixit->cdrom/dvd shell on a FreeBSD livefs > > > > or dvd1 iso.) > > > > > > > > b) qemu running on FreeBSD 8 hosts (and most likely head) has the > > > > additional problem of running its timers only at HZ/2 when using > > > > setitimer(2) (called `-clock unix' in qemu), as seen below. (as also > > > > > > this problem in 8.x is caused by the bug i described here yesterday: > > > > > > http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html > > > > > > In qeumu, the setitimer call (in file vl.c) has a timeout of 1 tick > > > which maps to callout_reset(..., 1, ...) and because (due to the bug) > > > 8.x processes callouts 1 tick late, this effectively halves the clock rate. > > > > > Thanx for the pointer! > > > > The proposed patch in that post didn't make a different here tho, > > guest still sees only half host HZ clock irq rate. (i.e. ~500 Hz.) > > > > Here is the patch I used, to make sure I patched what you meant... > > > > Index: sys/kern/kern_timeout.c > > @@ -323,7 +323,7 @@ softclock(void *arg) > > steps = 0; > > cc = (struct callout_cpu *)arg; > > CC_LOCK(cc); > > - while (cc->cc_softticks != ticks) { > > + while (cc->cc_softticks-1 != ticks) { > > /* > > * cc_softticks may be modified by hard clock, so cache > > * it while we work on a given bucket. > > > > as mentioned in the followup message in that thread, > you also need this change in callout_tick() > > mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET); > - for (; (cc->cc_softticks - ticks) < 0; cc->cc_softticks++) { > + for (; (cc->cc_softticks - ticks) <= 0; cc->cc_softticks++) { > bucket = cc->cc_softticks & callwheelmask; > Ah I missed that, now guest clock irqs are back to HZ indeed. Thanx, :) Juergen From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 20:58:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58B071065670; Thu, 10 Sep 2009 20:58:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 32F0F8FC0A; Thu, 10 Sep 2009 20:58:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n8AKwL3l010362; Thu, 10 Sep 2009 16:58:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n8AKwLeT010348; Thu, 10 Sep 2009 20:58:21 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Sep 2009 20:58:21 GMT Message-Id: <200909102058.n8AKwLeT010348@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 20:58:22 -0000 TB --- 2009-09-10 19:45:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-10 19:45:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-09-10 19:45:00 - cleaning the object tree TB --- 2009-09-10 19:45:42 - cvsupping the source tree TB --- 2009-09-10 19:45:42 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-09-10 19:46:55 - building world TB --- 2009-09-10 19:46:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-10 19:46:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-10 19:46:55 - TARGET=pc98 TB --- 2009-09-10 19:46:55 - TARGET_ARCH=i386 TB --- 2009-09-10 19:46:55 - TZ=UTC TB --- 2009-09-10 19:46:55 - __MAKE_CONF=/dev/null TB --- 2009-09-10 19:46:55 - cd /src TB --- 2009-09-10 19:46:55 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 10 19:46:56 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Sep 10 20:53:02 UTC 2009 TB --- 2009-09-10 20:53:02 - generating LINT kernel config TB --- 2009-09-10 20:53:02 - cd /src/sys/pc98/conf TB --- 2009-09-10 20:53:02 - /usr/bin/make -B LINT TB --- 2009-09-10 20:53:02 - building LINT kernel TB --- 2009-09-10 20:53:02 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-10 20:53:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-10 20:53:02 - TARGET=pc98 TB --- 2009-09-10 20:53:02 - TARGET_ARCH=i386 TB --- 2009-09-10 20:53:02 - TZ=UTC TB --- 2009-09-10 20:53:02 - __MAKE_CONF=/dev/null TB --- 2009-09-10 20:53:02 - cd /src TB --- 2009-09-10 20:53:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 10 20:53:02 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_mq_start_locked': /src/sys/dev/e1000/if_em.c:1037: warning: suggest parentheses around assignment used as truth value /src/sys/dev/e1000/if_em.c:1067: warning: suggest parentheses around assignment used as truth value *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-10 20:58:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-10 20:58:21 - ERROR: failed to build lint kernel TB --- 2009-09-10 20:58:21 - 2844.02 user 469.02 system 4400.22 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 21:05:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90DDF106566C; Thu, 10 Sep 2009 21:05:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 530F28FC16; Thu, 10 Sep 2009 21:05:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n8AL5wMS080260; Thu, 10 Sep 2009 17:05:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n8AL5wNn080259; Thu, 10 Sep 2009 21:05:58 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Sep 2009 21:05:58 GMT Message-Id: <200909102105.n8AL5wNn080259@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 21:05:59 -0000 TB --- 2009-09-10 19:45:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-10 19:45:00 - starting HEAD tinderbox run for i386/i386 TB --- 2009-09-10 19:45:00 - cleaning the object tree TB --- 2009-09-10 19:46:00 - cvsupping the source tree TB --- 2009-09-10 19:46:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2009-09-10 19:51:47 - building world TB --- 2009-09-10 19:51:47 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-10 19:51:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-10 19:51:47 - TARGET=i386 TB --- 2009-09-10 19:51:47 - TARGET_ARCH=i386 TB --- 2009-09-10 19:51:47 - TZ=UTC TB --- 2009-09-10 19:51:47 - __MAKE_CONF=/dev/null TB --- 2009-09-10 19:51:47 - cd /src TB --- 2009-09-10 19:51:47 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 10 19:51:48 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Sep 10 20:59:20 UTC 2009 TB --- 2009-09-10 20:59:20 - generating LINT kernel config TB --- 2009-09-10 20:59:20 - cd /src/sys/i386/conf TB --- 2009-09-10 20:59:20 - /usr/bin/make -B LINT TB --- 2009-09-10 20:59:20 - building LINT kernel TB --- 2009-09-10 20:59:20 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-10 20:59:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-10 20:59:20 - TARGET=i386 TB --- 2009-09-10 20:59:20 - TARGET_ARCH=i386 TB --- 2009-09-10 20:59:20 - TZ=UTC TB --- 2009-09-10 20:59:20 - __MAKE_CONF=/dev/null TB --- 2009-09-10 20:59:20 - cd /src TB --- 2009-09-10 20:59:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 10 20:59:20 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/eisa/eisaconf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_mq_start_locked': /src/sys/dev/e1000/if_em.c:1037: warning: suggest parentheses around assignment used as truth value /src/sys/dev/e1000/if_em.c:1067: warning: suggest parentheses around assignment used as truth value *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-10 21:05:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-10 21:05:58 - ERROR: failed to build lint kernel TB --- 2009-09-10 21:05:58 - 2930.05 user 474.92 system 4857.75 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 21:26:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBB50106566B for ; Thu, 10 Sep 2009 21:26:14 +0000 (UTC) (envelope-from daniel@toomuchdata.se) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 86F488FC1E for ; Thu, 10 Sep 2009 21:26:14 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 4so164346eyf.9 for ; Thu, 10 Sep 2009 14:26:13 -0700 (PDT) Received: by 10.211.145.11 with SMTP id x11mr2221656ebn.74.1252616397142; Thu, 10 Sep 2009 13:59:57 -0700 (PDT) Received: from ?192.168.42.3? (hd5e26117.gavlegardarna.gavle.to [213.226.97.23]) by mx.google.com with ESMTPS id 7sm2214966eyb.26.2009.09.10.13.59.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Sep 2009 13:59:56 -0700 (PDT) Message-ID: <4AA968C6.6000405@toomuchdata.se> Date: Thu, 10 Sep 2009 22:59:50 +0200 From: Daniel Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: FreeBSD CURRENT Mailing List References: <200909091631.01446.hselasky@c2i.net> <200909100911.10237.hselasky@c2i.net> In-Reply-To: <200909100911.10237.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: James Butler , Hans Petter Selasky Subject: Re: Fwd: Can't boot 8.0-BETA4 from USB stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 21:26:15 -0000 On 2009-09-10 09:11, Hans Petter Selasky wrote: > Another brand of memory sticks? I had the same problem trying to boot 8.0-BETA2 from an USB stick. The da0 device showed up too late, causing the boot to fail. Manually entering the boot device allowed the boot to continue. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 21:33:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7283106566B; Thu, 10 Sep 2009 21:33:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B0CEA8FC15; Thu, 10 Sep 2009 21:33:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n8ALXdti007131; Thu, 10 Sep 2009 17:33:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n8ALXdTj007130; Thu, 10 Sep 2009 21:33:39 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Sep 2009 21:33:39 GMT Message-Id: <200909102133.n8ALXdTj007130@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 21:33:39 -0000 TB --- 2009-09-10 19:45:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-10 19:45:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-09-10 19:45:00 - cleaning the object tree TB --- 2009-09-10 19:46:07 - cvsupping the source tree TB --- 2009-09-10 19:46:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-09-10 19:51:51 - building world TB --- 2009-09-10 19:51:51 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-10 19:51:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-10 19:51:51 - TARGET=amd64 TB --- 2009-09-10 19:51:51 - TARGET_ARCH=amd64 TB --- 2009-09-10 19:51:51 - TZ=UTC TB --- 2009-09-10 19:51:51 - __MAKE_CONF=/dev/null TB --- 2009-09-10 19:51:51 - cd /src TB --- 2009-09-10 19:51:51 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 10 19:51:51 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Sep 10 21:27:35 UTC 2009 TB --- 2009-09-10 21:27:35 - generating LINT kernel config TB --- 2009-09-10 21:27:35 - cd /src/sys/amd64/conf TB --- 2009-09-10 21:27:35 - /usr/bin/make -B LINT TB --- 2009-09-10 21:27:36 - building LINT kernel TB --- 2009-09-10 21:27:36 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-10 21:27:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-10 21:27:36 - TARGET=amd64 TB --- 2009-09-10 21:27:36 - TARGET_ARCH=amd64 TB --- 2009-09-10 21:27:36 - TZ=UTC TB --- 2009-09-10 21:27:36 - __MAKE_CONF=/dev/null TB --- 2009-09-10 21:27:36 - cd /src TB --- 2009-09-10 21:27:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 10 21:27:36 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_mq_start_locked': /src/sys/dev/e1000/if_em.c:1037: warning: suggest parentheses around assignment used as truth value /src/sys/dev/e1000/if_em.c:1067: warning: suggest parentheses around assignment used as truth value *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-10 21:33:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-10 21:33:38 - ERROR: failed to build lint kernel TB --- 2009-09-10 21:33:38 - 4089.37 user 694.49 system 6518.01 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 21:48:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19287106566C for ; Thu, 10 Sep 2009 21:48:19 +0000 (UTC) (envelope-from sweetnavelorange@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id A33E28FC17 for ; Thu, 10 Sep 2009 21:48:18 +0000 (UTC) Received: by ewy4 with SMTP id 4so556636ewy.36 for ; Thu, 10 Sep 2009 14:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=T4pQ3+CEF58VqU9f9jDviEr8QG5eEXC52POjWZjUjt8=; b=n04rYyXfNvWGCV9z1Jwl8wmKTPGMgl2px3a2HomcvJ2jWfuaXsXU6RsFzb7dFukV6p CVpt8XolCXQfrDqAYsSAyNpfHPAlHoVIWke0qAkkWPf2WuyGeuR2K302dzbyE9ibF6p0 c2itJMIwqGHcNGlPgRiH+GXDpV98/pS3rS1no= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=I1KZjcRTUuY0oR9a0tM3M9yYmQ1IUld3wcZk/cVf22oQYL76PAg++9wewkzQXjntgX EfWaA+0VtiUHT/gW/ou+fUxeuvDXRwkK1wUfZXF+HOB9I567G20UAfL/42BUi2UP1E39 MhDfjmOI5KS5MgGSop40Zi6SwRIIKlP2ofds0= MIME-Version: 1.0 Received: by 10.216.88.6 with SMTP id z6mr604276wee.52.1252619297447; Thu, 10 Sep 2009 14:48:17 -0700 (PDT) In-Reply-To: <200909100911.10237.hselasky@c2i.net> References: <200909091631.01446.hselasky@c2i.net> <200909100911.10237.hselasky@c2i.net> Date: Fri, 11 Sep 2009 09:48:17 +1200 Message-ID: From: James Butler To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD CURRENT Mailing List Subject: Re: Fwd: Can't boot 8.0-BETA4 from USB stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 21:48:19 -0000 2009/9/10 Hans Petter Selasky : > On Thursday 10 September 2009 06:37:13 James Butler wrote: >> Is there anything else worth trying? > > Another brand of memory sticks? I have only the three different brands that I tried (Toshiba and two different no-names). Is there really nothing like an adjustable delay at boot? Perhaps it's time to spend NZD$30 on a CF card and IDE adapter, but that will be of limited use for troubleshooting or installation. -James From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 21:53:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385031065692; Thu, 10 Sep 2009 21:53:00 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206049004.chello.pl [87.206.49.4]) by mx1.freebsd.org (Postfix) with ESMTP id 610638FC12; Thu, 10 Sep 2009 21:52:59 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3FC4845CAC; Thu, 10 Sep 2009 23:52:57 +0200 (CEST) Received: from localhost (chello087206049004.chello.pl [87.206.49.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id E034B45C98; Thu, 10 Sep 2009 23:52:51 +0200 (CEST) Date: Thu, 10 Sep 2009 23:52:54 +0200 From: Pawel Jakub Dawidek To: Tobias Lott Message-ID: <20090910215254.GD2718@garage.freebsd.pl> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> <20090909054249.GH1539@garage.freebsd.pl> <20090909101346.01887a02@sub.han.vpn.gamesnet.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BI5RvnYi6R4T2M87" Content-Disposition: inline In-Reply-To: <20090909101346.01887a02@sub.han.vpn.gamesnet.de> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Problems with ZFS on AMD64 (and i386 now) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 21:53:00 -0000 --BI5RvnYi6R4T2M87 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 09, 2009 at 10:13:46AM +0200, Tobias Lott wrote: >=20 >=20 > On Wed, 9 Sep 2009 07:42:49 +0200 > Pawel Jakub Dawidek wrote: >=20 > > On Wed, Sep 09, 2009 at 12:19:42AM +0200, Tobias Lott wrote: > > > Hey Everyone > > >=20 > > > I've managed to get some Output for this, using BETA2 LiveCD (gonna > > > try using BETA4 CD Tomorrow). > > >=20 > > > 'zfs import -f poolname' triggered this, Booting kernel.old (BETA3) > > > and today built BETA4 Kernel Panic mounting zfs Volumes. > > > Booting single user mode I get output of zfs list and so on but > > > mounting whatever volume also Panics. > >=20 > > Why -f? Were there a poblem in importing pool? > >=20 > > > Stack output, if there's more you need I'll gladly help > > > http://i27.tinypic.com/2d78qpd.jpg > > > http://i31.tinypic.com/oqhv2w.jpg > > > http://i28.tinypic.com/oktsag.jpg > >=20 > > Could you also provide top part of the backtrace? > >=20 > Oh yeah my bad >=20 > http://i29.tinypic.com/nqwxo2.jpg > http://i26.tinypic.com/209hanm.jpg Seems that one of the vdevs is NULL. Could you tell me why you decided to use -f option for importing the pool? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --BI5RvnYi6R4T2M87 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKqXU2ForvXbEpPzQRAgKuAKDDMWtwMCA0LPOm/oEost64rX5o9ACfTsMr rddEMv0fHzSxaJgLD7Ov+Qk= =zKGR -----END PGP SIGNATURE----- --BI5RvnYi6R4T2M87-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 22:07:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1DA5106566C for ; Thu, 10 Sep 2009 22:07:43 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id 4EBD48FC0C for ; Thu, 10 Sep 2009 22:07:42 +0000 (UTC) Received: by ewy4 with SMTP id 4so570994ewy.36 for ; Thu, 10 Sep 2009 15:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=WaVGwSfatZDpBXDAJ4WHidMh/Sw6tcrGeBJQeT5jO2w=; b=p7ssk5g958tTAa29T+NzuzImIzMDL+5rrlCPWWkADqzjW8xiPl278vLfQVArWMZzlm QJGuxZ1M2GFmOUUVg9fGBDtm/C5e6i2IEe3DKA5mT/76YVBDclLeIMcQgc9Q+rWdWOcu VUPQg6Ba2eAacohUpgzuF5d9Em0vCwpCJRcgM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=k+s5W+xtk5nliv26S0FgSXL5ixadNokHhz5oEuxU55xzJz46hmg27w5vmOIY/hhf/+ +yGr17M3TI4EqZbVo13+b8o3xf18w82gF9wU4LE8Cp2/1/c0K7CFTxWDMfCoRdrzjEgL Tg4d59kIEQqQee/bjZ5cHefynwd0nSDGq14Qk= MIME-Version: 1.0 Sender: sektie@gmail.com Received: by 10.211.161.18 with SMTP id n18mr2390206ebo.26.1252620339889; Thu, 10 Sep 2009 15:05:39 -0700 (PDT) In-Reply-To: References: <200909091631.01446.hselasky@c2i.net> <200909100911.10237.hselasky@c2i.net> Date: Thu, 10 Sep 2009 15:05:39 -0700 X-Google-Sender-Auth: f551b7d65438e64a Message-ID: From: Randi Harper To: James Butler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD CURRENT Mailing List , Hans Petter Selasky Subject: Re: Fwd: Can't boot 8.0-BETA4 from USB stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 22:07:43 -0000 On Thu, Sep 10, 2009 at 2:48 PM, James Butler wrote: > 2009/9/10 Hans Petter Selasky : > > On Thursday 10 September 2009 06:37:13 James Butler wrote: > >> Is there anything else worth trying? > > > > Another brand of memory sticks? > > I have only the three different brands that I tried (Toshiba and two > different no-names). Is there really nothing like an adjustable delay > at boot? Perhaps it's time to spend NZD$30 on a CF card and IDE > adapter, but that will be of limited use for troubleshooting or > installation. > > -James > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I've been asking around about an option to delay before mounting root as well. I don't know of anything off the top of my head, but it sounds to me like a bug (or at least a reasonable feature request). Send a PR? Have you only tried this on the one computer? It seems suspicious that all the cards are having this problem when I've only heard of two cases of USB flash-slowness causing problems so far. I'm curious to see if you have the same problem using that flash disk with a different computer. -- randi From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 22:10:55 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09D58106568B; Thu, 10 Sep 2009 22:10:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D81EB8FC12; Thu, 10 Sep 2009 22:10:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n8AMAsw6066548; Thu, 10 Sep 2009 18:10:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n8AMAspr066541; Thu, 10 Sep 2009 22:10:54 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Sep 2009 22:10:54 GMT Message-Id: <200909102210.n8AMAspr066541@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 22:10:55 -0000 TB --- 2009-09-10 20:40:12 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-10 20:40:12 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-09-10 20:40:12 - cleaning the object tree TB --- 2009-09-10 20:40:38 - cvsupping the source tree TB --- 2009-09-10 20:40:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-09-10 20:41:38 - building world TB --- 2009-09-10 20:41:38 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-10 20:41:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-10 20:41:38 - TARGET=ia64 TB --- 2009-09-10 20:41:38 - TARGET_ARCH=ia64 TB --- 2009-09-10 20:41:38 - TZ=UTC TB --- 2009-09-10 20:41:38 - __MAKE_CONF=/dev/null TB --- 2009-09-10 20:41:38 - cd /src TB --- 2009-09-10 20:41:38 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 10 20:41:39 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Sep 10 22:05:10 UTC 2009 TB --- 2009-09-10 22:05:10 - generating LINT kernel config TB --- 2009-09-10 22:05:10 - cd /src/sys/ia64/conf TB --- 2009-09-10 22:05:10 - /usr/bin/make -B LINT TB --- 2009-09-10 22:05:11 - building LINT kernel TB --- 2009-09-10 22:05:11 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-10 22:05:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-10 22:05:11 - TARGET=ia64 TB --- 2009-09-10 22:05:11 - TARGET_ARCH=ia64 TB --- 2009-09-10 22:05:11 - TZ=UTC TB --- 2009-09-10 22:05:11 - __MAKE_CONF=/dev/null TB --- 2009-09-10 22:05:11 - cd /src TB --- 2009-09-10 22:05:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 10 22:05:11 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/dpt/dpt_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/dpt/dpt_scsi.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_mq_start_locked': /src/sys/dev/e1000/if_em.c:1037: warning: suggest parentheses around assignment used as truth value /src/sys/dev/e1000/if_em.c:1067: warning: suggest parentheses around assignment used as truth value *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-10 22:10:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-10 22:10:54 - ERROR: failed to build lint kernel TB --- 2009-09-10 22:10:54 - 3921.92 user 489.71 system 5441.45 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 22:15:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DE4E106568B; Thu, 10 Sep 2009 22:15:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3FBE28FC08; Thu, 10 Sep 2009 22:15:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n8AMFopM093584; Thu, 10 Sep 2009 18:15:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n8AMFoqF093583; Thu, 10 Sep 2009 22:15:50 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Sep 2009 22:15:50 GMT Message-Id: <200909102215.n8AMFoqF093583@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 22:15:51 -0000 TB --- 2009-09-10 21:05:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-10 21:05:58 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-09-10 21:05:58 - cleaning the object tree TB --- 2009-09-10 21:06:07 - cvsupping the source tree TB --- 2009-09-10 21:06:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-09-10 21:06:40 - building world TB --- 2009-09-10 21:06:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-10 21:06:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-10 21:06:40 - TARGET=powerpc TB --- 2009-09-10 21:06:40 - TARGET_ARCH=powerpc TB --- 2009-09-10 21:06:40 - TZ=UTC TB --- 2009-09-10 21:06:40 - __MAKE_CONF=/dev/null TB --- 2009-09-10 21:06:40 - cd /src TB --- 2009-09-10 21:06:40 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 10 21:06:40 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Sep 10 22:12:16 UTC 2009 TB --- 2009-09-10 22:12:16 - generating LINT kernel config TB --- 2009-09-10 22:12:16 - cd /src/sys/powerpc/conf TB --- 2009-09-10 22:12:16 - /usr/bin/make -B LINT TB --- 2009-09-10 22:12:16 - building LINT kernel TB --- 2009-09-10 22:12:16 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-10 22:12:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-10 22:12:16 - TARGET=powerpc TB --- 2009-09-10 22:12:16 - TARGET_ARCH=powerpc TB --- 2009-09-10 22:12:16 - TZ=UTC TB --- 2009-09-10 22:12:16 - __MAKE_CONF=/dev/null TB --- 2009-09-10 22:12:16 - cd /src TB --- 2009-09-10 22:12:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 10 22:12:16 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/dpt/dpt_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/dpt/dpt_scsi.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_mq_start_locked': /src/sys/dev/e1000/if_em.c:1037: warning: suggest parentheses around assignment used as truth value /src/sys/dev/e1000/if_em.c:1067: warning: suggest parentheses around assignment used as truth value *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-10 22:15:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-10 22:15:50 - ERROR: failed to build lint kernel TB --- 2009-09-10 22:15:50 - 2926.18 user 446.68 system 4191.55 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 22:22:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D68F21065672 for ; Thu, 10 Sep 2009 22:22:36 +0000 (UTC) (envelope-from sweetnavelorange@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id 4259E8FC08 for ; Thu, 10 Sep 2009 22:22:36 +0000 (UTC) Received: by ewy4 with SMTP id 4so581513ewy.36 for ; Thu, 10 Sep 2009 15:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=I7YbQZaaf0GY55Adl+57XCK5SA7+VQZSwOk6PWxLU8o=; b=U4L81KXlbAun0zPqUuzmcGRYxdwijPg9EBvwBt8GM1ezivNaqVAfzwz3jsByTcugxH APIQOT8Q/5RcdTs6UlkAdS+ho52j59k/iN/NZTW+DBlPb6WugNaaakoo06KAeGZe4EXa 13/IifVSqs/ttrC0vMzoMx4SrXBYR1E933yl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kciWp3Ef/5m0uSaXRNFZ0XRAw1A6D9wroREd13HDLnrxMi27q9SBUE+WXyeh0RV5WA QZJZGkNuLhq/Sk4z29mkxRBaPWNZSncwyRY6KxLGnt/X/V1ZeRXQa/QEsHtB0MKIJpGW koPe506eUuv6Pd47DLo+vzywGE9fB+qds/CPY= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr203155wep.126.1252621354998; Thu, 10 Sep 2009 15:22:34 -0700 (PDT) In-Reply-To: References: <200909091631.01446.hselasky@c2i.net> <200909100911.10237.hselasky@c2i.net> Date: Fri, 11 Sep 2009 10:22:34 +1200 Message-ID: From: James Butler To: Randi Harper Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD CURRENT Mailing List , Hans Petter Selasky Subject: Re: Fwd: Can't boot 8.0-BETA4 from USB stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 22:22:37 -0000 2009/9/11 Randi Harper : > On Thu, Sep 10, 2009 at 2:48 PM, James Butler > wrote: >> >> 2009/9/10 Hans Petter Selasky : >> > On Thursday 10 September 2009 06:37:13 James Butler wrote: >> >> Is there anything else worth trying? >> > >> > Another brand of memory sticks? >> >> I have only the three different brands that I tried (Toshiba and two >> different no-names). Is there really nothing like an adjustable delay >> at boot? Perhaps it's time to spend NZD$30 on a CF card and IDE >> adapter, but that will be of limited use for troubleshooting or >> installation. >> >> -James >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > I've been asking around about an option to delay before mounting root as > well. I don't know of anything off the top of my head, but it sounds to me > like a bug (or at least a reasonable feature request). Send a PR? I probably will now, I just wanted to exhaust the existing options. It seems to me that a "wait for the configured root device to appear" timeout could be arbitrarily long (eg. 10+ secs) by default without adversely affecting the normal use case, but I don't claim to know how the boot process works. > Have you only tried this on the one computer? It seems suspicious that all > the cards are having this problem when I've only heard of two cases of USB > flash-slowness causing problems so far. I'm curious to see if you have the > same problem using that flash disk with a different computer. I think I used the same drive to test-install 8.0-BETA1 on my old Thinkpad X31, which seemed to work OK. This Asus motherboard is a but useless in other ways; still, 7.2 runs fine. -James From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 22:36:47 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 402AB106566B; Thu, 10 Sep 2009 22:36:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D91E08FC15; Thu, 10 Sep 2009 22:36:46 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n8AMakh7080234; Thu, 10 Sep 2009 18:36:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n8AMakN9080233; Thu, 10 Sep 2009 22:36:46 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Sep 2009 22:36:46 GMT Message-Id: <200909102236.n8AMakN9080233@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 22:36:47 -0000 TB --- 2009-09-10 21:33:39 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-10 21:33:39 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-09-10 21:33:39 - cleaning the object tree TB --- 2009-09-10 21:33:53 - cvsupping the source tree TB --- 2009-09-10 21:33:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-09-10 21:34:43 - building world TB --- 2009-09-10 21:34:43 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-10 21:34:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-10 21:34:43 - TARGET=sparc64 TB --- 2009-09-10 21:34:43 - TARGET_ARCH=sparc64 TB --- 2009-09-10 21:34:43 - TZ=UTC TB --- 2009-09-10 21:34:43 - __MAKE_CONF=/dev/null TB --- 2009-09-10 21:34:43 - cd /src TB --- 2009-09-10 21:34:43 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 10 21:34:44 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Sep 10 22:33:12 UTC 2009 TB --- 2009-09-10 22:33:12 - generating LINT kernel config TB --- 2009-09-10 22:33:12 - cd /src/sys/sparc64/conf TB --- 2009-09-10 22:33:12 - /usr/bin/make -B LINT TB --- 2009-09-10 22:33:12 - building LINT kernel TB --- 2009-09-10 22:33:12 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-10 22:33:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-10 22:33:12 - TARGET=sparc64 TB --- 2009-09-10 22:33:12 - TARGET_ARCH=sparc64 TB --- 2009-09-10 22:33:12 - TZ=UTC TB --- 2009-09-10 22:33:12 - __MAKE_CONF=/dev/null TB --- 2009-09-10 22:33:12 - cd /src TB --- 2009-09-10 22:33:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 10 22:33:12 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/dpt/dpt_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/dpt/dpt_scsi.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_mq_start_locked': /src/sys/dev/e1000/if_em.c:1037: warning: suggest parentheses around assignment used as truth value /src/sys/dev/e1000/if_em.c:1067: warning: suggest parentheses around assignment used as truth value *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-10 22:36:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-10 22:36:46 - ERROR: failed to build lint kernel TB --- 2009-09-10 22:36:46 - 2750.22 user 421.67 system 3786.79 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 22:49:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCDC51065672; Thu, 10 Sep 2009 22:49:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A66E88FC16; Thu, 10 Sep 2009 22:49:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n8AMnnPe013335; Thu, 10 Sep 2009 18:49:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n8AMnnTp013334; Thu, 10 Sep 2009 22:49:49 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 10 Sep 2009 22:49:49 GMT Message-Id: <200909102249.n8AMnnTp013334@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 22:49:49 -0000 TB --- 2009-09-10 21:51:06 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-10 21:51:06 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-09-10 21:51:06 - cleaning the object tree TB --- 2009-09-10 21:51:16 - cvsupping the source tree TB --- 2009-09-10 21:51:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-09-10 21:51:56 - building world TB --- 2009-09-10 21:51:56 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-10 21:51:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-10 21:51:56 - TARGET=sun4v TB --- 2009-09-10 21:51:56 - TARGET_ARCH=sparc64 TB --- 2009-09-10 21:51:56 - TZ=UTC TB --- 2009-09-10 21:51:56 - __MAKE_CONF=/dev/null TB --- 2009-09-10 21:51:56 - cd /src TB --- 2009-09-10 21:51:56 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 10 21:51:57 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Sep 10 22:46:18 UTC 2009 TB --- 2009-09-10 22:46:18 - generating LINT kernel config TB --- 2009-09-10 22:46:18 - cd /src/sys/sun4v/conf TB --- 2009-09-10 22:46:18 - /usr/bin/make -B LINT TB --- 2009-09-10 22:46:18 - building LINT kernel TB --- 2009-09-10 22:46:18 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-10 22:46:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-10 22:46:18 - TARGET=sun4v TB --- 2009-09-10 22:46:18 - TARGET_ARCH=sparc64 TB --- 2009-09-10 22:46:18 - TZ=UTC TB --- 2009-09-10 22:46:18 - __MAKE_CONF=/dev/null TB --- 2009-09-10 22:46:18 - cd /src TB --- 2009-09-10 22:46:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 10 22:46:18 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/dcons/dcons_os.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/de/if_de.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_mq_start_locked': /src/sys/dev/e1000/if_em.c:1037: warning: suggest parentheses around assignment used as truth value /src/sys/dev/e1000/if_em.c:1067: warning: suggest parentheses around assignment used as truth value *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-10 22:49:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-10 22:49:48 - ERROR: failed to build lint kernel TB --- 2009-09-10 22:49:48 - 2762.37 user 408.05 system 3522.10 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 22:52:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8684E106568B for ; Thu, 10 Sep 2009 22:52:18 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id EA93C8FC20 for ; Thu, 10 Sep 2009 22:52:17 +0000 (UTC) Received: by ewy4 with SMTP id 4so601010ewy.36 for ; Thu, 10 Sep 2009 15:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=JoV2yd/KEVs1ZCvlanix5ONNS6ompq0h/KExKEH9qq8=; b=xCVsQ+1jWTNtXV8wa5gaJ+3nR+jC7s2ml9DULEoL7jOS2T8EUKplDIqQqAEsFzeEAG 0hXj15jSgSWzsC2zJ79PqcMfttBZXctAG7WfI8u7jC13tV8ewupOyb2a7MqJB0GeA9B0 oHuDJyMfDT2PB2fdLUQsBZqDY7CAfw/cwKLF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=J9kn9JZUC8MkHlmLRgTQtiM3L5m8eIysWhYWFMbi6eNPKwoTxS/VDgrlcnKQbUCMs/ Xtae7qUG4dpYfaY4fJsvHEZvMQa3H7ibbc6SvCghCv3qEKpfjEdS3P5eKWVWPmwYluex Omyr2NOwTex61UknOfgQsimKUV76/SGK4WlBM= MIME-Version: 1.0 Sender: sektie@gmail.com Received: by 10.210.7.24 with SMTP id 24mr2353645ebg.48.1252623136799; Thu, 10 Sep 2009 15:52:16 -0700 (PDT) In-Reply-To: References: <200909091631.01446.hselasky@c2i.net> <200909100911.10237.hselasky@c2i.net> Date: Thu, 10 Sep 2009 15:52:16 -0700 X-Google-Sender-Auth: 61e86b9c7da43f53 Message-ID: From: Randi Harper To: James Butler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD CURRENT Mailing List , Hans Petter Selasky Subject: Re: Fwd: Can't boot 8.0-BETA4 from USB stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 22:52:18 -0000 On Thu, Sep 10, 2009 at 3:22 PM, James Butler wrote: > 2009/9/11 Randi Harper : > > On Thu, Sep 10, 2009 at 2:48 PM, James Butler < > sweetnavelorange@gmail.com> > > wrote: > >> > >> 2009/9/10 Hans Petter Selasky : > >> > On Thursday 10 September 2009 06:37:13 James Butler wrote: > >> >> Is there anything else worth trying? > >> > > >> > Another brand of memory sticks? > >> > >> I have only the three different brands that I tried (Toshiba and two > >> different no-names). Is there really nothing like an adjustable delay > >> at boot? Perhaps it's time to spend NZD$30 on a CF card and IDE > >> adapter, but that will be of limited use for troubleshooting or > >> installation. > >> > >> -James > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > > > I've been asking around about an option to delay before mounting root as > > well. I don't know of anything off the top of my head, but it sounds to > me > > like a bug (or at least a reasonable feature request). Send a PR? > > I probably will now, I just wanted to exhaust the existing options. It > seems to me that a "wait for the configured root device to appear" > timeout could be arbitrarily long (eg. 10+ secs) by default without > adversely affecting the normal use case, but I don't claim to know how > the boot process works. > > > Have you only tried this on the one computer? It seems suspicious that > all > > the cards are having this problem when I've only heard of two cases of > USB > > flash-slowness causing problems so far. I'm curious to see if you have > the > > same problem using that flash disk with a different computer. > > I think I used the same drive to test-install 8.0-BETA1 on my old > Thinkpad X31, which seemed to work OK. This Asus motherboard is a but > useless in other ways; still, 7.2 runs fine. > > -James > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > To avoid adversely affecting the normal use case, a tunable could specify the option of having the mount wait until the device appears, or possibly for how long to delay the mount. This really isn't my area of expertise, though, so take what I say with a grain of salt. Not sure if you've seen these, but this is a problem other people are reporting as well: Relevant but not enlightening: http://lists.freebsd.org/pipermail/freebsd-current/2009-May/007457.html Slightly more helpful: http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010562.html Not all that relevant, but interesting anyways: http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009912.html -- randi From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 23:05:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF365106566B for ; Thu, 10 Sep 2009 23:05:55 +0000 (UTC) (envelope-from duncan.young@pobox.com) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id A4BC78FC15 for ; Thu, 10 Sep 2009 23:05:55 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 0A4986909D for ; Thu, 10 Sep 2009 18:47:20 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 10 Sep 2009 18:47:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:content-type:content-transfer-encoding; s=smtpout; bh=DnjaE39KKggHiyJCkQrUSMRSkN0=; b=Ahg9xOmAoV6Qr1gr/RXnj9ezfAUSzd9eO37RQl82/qShbhvZ0cTmd71SoERFDTCrw+8rfKUj1WIN3XbzqRybs4jKsgzCAH+93m6poXjZNP9fAUzOsgdDX5rFVEZQlh+3y1Z4sDNTPLeffcgY1yjfkPONviQa3jjDFNR3DoWhFys= X-Sasl-enc: BpCXCYYK4f/ROyVkA8bhHLXeXVEj4fYf0WK54bPhu8uO 1252622838 Received: from [0.0.0.0] (c122-108-168-198.rochd4.qld.optusnet.com.au [122.108.168.198]) by mail.messagingengine.com (Postfix) with ESMTPSA id 46F62225C6 for ; Thu, 10 Sep 2009 18:47:18 -0400 (EDT) Message-ID: <4AA981F4.3090607@pobox.com> Date: Fri, 11 Sep 2009 08:47:16 +1000 From: Duncan Young User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: zfs woes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 23:05:56 -0000 Hi all, Again its happened (my need to restore my main zpool from backups). I have been having regular crashes (only recently been getting crash dumps though), and in the the process of upgrading to 7.1-STABLE, upgrading zpools (now 13) and zfs (now 3), I now have a problem with my main data zpool. I was having these problems before the upgrade. After zpool status saying that I had corrupted files (actually a zfs filesystem), I tried destroying it (the zfs filesystem), in the hope that this may make my problems go away). The machine hung. zpool scrub works, reporting 16 errors. zpool status -v crashes. starting multiuser hangs (probably on mounting the dud fs). I can start single user, and I am currently additional backups of the filesytems I can access (most off the corrupted zpool). Any accessing the corrupted zfs filesystem crashes the machine. Now I think it's fair enough that the filesystem is corrupted (I still see a need for some type of fsck), but I don't see that the machine should crash because of it. Any sugestions? Script started on Fri Sep 11 17:22:23 2009 # uname -a FreeBSD 7.2-STABLE FreeBSD 7.2-STABLE #8: Fri Sep 11 04:14:39 EST 2009 root@:/usr/obj/usr/src/sys/TRIPLE0 amd64 # cd /usr/src/sys/TRIPLE0 # kgdb ./kernel.debug /var/crash/vmcore/.25 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-STABLE #8: Fri Sep 11 04:14:39 EST 2009 root@:/usr/obj/usr/src/sys/TRIPLE0 module_register: module g_label already exists! Module g_label failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Phenom(tm) II X4 810 Processor (2608.81-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant Cores per package: 4 usable memory = 8441266176 (8050 MB) avail memory = 8131702784 (7754 MB) ACPI APIC Table: <072709 APIC1045> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ACPI Warning (tbfadt-0505): Optional field "Pm2ControlBlock" has zero address or length: 0 0/1 [20070320] ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <072709 XSDT1045> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of ffb80000, 80000 (3) failed acpi0: reservation of fec10000, 20 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dff00000 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc0ff mem 0xf0000000-0xf7ffffff,0xfbce0000-0xfbceffff,0xfbb00000-0xfbbfffff irq 18 at device 5.0 on pci1 hdac0: mem 0xfbcfc000-0xfbcfffff irq 19 at device 5.1 on pci1 hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] pcib2: irq 16 at device 4.0 on pci0 pci2: on pcib2 hptrr0: port 0xd800-0xd8ff mem 0xfbe00000-0xfbefffff irq 16 at device 0.0 on pci2 hptrr: adapter at PCI 2:0:0, IRQ 16 pcib3: irq 17 at device 5.0 on pci0 pci3: on pcib3 em0: port 0xec00-0xec1f mem 0xfbfe0000-0xfbffffff,0xfbf00000-0xfbf7ffff,0xfbfdc000-0xfbfdffff irq 17 at device 0.0 on pci3 em0: Using MSIX interrupts em0: [ITHREAD] em0: [ITHREAD] em0: [ITHREAD] em0: Ethernet address: 00:1b:21:3d:eb:e7 atapci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfbaffc00-0xfbafffff irq 22 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 6 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] ohci0: mem 0xfbafd000-0xfbafdfff irq 16 at device 18.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfbafe000-0xfbafefff irq 16 at device 18.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xfbaff800-0xfbaff8ff irq 17 at device 18.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 3 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 6 ports with 6 removable, self powered ohci2: mem 0xfbafb000-0xfbafbfff irq 18 at device 19.0 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: on ohci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 3 ports with 3 removable, self powered ohci3: mem 0xfbafc000-0xfbafcfff irq 18 at device 19.1 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: on ohci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 3 ports with 3 removable, self powered ehci1: mem 0xfbaff400-0xfbaff4ff irq 19 at device 19.2 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 3 ports each: usb3 usb4 usb5: on ehci1 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 6 ports with 6 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] hdac1: mem 0xfbaf4000-0xfbaf7fff irq 16 at device 20.2 on pci0 hdac1: HDA Driver Revision: 20090624_0136 hdac1: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib4: at device 20.4 on pci0 pci4: on pcib4 ohci4: mem 0xfbafa000-0xfbafafff irq 18 at device 20.5 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb6: OHCI version 1.0, legacy support usb6: on ohci4 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model MouseMan+, device ID 0 acpi_aiboost0: on acpi0 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] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cryptosoft0: on motherboard orm0: at iomem 0xd7800-0xd87ff 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: cannot reserve I/O port range sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ulpt0: on uhub0 ulpt0: using bi-directional mode WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x12c offMax=0x219 hptrr: start channel [0,0] hptrr: start channel [0,1] hptrr: start channel [0,2] hptrr: start channel [0,3] hptrr: [0 0] Start channel soft reset. hptrr: [0 2] Start channel soft reset. hptrr: [0 3] Start channel soft reset. hptrr: channel [0,0] started successfully hptrr: channel [0,2] started successfully hptrr: channel [0,3] started successfully hptrr: [0 1] Failed to perform channel hard reset. hptrr0: [GIANT-LOCKED] hptrr0: [ITHREAD] The GEOM class LABEL is already loaded. ZFS filesystem version 13 ZFS storage pool version 13 da0 at hptrr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da1 at hptrr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-0 device da2 at hptrr0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-0 device acd0: DVDR at ata0-master PIO4 ad4: 476940MB at ata2-master SATA300 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM Status: SCSI Status Error (probe0:ata0:0:0:0): SCSI Status: Check Condition (probe0:ata0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0 (probe0:ata0:0:0:0): Medium not present (probe0:ata0:0:0:0): Unretryable error cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present ad6: 953869MB at ata3-master SATA300 ad10: 953869MB at ata5-master SATA300 ad12: 476940MB at ata6-master SATA300 ad14: 953869MB at ata7-master SATA300 hdac0: HDA Codec #0: ATI RS690/780 HDMI pcm0: at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: VIA VT1708S_0 pcm1: at cad 0 nid 1 on hdac1 pcm2: at cad 0 nid 1 on hdac1 pcm3: at cad 0 nid 1 on hdac1 SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! Trying to mount root from zfs:rootzfs <118>Loading configuration files. <118>kernel dumps on /dev/ad4s1b <118>Entropy harvesting: <118> interrupts <118> ethernet <118> point_to_point <118> kickstart <118>. GEOM_ELI: Device label/swapB.eli created. GEOM_ELI: Encryption: AES-CBC 256 GEOM_ELI: Crypto: software <118>swapon: adding /dev/label/swapB.eli as swap device <118>/etc/rc: WARNING: Use of the early.sh script is deprecated <118>/etc/rc: WARNING: Please use a new-style rc.d script instead <118>/etc/rc: WARNING: See rc(8) for more information <118>gmirror: <118>No such device: swap_AB. <118> <118>Starting file system checks: <118>/dev/label/bstrapA: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/label/bstrapA: clean, 303581 free (261 frags, 37915 blocks, 0.1% fragmentation) <118>/dev/label/bstrapB: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/label/bstrapB: clean, 303502 free (318 frags, 37898 blocks, 0.1% fragmentation) <118>Setting hostuuid: e039c626-5f54-da11-8e5a-e6b6a8a23cf0. <118>Setting hostid: 0xd449202f. <118>Mounting local file systems: <118>. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x50 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff80ad7a5e stack pointer = 0x10:0xffffff80a5b2f620 frame pointer = 0x10:0xffffff80a5b2f6a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 314 (txg_thread_enter) trap number = 12 panic: page fault cpuid = 1 Uptime: 2m11s Physical memory: 8050 MB Dumping 1553 MB: 1538 1522 1506 1490 1474 1458 1442 1426 1410 1394 1378 1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154 1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898 882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610 594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /bootdirA/boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /bootdirA/boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /bootdirA/boot/kernel/geom_eli.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_eli.ko Reading symbols from /boot/kernel/crypto.ko...Reading symbols from /bootdirA/boot/kernel/crypto.ko.symbols...done. done. Loaded symbols for /boot/kernel/crypto.ko Reading symbols from /boot/kernel/zlib.ko...Reading symbols from /bootdirA/boot/kernel/zlib.ko.symbols...done. done. Loaded symbols for /boot/kernel/zlib.ko Reading symbols from /boot/kernel/geom_label.ko...Reading symbols from /bootdirA/boot/kernel/geom_label.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_label.ko Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /bootdirA/boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /bootdirA/boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /bootdirA/boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/cd9660_iconv.ko...Reading symbols from /bootdirA/boot/kernel/cd9660_iconv.ko.symbols...done. done. Loaded symbols for /boot/kernel/cd9660_iconv.ko Reading symbols from /boot/kernel/libiconv.ko...Reading symbols from /bootdirA/boot/kernel/libiconv.ko.symbols...done. done. Loaded symbols for /boot/kernel/libiconv.ko Reading symbols from /boot/kernel/aio.ko...Reading symbols from /bootdirA/boot/kernel/aio.ko.symbols...done. done. Loaded symbols for /boot/kernel/aio.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/sem.ko...Reading symbols from /bootdirA/boot/kernel/sem.ko.symbols...done. done. Loaded symbols for /boot/kernel/sem.ko #0 doadump () at pcpu.h:195 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0x0000000000000004 in ?? () #2 0xffffffff803aab90 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0xffffffff803aafb2 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0xffffffff80651d03 in trap_fatal (frame=0xffffff0009572390, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:770 #5 0xffffffff806520d5 in trap_pfault (frame=0xffffff80a5b2f570, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:686 #6 0xffffffff80652a63 in trap (frame=0xffffff80a5b2f570) at /usr/src/sys/amd64/amd64/trap.c:457 #7 0xffffffff8063cb4e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:218 #8 0xffffffff80ad7a5e in find_block (th=0xffffff8006930000, zseg=0xffffff000dafc580, dnp=0xffffff8006d35600, depth=Variable "depth" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c:400 #9 0xffffffff80ad81a3 in traverse_more (th=0xffffff8006930000) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c:672 #10 0xffffffff80ad8368 in traverse_dsl_dataset (ds=0x23, txg_start=1, advance=Variable "advance" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/d---Type to continue, or q to quit--- mu_traverse.c:731 #11 0xffffffff80ae41c9 in dsl_dataset_destroy_sync () from /boot/kernel/zfs.ko #12 0xffffffff80ae6d2a in dsl_sync_task_group_sync (dstg=0xffffff000d256600, tx=0xffffff000d1fca80) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_synctask.c:186 #13 0xffffffff80ae6873 in dsl_pool_sync (dp=0xffffff000d521000, txg=3430336) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:316 #14 0xffffffff80af59c3 in spa_sync (spa=0xffffff0006d08000, txg=3430336) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3988 #15 0xffffffff80afd772 in txg_sync_thread (arg=Variable "arg" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:352 #16 0xffffffff80385452 in fork_exit ( callout=0xffffffff80afd490 , arg=0xffffff000d521000, frame=0xffffff80a5b2fc80) at /usr/src/sys/kern/kern_fork.c:811 #17 0xffffffff8063cf2e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:554 #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000001 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000dde000 in ?? () #43 0xffffffff80950d40 in tdq_cpu () #44 0xffffffff8095c940 in tdq_groups () #45 0xffffffff8095c8c0 in tdq_cpu () #46 0xffffff0009572390 in ?? () #47 0x0000000000000000 in ?? () #48 0xffffff80a5b2f1e8 in ?? () #49 0xffffff0009572390 in ?? () #50 0xffffffff803ce154 in sched_switch (td=0xffffffff80afd490, newtd=0x0, flags=0) at /usr/src/sys/kern/sched_ule.c:1938 #51 0x0000000000000000 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000000 in ?? () #54 0x0000000000000000 in ?? () #55 0x0000000000000000 in ?? () #56 0x0000000000000000 in ?? () #57 0x0000000000000000 in ?? () #58 0x0000000000000000 in ?? () #59 0x0000000000000000 in ?? () #60 0x0000000000000000 in ?? () #61 0x0000000000000000 in ?? () #62 0x0000000000000000 in ?? () #63 0x0000000000000000 in ?? () #64 0x0000000000000000 in ?? () #65 0x0000000000000000 in ?? () #66 0x0000000000000000 in ?? () #67 0x0000000000000000 in ?? () #68 0x0000000000000000 in ?? () #69 0x0000000000000000 in ?? () #70 0x0000000000000000 in ?? () #71 0x0000000000000000 in ?? () #72 0x0000000000000000 in ?? () #73 0x0000000000000000 in ?? () #74 0x0000000000000000 in ?? () #75 0x0000000000000000 in ?? () #76 0x0000000000000000 in ?? () #77 0x0000000000000000 in ?? () #78 0x0000000000000000 in ?? () #79 0x0000000000000000 in ?? () #80 0x0000000000000000 in ?? () #81 0x0000000000000000 in ?? () #82 0x0000000000000000 in ?? () #83 0x0000000000000000 in ?? () #84 0x0000000000000000 in ?? () #85 0x0000000000000000 in ?? () #86 0x0000000000000000 in ?? () #87 0x0000000000000000 in ?? () #88 0x0000000000000000 in ?? () #89 0x0000000000000000 in ?? () #90 0x0000000000000000 in ?? () #91 0x0000000000000000 in ?? () #92 0x0000000000000000 in ?? () #93 0x0000000000000000 in ?? () #94 0x0000000000000000 in ?? () #95 0x0000000000000000 in ?? () #96 0x0000000000000000 in ?? () #97 0x0000000000000000 in ?? () #98 0x0000000000000000 in ?? () #99 0x0000000000000000 in ?? () #100 0x0000000000000000 in ?? () #101 0x0000000000000000 in ?? () #102 0x0000000000000000 in ?? () #103 0x0000000000000000 in ?? () #104 0x0000000000000000 in ?? () #105 0x0000000000000000 in ?? () #106 0x0000000000000000 in ?? () #107 0x0000000000000000 in ?? () #108 0x0000000000000000 in ?? () #109 0x0000000000000000 in ?? () #110 0x0000000000000000 in ?? () #111 0x0000000000000000 in ?? () #112 0x0000000000000000 in ?? () #113 0x0000000000000000 in ?? () #114 0x0000000000000000 in ?? () #115 0x0000000000000000 in ?? () #116 0x0000000000000000 in ?? () #117 0x0000000000000000 in ?? () #118 0x0000000000000000 in ?? () Cannot access memory at address 0xffffff80a5b30000 (kgdb) q # ^D Script done on Fri Sep 11 17:26:02 2009 From owner-freebsd-current@FreeBSD.ORG Thu Sep 10 23:46:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69C1E1065672 for ; Thu, 10 Sep 2009 23:46:31 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1DFE78FC0C for ; Thu, 10 Sep 2009 23:46:30 +0000 (UTC) Received: (qmail 15288 invoked from network); 10 Sep 2009 23:46:29 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 10 Sep 2009 23:46:29 -0000 Message-ID: <4AA98FCA.9090506@acm.poly.edu> Date: Thu, 10 Sep 2009 19:46:18 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.23 (X11/20090910) MIME-Version: 1.0 To: Duncan Young References: <4AA981F4.3090607@pobox.com> In-Reply-To: <4AA981F4.3090607@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: zfs woes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 23:46:31 -0000 Duncan Young wrote: > Hi all, > > Again its happened (my need to restore my main zpool from backups). > > I have been having regular crashes (only recently been getting crash > dumps though), and in the the process > of upgrading to 7.1-STABLE, upgrading zpools (now 13) and zfs (now 3), I > now have a problem with > my main data zpool. > > I was having these problems before the upgrade. > > After zpool status saying that I had corrupted files (actually a zfs > filesystem), I tried destroying it (the zfs filesystem), in the hope > that this > may make my problems go away). The machine hung. > > zpool scrub works, reporting 16 errors. > zpool status -v crashes. > starting multiuser hangs (probably on mounting the dud fs). > I can start single user, and I am currently additional backups of the > filesytems I can access (most off the corrupted zpool). > Any accessing the corrupted zfs filesystem crashes the machine. > > Now I think it's fair enough that the filesystem is corrupted (I still > see a need for some type of fsck), but I don't see that the > machine should crash because of it. Any sugestions? > > Script started on Fri Sep 11 17:22:23 2009 > # uname -a > FreeBSD 7.2-STABLE FreeBSD 7.2-STABLE #8: Fri Sep 11 04:14:39 EST > 2009 root@:/usr/obj/usr/src/sys/TRIPLE0 amd64 > # cd /usr/src/sys/TRIPLE0 > # kgdb ./kernel.debug /var/crash/vmcore/.25 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.2-STABLE #8: Fri Sep 11 04:14:39 EST 2009 > root@:/usr/obj/usr/src/sys/TRIPLE0 > module_register: module g_label already exists! > Module g_label failed to register: 17 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Phenom(tm) II X4 810 Processor (2608.81-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x100f42 Stepping = 2 > > Features=0x178bfbff > > Features2=0x802009 > AMD > Features=0xee500800 > > AMD > Features2=0x37ff > > TSC: P-state invariant > Cores per package: 4 > usable memory = 8441266176 (8050 MB) > avail memory = 8131702784 (7754 MB) > ACPI APIC Table: <072709 APIC1045> > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > This module (opensolaris) contains code covered by the > Common Development and Distribution License (CDDL) > see http://opensolaris.org/os/licensing/opensolaris_license/ > ACPI Warning (tbfadt-0505): Optional field "Pm2ControlBlock" has zero > address or length: 0 0/1 [20070320] > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: <072709 XSDT1045> on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of fee00000, 1000 (3) failed > acpi0: reservation of ffb80000, 80000 (3) failed > acpi0: reservation of fec10000, 20 (3) failed > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, dff00000 (3) failed > ACPI HPET table warning: Sequence is non-zero (2) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0xc000-0xc0ff mem > 0xf0000000-0xf7ffffff,0xfbce0000-0xfbceffff,0xfbb00000-0xfbbfffff irq 18 > at device 5.0 on pci1 > hdac0: mem > 0xfbcfc000-0xfbcfffff irq 19 at device 5.1 on pci1 > hdac0: HDA Driver Revision: 20090624_0136 > hdac0: [ITHREAD] > pcib2: irq 16 at device 4.0 on pci0 > pci2: on pcib2 > hptrr0: port 0xd800-0xd8ff mem 0xfbe00000-0xfbefffff irq 16 at > device 0.0 on pci2 > hptrr: adapter at PCI 2:0:0, IRQ 16 > pcib3: irq 17 at device 5.0 on pci0 > pci3: on pcib3 > em0: port 0xec00-0xec1f mem > 0xfbfe0000-0xfbffffff,0xfbf00000-0xfbf7ffff,0xfbfdc000-0xfbfdffff irq 17 > at device 0.0 on pci3 > em0: Using MSIX interrupts > em0: [ITHREAD] > em0: [ITHREAD] > em0: [ITHREAD] > em0: Ethernet address: 00:1b:21:3d:eb:e7 > atapci0: port > 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f > mem 0xfbaffc00-0xfbafffff irq 22 at device 17.0 on pci0 > atapci0: [ITHREAD] > atapci0: AHCI Version 01.10 controller with 6 ports detected > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > ata4: on atapci0 > ata4: [ITHREAD] > ata5: on atapci0 > ata5: [ITHREAD] > ata6: on atapci0 > ata6: [ITHREAD] > ata7: on atapci0 > ata7: [ITHREAD] > ohci0: mem 0xfbafd000-0xfbafdfff irq 16 > at device 18.0 on pci0 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 3 ports with 3 removable, self powered > ohci1: mem 0xfbafe000-0xfbafefff irq 16 > at device 18.1 on pci0 > ohci1: [GIANT-LOCKED] > ohci1: [ITHREAD] > usb1: OHCI version 1.0, legacy support > usb1: on ohci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 3 ports with 3 removable, self powered > ehci0: mem 0xfbaff800-0xfbaff8ff irq > 17 at device 18.2 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb2: EHCI version 1.0 > usb2: companion controllers, 3 ports each: usb0 usb1 > usb2: on ehci0 > usb2: USB revision 2.0 > uhub2: on usb2 > uhub2: 6 ports with 6 removable, self powered > ohci2: mem 0xfbafb000-0xfbafbfff irq 18 > at device 19.0 on pci0 > ohci2: [GIANT-LOCKED] > ohci2: [ITHREAD] > usb3: OHCI version 1.0, legacy support > usb3: on ohci2 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 3 ports with 3 removable, self powered > ohci3: mem 0xfbafc000-0xfbafcfff irq 18 > at device 19.1 on pci0 > ohci3: [GIANT-LOCKED] > ohci3: [ITHREAD] > usb4: OHCI version 1.0, legacy support > usb4: on ohci3 > usb4: USB revision 1.0 > uhub4: on usb4 > uhub4: 3 ports with 3 removable, self powered > ehci1: mem 0xfbaff400-0xfbaff4ff irq > 19 at device 19.2 on pci0 > ehci1: [GIANT-LOCKED] > ehci1: [ITHREAD] > usb5: EHCI version 1.0 > usb5: companion controllers, 3 ports each: usb3 usb4 > usb5: on ehci1 > usb5: USB revision 2.0 > uhub5: on usb5 > uhub5: 6 ports with 6 removable, self powered > pci0: at device 20.0 (no driver attached) > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 > ata0: on atapci1 > ata0: [ITHREAD] > hdac1: mem > 0xfbaf4000-0xfbaf7fff irq 16 at device 20.2 on pci0 > hdac1: HDA Driver Revision: 20090624_0136 > hdac1: [ITHREAD] > isab0: at device 20.3 on pci0 > isa0: on isab0 > pcib4: at device 20.4 on pci0 > pci4: on pcib4 > ohci4: mem 0xfbafa000-0xfbafafff irq 18 > at device 20.5 on pci0 > ohci4: [GIANT-LOCKED] > ohci4: [ITHREAD] > usb6: OHCI version 1.0, legacy support > usb6: on ohci4 > usb6: USB revision 1.0 > uhub6: on usb6 > uhub6: 2 ports with 2 removable, self powered > acpi_button0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model MouseMan+, device ID 0 > acpi_aiboost0: on acpi0 > 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] > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 > on acpi0 > fdc0: [FILTER] > cpu0: on acpi0 > acpi_throttle0: on cpu0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > cryptosoft0: on motherboard > orm0: at iomem 0xd7800-0xd87ff 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: cannot reserve I/O port range > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > ulpt0: Series, class 0/0, rev 1.10/1.00, addr 2> on uhub0 > ulpt0: using bi-directional mode > WARNING: ZFS is considered to be an experimental feature in FreeBSD. > Timecounters tick every 1.000 msec > vboxdrv: fAsync=0 offMin=0x12c offMax=0x219 > hptrr: start channel [0,0] > hptrr: start channel [0,1] > hptrr: start channel [0,2] > hptrr: start channel [0,3] > hptrr: [0 0] Start channel soft reset. > hptrr: [0 2] Start channel soft reset. > hptrr: [0 3] Start channel soft reset. > hptrr: channel [0,0] started successfully > hptrr: channel [0,2] started successfully > hptrr: channel [0,3] started successfully > hptrr: [0 1] Failed to perform channel hard reset. > hptrr0: [GIANT-LOCKED] > hptrr0: [ITHREAD] > The GEOM class LABEL is already loaded. > ZFS filesystem version 13 > ZFS storage pool version 13 > da0 at hptrr0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da1 at hptrr0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-0 device > da2 at hptrr0 bus 0 target 2 lun 0 > da2: Fixed Direct Access SCSI-0 device > acd0: DVDR at ata0-master PIO4 > ad4: 476940MB at ata2-master SATA300 > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 > 0x01 > (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:ata0:0:0:0): CAM Status: SCSI Status Error > (probe0:ata0:0:0:0): SCSI Status: Check Condition > (probe0:ata0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0 > (probe0:ata0:0:0:0): Medium not present > (probe0:ata0:0:0:0): Unretryable error > cd0 at ata0 bus 0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 16.000MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present > ad6: 953869MB at ata3-master SATA300 > ad10: 953869MB at ata5-master SATA300 > ad12: 476940MB at ata6-master SATA300 > ad14: 953869MB at ata7-master SATA300 > hdac0: HDA Codec #0: ATI RS690/780 HDMI > pcm0: at cad 0 nid 1 on hdac0 > hdac1: HDA Codec #0: VIA VT1708S_0 > pcm1: at cad 0 nid 1 on hdac1 > pcm2: at cad 0 nid 1 on hdac1 > pcm3: at cad 0 nid 1 on hdac1 > SMP: AP CPU #2 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #1 Launched! > Trying to mount root from zfs:rootzfs > <118>Loading configuration files. > <118>kernel dumps on /dev/ad4s1b > <118>Entropy harvesting: > <118> interrupts > <118> ethernet > <118> point_to_point > <118> kickstart > <118>. > GEOM_ELI: Device label/swapB.eli created. > GEOM_ELI: Encryption: AES-CBC 256 > GEOM_ELI: Crypto: software > <118>swapon: adding /dev/label/swapB.eli as swap device > <118>/etc/rc: WARNING: Use of the early.sh script is deprecated > <118>/etc/rc: WARNING: Please use a new-style rc.d script instead > <118>/etc/rc: WARNING: See rc(8) for more information > <118>gmirror: > <118>No such device: swap_AB. > <118> > <118>Starting file system checks: > <118>/dev/label/bstrapA: FILE SYSTEM CLEAN; SKIPPING CHECKS > <118>/dev/label/bstrapA: clean, 303581 free (261 frags, 37915 blocks, > 0.1% fragmentation) > <118>/dev/label/bstrapB: FILE SYSTEM CLEAN; SKIPPING CHECKS > <118>/dev/label/bstrapB: clean, 303502 free (318 frags, 37898 blocks, > 0.1% fragmentation) > <118>Setting hostuuid: e039c626-5f54-da11-8e5a-e6b6a8a23cf0. > <118>Setting hostid: 0xd449202f. > <118>Mounting local file systems: > <118>. > > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x50 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff80ad7a5e > stack pointer = 0x10:0xffffff80a5b2f620 > frame pointer = 0x10:0xffffff80a5b2f6a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 314 (txg_thread_enter) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 2m11s > Physical memory: 8050 MB > Dumping 1553 MB: 1538 1522 1506 1490 1474 1458 1442 1426 1410 1394 1378 > 1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154 > 1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898 > 882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610 > 594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322 > 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 > > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from > /bootdirA/boot/kernel/zfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/zfs.ko > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from > /bootdirA/boot/kernel/opensolaris.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/opensolaris.ko > Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from > /bootdirA/boot/kernel/geom_eli.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/geom_eli.ko > Reading symbols from /boot/kernel/crypto.ko...Reading symbols from > /bootdirA/boot/kernel/crypto.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/crypto.ko > Reading symbols from /boot/kernel/zlib.ko...Reading symbols from > /bootdirA/boot/kernel/zlib.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/zlib.ko > Reading symbols from /boot/kernel/geom_label.ko...Reading symbols from > /bootdirA/boot/kernel/geom_label.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/geom_label.ko > Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from > /bootdirA/boot/kernel/geom_mirror.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/geom_mirror.ko > Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from > /bootdirA/boot/kernel/snd_hda.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/snd_hda.ko > Reading symbols from /boot/kernel/sound.ko...Reading symbols from > /bootdirA/boot/kernel/sound.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/sound.ko > Reading symbols from /boot/kernel/cd9660_iconv.ko...Reading symbols from > /bootdirA/boot/kernel/cd9660_iconv.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/cd9660_iconv.ko > Reading symbols from /boot/kernel/libiconv.ko...Reading symbols from > /bootdirA/boot/kernel/libiconv.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/libiconv.ko > Reading symbols from /boot/kernel/aio.ko...Reading symbols from > /bootdirA/boot/kernel/aio.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/aio.ko > Reading symbols from /boot/modules/vboxdrv.ko...done. > Loaded symbols for /boot/modules/vboxdrv.ko > Reading symbols from /boot/kernel/sem.ko...Reading symbols from > /bootdirA/boot/kernel/sem.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/sem.ko > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > (kgdb) backtrace > #0 doadump () at pcpu.h:195 > #1 0x0000000000000004 in ?? () > #2 0xffffffff803aab90 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:418 > #3 0xffffffff803aafb2 in panic (fmt=0x104
) > at /usr/src/sys/kern/kern_shutdown.c:574 > #4 0xffffffff80651d03 in trap_fatal (frame=0xffffff0009572390, > eva=Variable "eva" is not available. > ) > at /usr/src/sys/amd64/amd64/trap.c:770 > #5 0xffffffff806520d5 in trap_pfault (frame=0xffffff80a5b2f570, > usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:686 > #6 0xffffffff80652a63 in trap (frame=0xffffff80a5b2f570) > at /usr/src/sys/amd64/amd64/trap.c:457 > #7 0xffffffff8063cb4e in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:218 > #8 0xffffffff80ad7a5e in find_block (th=0xffffff8006930000, > zseg=0xffffff000dafc580, dnp=0xffffff8006d35600, depth=Variable > "depth" is not available. > ) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c:400 > > #9 0xffffffff80ad81a3 in traverse_more (th=0xffffff8006930000) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c:672 > > #10 0xffffffff80ad8368 in traverse_dsl_dataset (ds=0x23, txg_start=1, > advance=Variable "advance" is not available. > > ) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/d---Type > > to continue, or q to quit--- > mu_traverse.c:731 > #11 0xffffffff80ae41c9 in dsl_dataset_destroy_sync () from > /boot/kernel/zfs.ko > #12 0xffffffff80ae6d2a in dsl_sync_task_group_sync > (dstg=0xffffff000d256600, > tx=0xffffff000d1fca80) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_synctask.c:186 > > #13 0xffffffff80ae6873 in dsl_pool_sync (dp=0xffffff000d521000, > txg=3430336) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:316 > > #14 0xffffffff80af59c3 in spa_sync (spa=0xffffff0006d08000, txg=3430336) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3988 > > #15 0xffffffff80afd772 in txg_sync_thread (arg=Variable "arg" is not > available. > ) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:352 > > #16 0xffffffff80385452 in fork_exit ( > callout=0xffffffff80afd490 , arg=0xffffff000d521000, > frame=0xffffff80a5b2fc80) at /usr/src/sys/kern/kern_fork.c:811 > #17 0xffffffff8063cf2e in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:554 > #18 0x0000000000000000 in ?? () > #19 0x0000000000000000 in ?? () > #20 0x0000000000000001 in ?? () > #21 0x0000000000000000 in ?? () > #22 0x0000000000000000 in ?? () > #23 0x0000000000000000 in ?? () > #24 0x0000000000000000 in ?? () > #25 0x0000000000000000 in ?? () > #26 0x0000000000000000 in ?? () > #27 0x0000000000000000 in ?? () > #28 0x0000000000000000 in ?? () > #29 0x0000000000000000 in ?? () > #30 0x0000000000000000 in ?? () > #31 0x0000000000000000 in ?? () > #32 0x0000000000000000 in ?? () > #33 0x0000000000000000 in ?? () > #34 0x0000000000000000 in ?? () > #35 0x0000000000000000 in ?? () > #36 0x0000000000000000 in ?? () > #37 0x0000000000000000 in ?? () > #38 0x0000000000000000 in ?? () > #39 0x0000000000000000 in ?? () > #40 0x0000000000000000 in ?? () > #41 0x0000000000000000 in ?? () > #42 0x0000000000dde000 in ?? () > #43 0xffffffff80950d40 in tdq_cpu () > #44 0xffffffff8095c940 in tdq_groups () > #45 0xffffffff8095c8c0 in tdq_cpu () > #46 0xffffff0009572390 in ?? () > #47 0x0000000000000000 in ?? () > #48 0xffffff80a5b2f1e8 in ?? () > #49 0xffffff0009572390 in ?? () > #50 0xffffffff803ce154 in sched_switch (td=0xffffffff80afd490, newtd=0x0, > flags=0) at /usr/src/sys/kern/sched_ule.c:1938 > #51 0x0000000000000000 in ?? () > #52 0x0000000000000000 in ?? () > #53 0x0000000000000000 in ?? () > #54 0x0000000000000000 in ?? () > #55 0x0000000000000000 in ?? () > #56 0x0000000000000000 in ?? () > #57 0x0000000000000000 in ?? () > #58 0x0000000000000000 in ?? () > #59 0x0000000000000000 in ?? () > #60 0x0000000000000000 in ?? () > #61 0x0000000000000000 in ?? () > #62 0x0000000000000000 in ?? () > #63 0x0000000000000000 in ?? () > #64 0x0000000000000000 in ?? () > #65 0x0000000000000000 in ?? () > #66 0x0000000000000000 in ?? () > #67 0x0000000000000000 in ?? () > #68 0x0000000000000000 in ?? () > #69 0x0000000000000000 in ?? () > #70 0x0000000000000000 in ?? () > #71 0x0000000000000000 in ?? () > #72 0x0000000000000000 in ?? () > #73 0x0000000000000000 in ?? () > #74 0x0000000000000000 in ?? () > #75 0x0000000000000000 in ?? () > #76 0x0000000000000000 in ?? () > #77 0x0000000000000000 in ?? () > #78 0x0000000000000000 in ?? () > #79 0x0000000000000000 in ?? () > #80 0x0000000000000000 in ?? () > #81 0x0000000000000000 in ?? () > #82 0x0000000000000000 in ?? () > #83 0x0000000000000000 in ?? () > #84 0x0000000000000000 in ?? () > #85 0x0000000000000000 in ?? () > #86 0x0000000000000000 in ?? () > #87 0x0000000000000000 in ?? () > #88 0x0000000000000000 in ?? () > #89 0x0000000000000000 in ?? () > #90 0x0000000000000000 in ?? () > #91 0x0000000000000000 in ?? () > #92 0x0000000000000000 in ?? () > #93 0x0000000000000000 in ?? () > #94 0x0000000000000000 in ?? () > #95 0x0000000000000000 in ?? () > #96 0x0000000000000000 in ?? () > #97 0x0000000000000000 in ?? () > #98 0x0000000000000000 in ?? () > #99 0x0000000000000000 in ?? () > #100 0x0000000000000000 in ?? () > #101 0x0000000000000000 in ?? () > #102 0x0000000000000000 in ?? () > #103 0x0000000000000000 in ?? () > #104 0x0000000000000000 in ?? () > #105 0x0000000000000000 in ?? () > #106 0x0000000000000000 in ?? () > #107 0x0000000000000000 in ?? () > #108 0x0000000000000000 in ?? () > #109 0x0000000000000000 in ?? () > #110 0x0000000000000000 in ?? () > #111 0x0000000000000000 in ?? () > #112 0x0000000000000000 in ?? () > #113 0x0000000000000000 in ?? () > #114 0x0000000000000000 in ?? () > #115 0x0000000000000000 in ?? () > #116 0x0000000000000000 in ?? () > #117 0x0000000000000000 in ?? () > #118 0x0000000000000000 in ?? () > Cannot access memory at address 0xffffff80a5b30000 > (kgdb) q > # ^D > Script done on Fri Sep 11 17:26:02 2009 > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" Is the hardware in the machine (CPU, motherboard, and memory) confirmed to be solid? I ran into a similar situation last month (http://lists.freebsd.org/pipermail/freebsd-fs/2009-August/006606.html), the root cause of which turned out to be bad memory. ZFS tends to make the problem show up more frequently since it uses a lot of memory. -Boris From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 01:56:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBF96106566B for ; Fri, 11 Sep 2009 01:56:54 +0000 (UTC) (envelope-from duncan.young@pobox.com) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id A20278FC0C for ; Fri, 11 Sep 2009 01:56:54 +0000 (UTC) Received: from compute2.internal (compute2.internal [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id F064767B84; Thu, 10 Sep 2009 21:56:53 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 10 Sep 2009 21:56:54 -0400 X-Sasl-enc: 85M4wCfoFfZCKrZQ0Pr5VvGDa2zgOamp1HtZh65JjR1P 1252634212 Received: from [192.168.0.104] (c122-108-168-198.rochd4.qld.optusnet.com.au [122.108.168.198]) by mail.messagingengine.com (Postfix) with ESMTPSA id DF1A9625E; Thu, 10 Sep 2009 21:56:51 -0400 (EDT) Message-ID: <4AA9AE61.7060601@pobox.com> Date: Fri, 11 Sep 2009 11:56:49 +1000 From: Duncan Young User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Boris Kochergin References: <4AA981F4.3090607@pobox.com> <4AA98FCA.9090506@acm.poly.edu> In-Reply-To: <4AA98FCA.9090506@acm.poly.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: zfs woes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 01:56:55 -0000 Boris Kochergin wrote: > Duncan Young wrote: >> Hi all, >> >> Again its happened (my need to restore my main zpool from backups). >> >> I have been having regular crashes (only recently been getting crash >> dumps though), and in the the process >> of upgrading to 7.1-STABLE, upgrading zpools (now 13) and zfs (now 3), I >> now have a problem with >> my main data zpool. >> >> I was having these problems before the upgrade. >> >> After zpool status saying that I had corrupted files (actually a zfs >> filesystem), I tried destroying it (the zfs filesystem), in the hope >> that this >> may make my problems go away). The machine hung. >> >> zpool scrub works, reporting 16 errors. >> zpool status -v crashes. >> starting multiuser hangs (probably on mounting the dud fs). >> I can start single user, and I am currently additional backups of the >> filesytems I can access (most off the corrupted zpool). >> Any accessing the corrupted zfs filesystem crashes the machine. >> >> Now I think it's fair enough that the filesystem is corrupted (I still >> see a need for some type of fsck), but I don't see that the >> machine should crash because of it. Any sugestions? >> >> Script started on Fri Sep 11 17:22:23 2009 >> # uname -a >> FreeBSD 7.2-STABLE FreeBSD 7.2-STABLE #8: Fri Sep 11 04:14:39 EST >> 2009 root@:/usr/obj/usr/src/sys/TRIPLE0 amd64 >> # cd /usr/src/sys/TRIPLE0 >> # kgdb ./kernel.debug /var/crash/vmcore/.25 >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and >> you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "amd64-marcel-freebsd"... >> >> Unread portion of the kernel message buffer: >> Copyright (c) 1992-2009 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 7.2-STABLE #8: Fri Sep 11 04:14:39 EST 2009 >> root@:/usr/obj/usr/src/sys/TRIPLE0 >> module_register: module g_label already exists! >> Module g_label failed to register: 17 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: AMD Phenom(tm) II X4 810 Processor (2608.81-MHz K8-class CPU) >> Origin = "AuthenticAMD" Id = 0x100f42 Stepping = 2 >> >> Features=0x178bfbff >> >> Features2=0x802009 >> AMD >> Features=0xee500800 >> >> AMD >> Features2=0x37ff >> >> TSC: P-state invariant >> Cores per package: 4 >> usable memory = 8441266176 (8050 MB) >> avail memory = 8131702784 (7754 MB) >> ACPI APIC Table: <072709 APIC1045> >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> cpu2 (AP): APIC ID: 2 >> cpu3 (AP): APIC ID: 3 >> This module (opensolaris) contains code covered by the >> Common Development and Distribution License (CDDL) >> see http://opensolaris.org/os/licensing/opensolaris_license/ >> ACPI Warning (tbfadt-0505): Optional field "Pm2ControlBlock" has zero >> address or length: 0 0/1 [20070320] >> ioapic0 irqs 0-23 on motherboard >> kbd1 at kbdmux0 >> acpi0: <072709 XSDT1045> on motherboard >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> acpi0: reservation of fee00000, 1000 (3) failed >> acpi0: reservation of ffb80000, 80000 (3) failed >> acpi0: reservation of fec10000, 20 (3) failed >> acpi0: reservation of 0, a0000 (3) failed >> acpi0: reservation of 100000, dff00000 (3) failed >> ACPI HPET table warning: Sequence is non-zero (2) >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on >> acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pcib1: at device 1.0 on pci0 >> pci1: on pcib1 >> vgapci0: port 0xc000-0xc0ff mem >> 0xf0000000-0xf7ffffff,0xfbce0000-0xfbceffff,0xfbb00000-0xfbbfffff irq 18 >> at device 5.0 on pci1 >> hdac0: mem >> 0xfbcfc000-0xfbcfffff irq 19 at device 5.1 on pci1 >> hdac0: HDA Driver Revision: 20090624_0136 >> hdac0: [ITHREAD] >> pcib2: irq 16 at device 4.0 on pci0 >> pci2: on pcib2 >> hptrr0: port 0xd800-0xd8ff mem 0xfbe00000-0xfbefffff irq 16 at >> device 0.0 on pci2 >> hptrr: adapter at PCI 2:0:0, IRQ 16 >> pcib3: irq 17 at device 5.0 on pci0 >> pci3: on pcib3 >> em0: port 0xec00-0xec1f mem >> 0xfbfe0000-0xfbffffff,0xfbf00000-0xfbf7ffff,0xfbfdc000-0xfbfdffff irq 17 >> at device 0.0 on pci3 >> em0: Using MSIX interrupts >> em0: [ITHREAD] >> em0: [ITHREAD] >> em0: [ITHREAD] >> em0: Ethernet address: 00:1b:21:3d:eb:e7 >> atapci0: port >> 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f >> mem 0xfbaffc00-0xfbafffff irq 22 at device 17.0 on pci0 >> atapci0: [ITHREAD] >> atapci0: AHCI Version 01.10 controller with 6 ports detected >> ata2: on atapci0 >> ata2: [ITHREAD] >> ata3: on atapci0 >> ata3: [ITHREAD] >> ata4: on atapci0 >> ata4: [ITHREAD] >> ata5: on atapci0 >> ata5: [ITHREAD] >> ata6: on atapci0 >> ata6: [ITHREAD] >> ata7: on atapci0 >> ata7: [ITHREAD] >> ohci0: mem 0xfbafd000-0xfbafdfff irq 16 >> at device 18.0 on pci0 >> ohci0: [GIANT-LOCKED] >> ohci0: [ITHREAD] >> usb0: OHCI version 1.0, legacy support >> usb0: on ohci0 >> usb0: USB revision 1.0 >> uhub0: on usb0 >> uhub0: 3 ports with 3 removable, self powered >> ohci1: mem 0xfbafe000-0xfbafefff irq 16 >> at device 18.1 on pci0 >> ohci1: [GIANT-LOCKED] >> ohci1: [ITHREAD] >> usb1: OHCI version 1.0, legacy support >> usb1: on ohci1 >> usb1: USB revision 1.0 >> uhub1: on usb1 >> uhub1: 3 ports with 3 removable, self powered >> ehci0: mem 0xfbaff800-0xfbaff8ff irq >> 17 at device 18.2 on pci0 >> ehci0: [GIANT-LOCKED] >> ehci0: [ITHREAD] >> usb2: EHCI version 1.0 >> usb2: companion controllers, 3 ports each: usb0 usb1 >> usb2: on ehci0 >> usb2: USB revision 2.0 >> uhub2: on usb2 >> uhub2: 6 ports with 6 removable, self powered >> ohci2: mem 0xfbafb000-0xfbafbfff irq 18 >> at device 19.0 on pci0 >> ohci2: [GIANT-LOCKED] >> ohci2: [ITHREAD] >> usb3: OHCI version 1.0, legacy support >> usb3: on ohci2 >> usb3: USB revision 1.0 >> uhub3: on usb3 >> uhub3: 3 ports with 3 removable, self powered >> ohci3: mem 0xfbafc000-0xfbafcfff irq 18 >> at device 19.1 on pci0 >> ohci3: [GIANT-LOCKED] >> ohci3: [ITHREAD] >> usb4: OHCI version 1.0, legacy support >> usb4: on ohci3 >> usb4: USB revision 1.0 >> uhub4: on usb4 >> uhub4: 3 ports with 3 removable, self powered >> ehci1: mem 0xfbaff400-0xfbaff4ff irq >> 19 at device 19.2 on pci0 >> ehci1: [GIANT-LOCKED] >> ehci1: [ITHREAD] >> usb5: EHCI version 1.0 >> usb5: companion controllers, 3 ports each: usb3 usb4 >> usb5: on ehci1 >> usb5: USB revision 2.0 >> uhub5: on usb5 >> uhub5: 6 ports with 6 removable, self powered >> pci0: at device 20.0 (no driver attached) >> atapci1: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 >> ata0: on atapci1 >> ata0: [ITHREAD] >> hdac1: mem >> 0xfbaf4000-0xfbaf7fff irq 16 at device 20.2 on pci0 >> hdac1: HDA Driver Revision: 20090624_0136 >> hdac1: [ITHREAD] >> isab0: at device 20.3 on pci0 >> isa0: on isab0 >> pcib4: at device 20.4 on pci0 >> pci4: on pcib4 >> ohci4: mem 0xfbafa000-0xfbafafff irq 18 >> at device 20.5 on pci0 >> ohci4: [GIANT-LOCKED] >> ohci4: [ITHREAD] >> usb6: OHCI version 1.0, legacy support >> usb6: on ohci4 >> usb6: USB revision 1.0 >> uhub6: on usb6 >> uhub6: 2 ports with 2 removable, self powered >> acpi_button0: on acpi0 >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> psm0: irq 12 on atkbdc0 >> psm0: [GIANT-LOCKED] >> psm0: [ITHREAD] >> psm0: model MouseMan+, device ID 0 >> acpi_aiboost0: on acpi0 >> 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] >> fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 >> on acpi0 >> fdc0: [FILTER] >> cpu0: on acpi0 >> acpi_throttle0: on cpu0 >> cpu1: on acpi0 >> cpu2: on acpi0 >> cpu3: on acpi0 >> cryptosoft0: on motherboard >> orm0: at iomem 0xd7800-0xd87ff 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: cannot reserve I/O port range >> sio1: configured irq 3 not in bitmap of probed irqs 0 >> sio1: port may not be enabled >> ulpt0: > Series, class 0/0, rev 1.10/1.00, addr 2> on uhub0 >> ulpt0: using bi-directional mode >> WARNING: ZFS is considered to be an experimental feature in FreeBSD. >> Timecounters tick every 1.000 msec >> vboxdrv: fAsync=0 offMin=0x12c offMax=0x219 >> hptrr: start channel [0,0] >> hptrr: start channel [0,1] >> hptrr: start channel [0,2] >> hptrr: start channel [0,3] >> hptrr: [0 0] Start channel soft reset. >> hptrr: [0 2] Start channel soft reset. >> hptrr: [0 3] Start channel soft reset. >> hptrr: channel [0,0] started successfully >> hptrr: channel [0,2] started successfully >> hptrr: channel [0,3] started successfully >> hptrr: [0 1] Failed to perform channel hard reset. >> hptrr0: [GIANT-LOCKED] >> hptrr0: [ITHREAD] >> The GEOM class LABEL is already loaded. >> ZFS filesystem version 13 >> ZFS storage pool version 13 >> da0 at hptrr0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-0 device >> da1 at hptrr0 bus 0 target 1 lun 0 >> da1: Fixed Direct Access SCSI-0 device >> da2 at hptrr0 bus 0 target 2 lun 0 >> da2: Fixed Direct Access SCSI-0 device >> acd0: DVDR at ata0-master PIO4 >> ad4: 476940MB at ata2-master SATA300 >> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 >> 0x01 >> (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 >> (probe0:ata0:0:0:0): CAM Status: SCSI Status Error >> (probe0:ata0:0:0:0): SCSI Status: Check Condition >> (probe0:ata0:0:0:0): NOT READY csi:0,0,bb,0 asc:3a,0 >> (probe0:ata0:0:0:0): Medium not present >> (probe0:ata0:0:0:0): Unretryable error >> cd0 at ata0 bus 0 target 0 lun 0 >> cd0: Removable CD-ROM SCSI-0 device >> cd0: 16.000MB/s transfers >> cd0: Attempt to query device size failed: NOT READY, Medium not present >> ad6: 953869MB at ata3-master SATA300 >> ad10: 953869MB at ata5-master SATA300 >> ad12: 476940MB at ata6-master SATA300 >> ad14: 953869MB at ata7-master SATA300 >> hdac0: HDA Codec #0: ATI RS690/780 HDMI >> pcm0: at cad 0 nid 1 on hdac0 >> hdac1: HDA Codec #0: VIA VT1708S_0 >> pcm1: at cad 0 nid 1 on hdac1 >> pcm2: at cad 0 nid 1 on hdac1 >> pcm3: at cad 0 nid 1 on hdac1 >> SMP: AP CPU #2 Launched! >> SMP: AP CPU #3 Launched! >> SMP: AP CPU #1 Launched! >> Trying to mount root from zfs:rootzfs >> <118>Loading configuration files. >> <118>kernel dumps on /dev/ad4s1b >> <118>Entropy harvesting: >> <118> interrupts >> <118> ethernet >> <118> point_to_point >> <118> kickstart >> <118>. >> GEOM_ELI: Device label/swapB.eli created. >> GEOM_ELI: Encryption: AES-CBC 256 >> GEOM_ELI: Crypto: software >> <118>swapon: adding /dev/label/swapB.eli as swap device >> <118>/etc/rc: WARNING: Use of the early.sh script is deprecated >> <118>/etc/rc: WARNING: Please use a new-style rc.d script instead >> <118>/etc/rc: WARNING: See rc(8) for more information >> <118>gmirror: >> <118>No such device: swap_AB. >> <118> >> <118>Starting file system checks: >> <118>/dev/label/bstrapA: FILE SYSTEM CLEAN; SKIPPING CHECKS >> <118>/dev/label/bstrapA: clean, 303581 free (261 frags, 37915 blocks, >> 0.1% fragmentation) >> <118>/dev/label/bstrapB: FILE SYSTEM CLEAN; SKIPPING CHECKS >> <118>/dev/label/bstrapB: clean, 303502 free (318 frags, 37898 blocks, >> 0.1% fragmentation) >> <118>Setting hostuuid: e039c626-5f54-da11-8e5a-e6b6a8a23cf0. >> <118>Setting hostid: 0xd449202f. >> <118>Mounting local file systems: >> <118>. >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x50 >> fault code = supervisor read data, page not present >> instruction pointer = 0x8:0xffffffff80ad7a5e >> stack pointer = 0x10:0xffffff80a5b2f620 >> frame pointer = 0x10:0xffffff80a5b2f6a0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 314 (txg_thread_enter) >> trap number = 12 >> panic: page fault >> cpuid = 1 >> Uptime: 2m11s >> Physical memory: 8050 MB >> Dumping 1553 MB: 1538 1522 1506 1490 1474 1458 1442 1426 1410 1394 1378 >> 1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154 >> 1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898 >> 882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610 >> 594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322 >> 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 >> >> Reading symbols from /boot/kernel/zfs.ko...Reading symbols from >> /bootdirA/boot/kernel/zfs.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/zfs.ko >> Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from >> /bootdirA/boot/kernel/opensolaris.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/opensolaris.ko >> Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from >> /bootdirA/boot/kernel/geom_eli.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/geom_eli.ko >> Reading symbols from /boot/kernel/crypto.ko...Reading symbols from >> /bootdirA/boot/kernel/crypto.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/crypto.ko >> Reading symbols from /boot/kernel/zlib.ko...Reading symbols from >> /bootdirA/boot/kernel/zlib.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/zlib.ko >> Reading symbols from /boot/kernel/geom_label.ko...Reading symbols from >> /bootdirA/boot/kernel/geom_label.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/geom_label.ko >> Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from >> /bootdirA/boot/kernel/geom_mirror.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/geom_mirror.ko >> Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from >> /bootdirA/boot/kernel/snd_hda.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/snd_hda.ko >> Reading symbols from /boot/kernel/sound.ko...Reading symbols from >> /bootdirA/boot/kernel/sound.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/sound.ko >> Reading symbols from /boot/kernel/cd9660_iconv.ko...Reading symbols from >> /bootdirA/boot/kernel/cd9660_iconv.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/cd9660_iconv.ko >> Reading symbols from /boot/kernel/libiconv.ko...Reading symbols from >> /bootdirA/boot/kernel/libiconv.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/libiconv.ko >> Reading symbols from /boot/kernel/aio.ko...Reading symbols from >> /bootdirA/boot/kernel/aio.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/aio.ko >> Reading symbols from /boot/modules/vboxdrv.ko...done. >> Loaded symbols for /boot/modules/vboxdrv.ko >> Reading symbols from /boot/kernel/sem.ko...Reading symbols from >> /bootdirA/boot/kernel/sem.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/sem.ko >> #0 doadump () at pcpu.h:195 >> 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); >> (kgdb) backtrace >> #0 doadump () at pcpu.h:195 >> #1 0x0000000000000004 in ?? () >> #2 0xffffffff803aab90 in boot (howto=260) >> at /usr/src/sys/kern/kern_shutdown.c:418 >> #3 0xffffffff803aafb2 in panic (fmt=0x104
> bounds>) >> at /usr/src/sys/kern/kern_shutdown.c:574 >> #4 0xffffffff80651d03 in trap_fatal (frame=0xffffff0009572390, >> eva=Variable "eva" is not available. >> ) >> at /usr/src/sys/amd64/amd64/trap.c:770 >> #5 0xffffffff806520d5 in trap_pfault (frame=0xffffff80a5b2f570, >> usermode=0) >> at /usr/src/sys/amd64/amd64/trap.c:686 >> #6 0xffffffff80652a63 in trap (frame=0xffffff80a5b2f570) >> at /usr/src/sys/amd64/amd64/trap.c:457 >> #7 0xffffffff8063cb4e in calltrap () >> at /usr/src/sys/amd64/amd64/exception.S:218 >> #8 0xffffffff80ad7a5e in find_block (th=0xffffff8006930000, >> zseg=0xffffff000dafc580, dnp=0xffffff8006d35600, depth=Variable >> "depth" is not available. >> ) >> at >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c:400 >> >> #9 0xffffffff80ad81a3 in traverse_more (th=0xffffff8006930000) >> at >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c:672 >> >> #10 0xffffffff80ad8368 in traverse_dsl_dataset (ds=0x23, txg_start=1, >> advance=Variable "advance" is not available. >> >> ) >> at >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/d---Type >> >> to continue, or q to quit--- >> mu_traverse.c:731 >> #11 0xffffffff80ae41c9 in dsl_dataset_destroy_sync () from >> /boot/kernel/zfs.ko >> #12 0xffffffff80ae6d2a in dsl_sync_task_group_sync >> (dstg=0xffffff000d256600, >> tx=0xffffff000d1fca80) >> at >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_synctask.c:186 >> >> #13 0xffffffff80ae6873 in dsl_pool_sync (dp=0xffffff000d521000, >> txg=3430336) >> at >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:316 >> >> #14 0xffffffff80af59c3 in spa_sync (spa=0xffffff0006d08000, txg=3430336) >> at >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3988 >> >> #15 0xffffffff80afd772 in txg_sync_thread (arg=Variable "arg" is not >> available. >> ) >> at >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:352 >> >> #16 0xffffffff80385452 in fork_exit ( >> callout=0xffffffff80afd490 , arg=0xffffff000d521000, >> frame=0xffffff80a5b2fc80) at /usr/src/sys/kern/kern_fork.c:811 >> #17 0xffffffff8063cf2e in fork_trampoline () >> at /usr/src/sys/amd64/amd64/exception.S:554 >> #18 0x0000000000000000 in ?? () >> #19 0x0000000000000000 in ?? () >> #20 0x0000000000000001 in ?? () >> #21 0x0000000000000000 in ?? () >> #22 0x0000000000000000 in ?? () >> #23 0x0000000000000000 in ?? () >> #24 0x0000000000000000 in ?? () >> #25 0x0000000000000000 in ?? () >> #26 0x0000000000000000 in ?? () >> #27 0x0000000000000000 in ?? () >> #28 0x0000000000000000 in ?? () >> #29 0x0000000000000000 in ?? () >> #30 0x0000000000000000 in ?? () >> #31 0x0000000000000000 in ?? () >> #32 0x0000000000000000 in ?? () >> #33 0x0000000000000000 in ?? () >> #34 0x0000000000000000 in ?? () >> #35 0x0000000000000000 in ?? () >> #36 0x0000000000000000 in ?? () >> #37 0x0000000000000000 in ?? () >> #38 0x0000000000000000 in ?? () >> #39 0x0000000000000000 in ?? () >> #40 0x0000000000000000 in ?? () >> #41 0x0000000000000000 in ?? () >> #42 0x0000000000dde000 in ?? () >> #43 0xffffffff80950d40 in tdq_cpu () >> #44 0xffffffff8095c940 in tdq_groups () >> #45 0xffffffff8095c8c0 in tdq_cpu () >> #46 0xffffff0009572390 in ?? () >> #47 0x0000000000000000 in ?? () >> #48 0xffffff80a5b2f1e8 in ?? () >> #49 0xffffff0009572390 in ?? () >> #50 0xffffffff803ce154 in sched_switch (td=0xffffffff80afd490, >> newtd=0x0, >> flags=0) at /usr/src/sys/kern/sched_ule.c:1938 >> #51 0x0000000000000000 in ?? () >> #52 0x0000000000000000 in ?? () >> #53 0x0000000000000000 in ?? () >> #54 0x0000000000000000 in ?? () >> #55 0x0000000000000000 in ?? () >> #56 0x0000000000000000 in ?? () >> #57 0x0000000000000000 in ?? () >> #58 0x0000000000000000 in ?? () >> #59 0x0000000000000000 in ?? () >> #60 0x0000000000000000 in ?? () >> #61 0x0000000000000000 in ?? () >> #62 0x0000000000000000 in ?? () >> #63 0x0000000000000000 in ?? () >> #64 0x0000000000000000 in ?? () >> #65 0x0000000000000000 in ?? () >> #66 0x0000000000000000 in ?? () >> #67 0x0000000000000000 in ?? () >> #68 0x0000000000000000 in ?? () >> #69 0x0000000000000000 in ?? () >> #70 0x0000000000000000 in ?? () >> #71 0x0000000000000000 in ?? () >> #72 0x0000000000000000 in ?? () >> #73 0x0000000000000000 in ?? () >> #74 0x0000000000000000 in ?? () >> #75 0x0000000000000000 in ?? () >> #76 0x0000000000000000 in ?? () >> #77 0x0000000000000000 in ?? () >> #78 0x0000000000000000 in ?? () >> #79 0x0000000000000000 in ?? () >> #80 0x0000000000000000 in ?? () >> #81 0x0000000000000000 in ?? () >> #82 0x0000000000000000 in ?? () >> #83 0x0000000000000000 in ?? () >> #84 0x0000000000000000 in ?? () >> #85 0x0000000000000000 in ?? () >> #86 0x0000000000000000 in ?? () >> #87 0x0000000000000000 in ?? () >> #88 0x0000000000000000 in ?? () >> #89 0x0000000000000000 in ?? () >> #90 0x0000000000000000 in ?? () >> #91 0x0000000000000000 in ?? () >> #92 0x0000000000000000 in ?? () >> #93 0x0000000000000000 in ?? () >> #94 0x0000000000000000 in ?? () >> #95 0x0000000000000000 in ?? () >> #96 0x0000000000000000 in ?? () >> #97 0x0000000000000000 in ?? () >> #98 0x0000000000000000 in ?? () >> #99 0x0000000000000000 in ?? () >> #100 0x0000000000000000 in ?? () >> #101 0x0000000000000000 in ?? () >> #102 0x0000000000000000 in ?? () >> #103 0x0000000000000000 in ?? () >> #104 0x0000000000000000 in ?? () >> #105 0x0000000000000000 in ?? () >> #106 0x0000000000000000 in ?? () >> #107 0x0000000000000000 in ?? () >> #108 0x0000000000000000 in ?? () >> #109 0x0000000000000000 in ?? () >> #110 0x0000000000000000 in ?? () >> #111 0x0000000000000000 in ?? () >> #112 0x0000000000000000 in ?? () >> #113 0x0000000000000000 in ?? () >> #114 0x0000000000000000 in ?? () >> #115 0x0000000000000000 in ?? () >> #116 0x0000000000000000 in ?? () >> #117 0x0000000000000000 in ?? () >> #118 0x0000000000000000 in ?? () >> Cannot access memory at address 0xffffff80a5b30000 >> (kgdb) q >> # ^D >> Script done on Fri Sep 11 17:26:02 2009 >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > Is the hardware in the machine (CPU, motherboard, and memory) > confirmed to be solid? I ran into a similar situation last month > (http://lists.freebsd.org/pipermail/freebsd-fs/2009-August/006606.html), > the root cause of which turned out to be bad memory. ZFS tends to make > the problem show up more frequently since it uses a lot of memory. > > -Boris I believe the memory to be fine. I ran memtest across it and found no errors. Its also ECC memory (which I have switched on), so much less likely to have errors showing up. Duncan From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 04:58:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 442CC1065672 for ; Fri, 11 Sep 2009 04:58:26 +0000 (UTC) (envelope-from fulanpeng@gmail.com) Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by mx1.freebsd.org (Postfix) with ESMTP id 0431A8FC14 for ; Fri, 11 Sep 2009 04:58:25 +0000 (UTC) Received: by vws27 with SMTP id 27so532855vws.3 for ; Thu, 10 Sep 2009 21:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=fpVRV9FXbCIWN+f5fFdGy+7lcgzr5DBFjtwUykf2WTE=; b=rWDL/31r8gDZWA7skJShRsF1Qlzdg2rJ/Iw96LSnvDC3DndaOVdwqZO1a18UlqL6z4 IHtgHrzWn/BDZWrBLhLgyYPROb4Y1re9+/JDV9BUtiTnEGBVYoBAxi90xxfvC/DAJC7W Qkp1KfGWUApZWT5XTTzrYWCuklDZ4I+u9SDb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=pPR2Zk3Hmns/eQoP19t5XuMhHGqwChdIL76MOAXT+tGDmvU4+Hq2icXhDRp6cqp8nV +fEgzDPtZ1L9X0S85nsqQ2tcF9w3o4OZIOnQ/81W/oQGBd5GZKemzHDNGeo9DvP1Jl2g XcFADU2FhhbolXw6uwIcKuuaCLOGSl5xwRskM= MIME-Version: 1.0 Received: by 10.220.15.71 with SMTP id j7mr2887255vca.79.1252645104900; Thu, 10 Sep 2009 21:58:24 -0700 (PDT) Date: Fri, 11 Sep 2009 04:58:24 +0000 Message-ID: From: fulan Peng To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: How to make sysctl.conf effect? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 04:58:26 -0000 I am sorry if this is not the right place to ask this question. I am using freebsd amd64 7.2. I cannot make more than 32768 directories in a folder. So I edited /etc/sysctl.conf and added a line vfs_ufs_dirhash_maxmem=67108864 when I do sysctl -a |grep mem, I saw the setting was correct. But when I went into a directory and try to make more than 32768 subdirectories, it always was told me too many links. I have rebooted many, many times. I even powered of the computer several times. I have 6G memory in the computer. And I even recompiled the kernel once. All failed. Could you please help me to give me some hints to activate the /etc/sysctl.conf file. Thanks a lot! Fulan Peng From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 06:30:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DEAA1065670 for ; Fri, 11 Sep 2009 06:30:58 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 3FAAC8FC0A for ; Fri, 11 Sep 2009 06:30:57 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.0/8.14.0) with ESMTP id n8B6UvGM076043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Sep 2009 01:30:57 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n8B6UuPw071391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Sep 2009 01:30:56 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n8B6UuZq071324; Fri, 11 Sep 2009 01:30:56 -0500 (CDT) (envelope-from dan) Date: Fri, 11 Sep 2009 01:30:55 -0500 From: Dan Nelson To: fulan Peng Message-ID: <20090911063055.GC37884@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email2.allantgroup.com [199.67.51.78]); Fri, 11 Sep 2009 01:30:57 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: freebsd-current@freebsd.org Subject: Re: How to make sysctl.conf effect? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 06:30:58 -0000 In the last episode (Sep 11), fulan Peng said: > I am sorry if this is not the right place to ask this question. > I am using freebsd amd64 7.2. > I cannot make more than 32768 directories in a folder. So I edited > /etc/sysctl.conf and added a line > vfs_ufs_dirhash_maxmem=67108864 > when I do sysctl -a |grep mem, I saw the setting was correct. > But when I went into a directory and try to make more than 32768 > subdirectories, it always was told me too many links. I have rebooted > many, many times. I even powered of the computer several times. I have > 6G memory in the computer. And I even recompiled the kernel once. All > failed. dirhash is simply a speed optimization for large directories. It doesn't set a hard limit of any sort. Your problem is that you are using the UFS filesystem, which does not allow more than 32768 subdirectories. The "number of links" counter in UFS filesystems is a signed short type, and each subdirectory has to create a ".." link back to the parent directory, so if you try to create more than 32768 subdirectories, it fails because the parent directory would exceed the maximum link count. You'll need to either create multiple levels of directories (i.e. make directories called 345/678/ instead of 345678/ ), or switch to the zfs filesystem, which has a much higher limit. I was able to create 1 million subdirs as a test, using zsh's brace expansion syntax to generate the directory names: (dan@dan) / # zfs create -o mountpoint=/tmp/zz local/zz (dan@dan) / # cd /tmp/zz (dan@dan) /tmp/zz/ # for i in {00..99} ; do echo ${i}0000 ; mkdir ${i}{0000..9999} ; done 000000 [..] 990000 (dan@dan) /tmp/zz/ # echo * | wc -w 1000000 -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 07:02:00 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9456F10656C1 for ; Fri, 11 Sep 2009 07:02:00 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CAE5A8FC19 for ; Fri, 11 Sep 2009 07:01:59 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA07137; Fri, 11 Sep 2009 10:01:57 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Mm08r-000Cn5-5f; Fri, 11 Sep 2009 10:01:57 +0300 Message-ID: <4AA9F5E4.6020305@icyb.net.ua> Date: Fri, 11 Sep 2009 10:01:56 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090823) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, ddkprog@yahoo.com X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: vesa(4) and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 07:02:00 -0000 I am trying x86emu-enabled vesa (from head) on amd64. First of all, thank you very much for doing this! It works almost perfectly. 'Almost', because I have one minor issue. If I set non-default mode in a console, then switch to X, then switch back, the colors in the console get shuffled. If I switch to another virtual console with default mode and then back, the colors get restored to normal. This is with radeon hardware and driver: vgapci0: port 0xee00-0xeeff mem 0xd0000000-0xdfffffff,0xfdfe0000-0xfdfeffff,0xfde00000-0xfdefffff irq 18 at device 5.0 on pci1 drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.31.0 20080613 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 info: [drm] Setting GART location based on new memory map I can provide any addition info and debugging. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 07:45:52 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62EFD1065670 for ; Fri, 11 Sep 2009 07:45:52 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.freebsd.org (Postfix) with ESMTP id 25D828FC17 for ; Fri, 11 Sep 2009 07:45:51 +0000 (UTC) Received: by mail.0x20.net (Postfix, from userid 1002) id 8E629398B3; Fri, 11 Sep 2009 09:45:50 +0200 (CEST) Date: Fri, 11 Sep 2009 09:45:50 +0200 From: Lars Engels To: current@FreeBSD.org Message-ID: <20090911074550.GF19090@e.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline X-Editor: VIM - Vi IMproved 7.2 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: "wpi0: fatal firmware error" in BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 07:45:52 -0000 --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, after upgrading from BETA1 to BETA4 my wpi0 device stops working after a few minutes. The kernel shows: wpi0: fatal firmware error dmesg says this about the device: wpi0: mem 0xd4000000-0xd4000fff irq 16 at d= evice 0.0 on pci2 wpi0: Driver Revision 20071127 wpi0: Hardware Revision (0x1) adding chan 1 (2412MHz) flags=3D0x2b maxpwr=3D15 passive=3D0, offset 2 [...] adding chan 140 (5700MHz) flags=3D0xb1 maxpwr=3D16 passive=3D1, offset 49 power group 0: chan=3D1 maxpwr=3D46 temp=3D-190 sample 0: index=3D13 power=3D43 sample 1: index=3D29 power=3D31 sample 2: index=3D47 power=3D11 sample 3: index=3D58 power=3D0 sample 4: index=3D77 power=3D-18 [...] wpi0: Regulatory Domain: MoW2 wpi0: Hardware Type: B wpi0: Hardware Revision: ? wpi0: SKU does support 802.11a wpi0: [ITHREAD] Lars --=20 Lars Engels E-Mail: lars.engels@0x20.net =09 --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqqAC4ACgkQKc512sD3afhiJgCfdm8QdfQF4izqjkoxa/YJsFcN 5S0AoISWzgv73YcXn16j1znwdYXjQqgN =43hf -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 09:58:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E994106566C; Fri, 11 Sep 2009 09:58:12 +0000 (UTC) (envelope-from tlott@gamesnet.de) Received: from spirit.gamesnet.de (spirit.gamesnet.de [87.230.101.86]) by mx1.freebsd.org (Postfix) with ESMTP id 203C78FC21; Fri, 11 Sep 2009 09:58:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by spirit.gamesnet.de (Postfix) with ESMTP id 97E8D304E92; Fri, 11 Sep 2009 11:57:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at gamesnet.de Received: from spirit.gamesnet.de ([127.0.0.1]) by localhost (spirit.gamesnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GW+CiXCrsOJ6; Fri, 11 Sep 2009 11:57:36 +0200 (CEST) Received: from mail.gamesnet.de (localhost [127.0.0.1]) by spirit.gamesnet.de (Postfix) with ESMTPA id 7BD08304D22; Fri, 11 Sep 2009 11:51:25 +0200 (CEST) Received: from 87.154.170.53 (proxying for 87.154.170.53) (SquirrelMail authenticated user tlott@gamesnet.de) by mail.gamesnet.de with HTTP; Fri, 11 Sep 2009 11:51:25 +0200 Message-ID: <102295df02d347c97bd098dc89ccb534.squirrel@mail.gamesnet.de> In-Reply-To: <20090910215254.GD2718@garage.freebsd.pl> References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> <20090909054249.GH1539@garage.freebsd.pl> <20090909101346.01887a02@sub.han.vpn.gamesnet.de> <20090910215254.GD2718@garage.freebsd.pl> Date: Fri, 11 Sep 2009 11:51:25 +0200 From: tlott@gamesnet.de To: "Pawel Jakub Dawidek" User-Agent: SquirrelMail/1.4.20 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Problems with ZFS on AMD64 (and i386 now) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 09:58:12 -0000 > On Wed, Sep 09, 2009 at 10:13:46AM +0200, Tobias Lott wrote: >> >> >> On Wed, 9 Sep 2009 07:42:49 +0200 >> Pawel Jakub Dawidek wrote: >> >> > On Wed, Sep 09, 2009 at 12:19:42AM +0200, Tobias Lott wrote: >> > > Hey Everyone >> > > >> > > I've managed to get some Output for this, using BETA2 LiveCD (gonna >> > > try using BETA4 CD Tomorrow). >> > > >> > > 'zfs import -f poolname' triggered this, Booting kernel.old (BETA3) >> > > and today built BETA4 Kernel Panic mounting zfs Volumes. >> > > Booting single user mode I get output of zfs list and so on but >> > > mounting whatever volume also Panics. >> > >> > Why -f? Were there a poblem in importing pool? >> > >> > > Stack output, if there's more you need I'll gladly help >> > > http://i27.tinypic.com/2d78qpd.jpg >> > > http://i31.tinypic.com/oqhv2w.jpg >> > > http://i28.tinypic.com/oktsag.jpg >> > >> > Could you also provide top part of the backtrace? >> > >> Oh yeah my bad >> >> http://i29.tinypic.com/nqwxo2.jpg >> http://i26.tinypic.com/209hanm.jpg > > Seems that one of the vdevs is NULL. Could you tell me why you decided > to use -f option for importing the pool? > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > Because zpool import tank says: cannot import 'tank': pool may be in use from other system use '-f' to import anyway From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 10:29:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAF6D106566C for ; Fri, 11 Sep 2009 10:29:16 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id 3E35F8FC27 for ; Fri, 11 Sep 2009 10:29:15 +0000 (UTC) Received: by ewy4 with SMTP id 4so966504ewy.36 for ; Fri, 11 Sep 2009 03:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=sxP2VaI2QC9JsrCNjX2ClzUP4io/YPzWlMqb7Ma/AO4=; b=mpmZKs2xixOqYl2fu4sfsag4q/KwojoBqpLfQYQbrk04IE5+uDgFET8OiHX+/fRoYi 1LGEj16v3ojAfwoe2OYYuRQxS1gGChy/Mk8cCbg928q5oH09qn/uI6H2nKdAqZB+eCBM 8iZcH5ZnbNfrdQC7fTzeeOgZtRMCjhsyq5PZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=nq7ojfyfe3zQKCg/bw322DNGuduxavLWPyUfBDsTzTraPnXfWY9wbOObQyxkHafAZf 2TxnwZqxwAYR9WHUpRurRC92ToF9L3N2TxN5DHdrVBsf0ipQXpdisW4hNIJB4KkecUEV KYq082d8ZiRhQTR5EaLR2+nJ106UJ3bkgCHHY= Received: by 10.211.160.19 with SMTP id m19mr391331ebo.2.1252664955096; Fri, 11 Sep 2009 03:29:15 -0700 (PDT) Received: from localhost (95-24-170-142.broadband.corbina.ru [95.24.170.142]) by mx.google.com with ESMTPS id 7sm603834eyg.26.2009.09.11.03.29.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 11 Sep 2009 03:29:12 -0700 (PDT) From: Anonymous To: Andriy Gapon References: <4AA9F5E4.6020305@icyb.net.ua> Date: Fri, 11 Sep 2009 14:29:10 +0400 In-Reply-To: <4AA9F5E4.6020305@icyb.net.ua> (Andriy Gapon's message of "Fri, 11 Sep 2009 10:01:56 +0300") Message-ID: <863a6tbwqx.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, ddkprog@yahoo.com Subject: Re: vesa(4) and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 10:29:16 -0000 Andriy Gapon writes: > I am trying x86emu-enabled vesa (from head) on amd64. > First of all, thank you very much for doing this! > It works almost perfectly. 'Almost', because I have one minor issue. > > If I set non-default mode in a console, then switch to X, then switch > back, the colors in the console get shuffled. By non-default do you mean 8bit mode? Have you tried 32bit and 16bit modes? > If I switch to another virtual console with default mode and then > back, the colors get restored to normal. > > This is with radeon hardware and driver: > vgapci0: port 0xee00-0xeeff mem > 0xd0000000-0xdfffffff,0xfdfe0000-0xfdfeffff,0xfde00000-0xfdefffff irq 18 at device > 5.0 on pci1 > drm0: on vgapci0 > info: [drm] MSI enabled 1 message(s) > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] Initialized radeon 1.31.0 20080613 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > info: [drm] Setting GART location based on new memory map > > I can provide any addition info and debugging. From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 10:34:12 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E0DC10656A4 for ; Fri, 11 Sep 2009 10:34:12 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 922768FC17 for ; Fri, 11 Sep 2009 10:34:11 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA12198; Fri, 11 Sep 2009 13:34:07 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Mm3SB-000DH4-MD; Fri, 11 Sep 2009 13:34:07 +0300 Message-ID: <4AAA279F.1060703@icyb.net.ua> Date: Fri, 11 Sep 2009 13:34:07 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090823) MIME-Version: 1.0 To: Anonymous References: <4AA9F5E4.6020305@icyb.net.ua> <863a6tbwqx.fsf@gmail.com> In-Reply-To: <863a6tbwqx.fsf@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, ddkprog@yahoo.com Subject: Re: vesa(4) and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 10:34:12 -0000 on 11/09/2009 13:29 Anonymous said the following: > Andriy Gapon writes: > >> I am trying x86emu-enabled vesa (from head) on amd64. >> First of all, thank you very much for doing this! >> It works almost perfectly. 'Almost', because I have one minor issue. >> >> If I set non-default mode in a console, then switch to X, then switch >> back, the colors in the console get shuffled. > > By non-default do you mean 8bit mode? Have you tried 32bit and 16bit modes? Non-default is anything that is not the default 80x25. I actually tried a 16-bit one, I will try a 32-bit one for test coverage. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 10:36:26 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12E96106566B for ; Fri, 11 Sep 2009 10:36:26 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 56B6A8FC12 for ; Fri, 11 Sep 2009 10:36:25 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA12306; Fri, 11 Sep 2009 13:36:22 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Mm3UM-000DHU-7l; Fri, 11 Sep 2009 13:36:22 +0300 Message-ID: <4AAA2825.8050906@icyb.net.ua> Date: Fri, 11 Sep 2009 13:36:21 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090823) MIME-Version: 1.0 To: Anonymous References: <4AA9F5E4.6020305@icyb.net.ua> <863a6tbwqx.fsf@gmail.com> <4AAA279F.1060703@icyb.net.ua> In-Reply-To: <4AAA279F.1060703@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, ddkprog@yahoo.com Subject: Re: vesa(4) and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 10:36:26 -0000 on 11/09/2009 13:34 Andriy Gapon said the following: > on 11/09/2009 13:29 Anonymous said the following: >> Andriy Gapon writes: >> >>> I am trying x86emu-enabled vesa (from head) on amd64. >>> First of all, thank you very much for doing this! >>> It works almost perfectly. 'Almost', because I have one minor issue. >>> >>> If I set non-default mode in a console, then switch to X, then switch >>> back, the colors in the console get shuffled. >> By non-default do you mean 8bit mode? Have you tried 32bit and 16bit modes? > > Non-default is anything that is not the default 80x25. > I actually tried a 16-bit one, I will try a 32-bit one for test coverage. Yes, the problem is still there with 32-bit mode too. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 10:50:07 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A8B91065693 for ; Fri, 11 Sep 2009 10:50:07 +0000 (UTC) (envelope-from ddkprog@yahoo.com) Received: from web59108.mail.re1.yahoo.com (web59108.mail.re1.yahoo.com [66.196.101.19]) by mx1.freebsd.org (Postfix) with SMTP id C4C4A8FC0A for ; Fri, 11 Sep 2009 10:50:06 +0000 (UTC) Received: (qmail 11526 invoked by uid 60001); 11 Sep 2009 10:23:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252664606; bh=AL+3P81FC+k8xq4THeEJeqeTEt8OKBZTRrbb91dcKDI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bPXcll+W2+yPaXXBJbhJt8mXZyE8E4YjQDqizY1vbhviiUOscV88j/4JDkhj231Jkv8l1wySAULwybWA+yL5dlKCJmRU+mDN6+UFHr0htA44H2FwNrWktsrrjPFWugzD5PJzvBZgoIRtNT41Jh49qZ7XD0pQvWwiJP104dJyonk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AD3Rh/PQXOKP+xW+IxgVXkyk/aNTaV9DoRh0ztw3KhQ+h0CkTjLniNPGY/ahTnlAFZxKLRvyUJyLLXsjjpAXNWf681J+eG4AKhJ5lyN8ofzWSvXMnhVC5BryKpw0l75aZxKw77eUSgErtxsCvh6ck0/Uv9KJbfPb78L28q7XUUc=; Message-ID: <85911.11390.qm@web59108.mail.re1.yahoo.com> X-YMail-OSG: vyEb0EcVM1mL3Chw15bB9csROoJhAQBIumODqLVjyyOBS5acHuNwpjsoe1ESVk22ox_RVJLNa_iMvlmBfVuCFTwSxBRaDb3VGSUw_vWA6cuLezaXqJzop9MRiik5QApYtjjM.Oj5kuCri4jxuSQGysTtk0KN2b2ys3fT6F.lgosp.xFBPHn2EzvJFdNJxZ87JrvZ.G90ykJUzyU82b1VsSx329wV3QjDUdCbKMzG8l4AH0WowKigax4Anaj6OhMAICt5Pk.bsD5Bw2H6UlA- Received: from [95.109.154.178] by web59108.mail.re1.yahoo.com via HTTP; Fri, 11 Sep 2009 03:23:26 PDT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.347.2 Date: Fri, 11 Sep 2009 03:23:26 -0700 (PDT) From: ddk ddk To: freebsd-current@FreeBSD.org In-Reply-To: <4AA9F5E4.6020305@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 11 Sep 2009 11:28:39 +0000 Cc: swell.k@gmail.com, delphij@FreeBSD.ORG Subject: Re: vesa(4) and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 10:50:07 -0000 > > I am trying x86emu-enabled vesa (from head) on amd64. > First of all, thank you very much for doing this! > It works almost perfectly. 'Almost', because I have one > minor issue. > > If I set non-default mode in a console, then switch to X, > then switch back, the > colors in the console get shuffled. If I switch to another > virtual console with > default mode and then back, the colors get restored to > normal. > > This is with radeon hardware and driver: > vgapci0: port 0xee00-0xeeff > mem > 0xd0000000-0xdfffffff,0xfdfe0000-0xfdfeffff,0xfde00000-0xfdefffff > irq 18 at device > 5.0 on pci1 > drm0: on vgapci0 > info: [drm] MSI enabled 1 message(s) > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] Initialized radeon 1.31.0 20080613 > vga0: at port 0x3c0-0x3df iomem > 0xa0000-0xbffff on isa0 > info: [drm] Setting GART location based on new memory map > > I can provide any addition info and debugging. > > -- > Andriy Gapon > I think I can repeat this bug on my hardware but now there is a more serious bug impossible to lower the resolution of the console can only improve ie 80x25 -> 800x600 -> 1024x768 when is lowered to 800x600 -> 80x25 or 1024x768->800x600 the system freezy is not a problem driver vesa I think this is a problem that has added a new terminal teken by ed@ becouse there is no problem on freebsd 7 where is no teken where I can switch to any low mode From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 11:36:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12CDC1065672 for ; Fri, 11 Sep 2009 11:36:25 +0000 (UTC) (envelope-from nick-lists@netability.ie) Received: from mail.acquirer.com (mail.acquirer.com [87.198.142.193]) by mx1.freebsd.org (Postfix) with ESMTP id 8B27B8FC13 for ; Fri, 11 Sep 2009 11:36:24 +0000 (UTC) X-Envelope-To: Received: from cupcake.internal.acquirer.com (cupcake.internal.acquirer.com [10.228.100.105]) (authenticated bits=0) by mail.acquirer.com (8.14.3/8.14.3) with ESMTP id n8BBaJYT054331 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 11 Sep 2009 12:36:19 +0100 (IST) (envelope-from nick-lists@netability.ie) Message-ID: <4AAA3633.1040004@netability.ie> Date: Fri, 11 Sep 2009 12:36:19 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <200909011005.18200.jhb@freebsd.org> <20090908214402.43009577@sub.han.vpn.gamesnet.de> <20090909001942.0affc96c@sub.han.vpn.gamesnet.de> <20090909054249.GH1539@garage.freebsd.pl> <20090909101346.01887a02@sub.han.vpn.gamesnet.de> <20090910215254.GD2718@garage.freebsd.pl> <102295df02d347c97bd098dc89ccb534.squirrel@mail.gamesnet.de> In-Reply-To: <102295df02d347c97bd098dc89ccb534.squirrel@mail.gamesnet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,BAYES_00,TW_ZF autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muffin.acquirer.com Subject: Re: Problems with ZFS on AMD64 (and i386 now) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 11:36:25 -0000 On 11/09/2009 10:51, tlott@gamesnet.de wrote: > Because zpool import tank says: > cannot import 'tank': pool may be in use from other system > use '-f' to import anyway Eh, yah, when messing around with zfs from single-user boot, it's a good idea to run "/etc/rc.d/hostid start" first. Otherwise you end up writing 0000000 as the host id of the last system to mount your zfs pool, and this is one of the means used to determine whether the pool is mounted by any other system. Nick From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 11:40:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80134106566C; Fri, 11 Sep 2009 11:40:57 +0000 (UTC) (envelope-from nick-lists@netability.ie) Received: from mail.acquirer.com (mail.acquirer.com [87.198.142.193]) by mx1.freebsd.org (Postfix) with ESMTP id DB17B8FC17; Fri, 11 Sep 2009 11:40:56 +0000 (UTC) X-Envelope-To: freebsd-current@freebsd.org Received: from cupcake.internal.acquirer.com (cupcake.internal.acquirer.com [10.228.100.105]) (authenticated bits=0) by mail.acquirer.com (8.14.3/8.14.3) with ESMTP id n8BBeqIs000958 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 11 Sep 2009 12:40:53 +0100 (IST) (envelope-from nick-lists@netability.ie) Message-ID: <4AAA3744.5020604@netability.ie> Date: Fri, 11 Sep 2009 12:40:52 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: John Baldwin References: <4A9BF23F.6070801@netability.ie> <200909011002.59592.jhb@freebsd.org> <4AA52BE4.3070708@netability.ie> <200909081325.13149.jhb@freebsd.org> In-Reply-To: <200909081325.13149.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muffin.acquirer.com Cc: freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 11:40:57 -0000 On 08/09/2009 18:25, John Baldwin wrote: > So as with the other pciconf output I got, it seems that it is reading the > registers ok in both cases. Can you add some printfs to the ata driver to > figure out when it starts behaving differently (e.g. reading a value from a > register) between the mcfg=0 and mcfg=1 cases on 8? oh my, this is causing sadness. I've installed 8.0 on a usb key and am running into the mountroot problem that others are seeing: > http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011445.html The usb key is a 2yo Kingston unit. > umass0: on usbus1 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:0:0:-1: Attached to scbus0 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 3936MB (8060928 512 byte sectors: 255H 63S/T 501C) / is mounted on /dev/da0s1a, and when I type "ufs:/dev/da0s1a" at the mountroot> prompt, it usually continues bootup, but not always. However, if I use a PS/2 keyboard when it boots up, the console keeps on scrolling up as if the cat were sitting on the return key, and it refuses to accept any input from the keyboard after mountroot>. A USB keyboard usually works better, but not always. And it only works if I plug in the keyboard before turning the machine on. Frustrating :-( Anyway, at this stage, I have a bootable usb key with an 8.0-beta4 kernel built on it, and reboots mostly work. You'll have to excuse me but my ata driver clue is epsilon away from zero. If you can tell me what sort of stuff to put where, I can build a kernel with local mods and report on what it's doing. But being inventive with this is beyond my understanding of what's going on in the pcie subsystem. Sorry :-( Nick From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 12:06:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8949F106566B for ; Fri, 11 Sep 2009 12:06:53 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 493488FC14 for ; Fri, 11 Sep 2009 12:06:53 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mm4tw-000J2t-90 for freebsd-current@freebsd.org; Fri, 11 Sep 2009 14:06:52 +0200 Date: Fri, 11 Sep 2009 14:06:52 +0200 From: Kurt Jaeger To: freebsd-current@freebsd.org Message-ID: <20090911120652.GI48206@home.opsec.eu> References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im> <200909011002.59592.jhb@freebsd.org> <4AA52BE4.3070708@netability.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AA52BE4.3070708@netability.ie> Subject: 8.0-BETA4 sysinstaller and install on LSI MegaRAID (mfid0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 12:06:53 -0000 Hi! I used the 8.0-BETA4 amd64 bootonly CD to boot a FSC RX330 S1 server which has a built-in LSI megaraid. I sucessfully installed 7.2-i386 on that same hardware before. The resulting dmesg.boot can be found at http://www.nepustil.net/support/tmp/dmesg.boot-7.2-i386 The error in the FreeBSD Disklabel Editor (when I used "w" to trigger the necessary newfs calls) was: Unable to find device node for /dev/mfid0s1b in /dev The Creation of filesystems will be aborted. Using an emergency shell, I typed: cd /dev echo * and found only the following device nodes: mfi0 mfid0 mfid0s1 mfid0s2 but no mfid0s1a, 1b, ... Something is going wrong, any ideas ? Thanks! -- pi@opsec.eu +49 171 3101372 11 years to go ! From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 13:01:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7140D1065672 for ; Fri, 11 Sep 2009 13:01:12 +0000 (UTC) (envelope-from raul@pop.isdefe.es) Received: from mail1.isdefe.es (mail1.isdefe.es [194.15.213.239]) by mx1.freebsd.org (Postfix) with ESMTP id 35FA08FC27 for ; Fri, 11 Sep 2009 13:01:11 +0000 (UTC) Received: from mail1.isdefe.es (mail1.isdefe.es [127.0.0.1]) by localhost.isdefe.es (Postfix) with ESMTP id AFED1316743; Fri, 11 Sep 2009 15:00:43 +0200 (CEST) Received: from [10.200.104.66] (unknown [10.200.104.66]) by mail1.isdefe.es (Postfix) with ESMTP id A3AB7316742; Fri, 11 Sep 2009 15:00:43 +0200 (CEST) Message-ID: <4AAA4A16.4060709@pop.isdefe.es> Date: Fri, 11 Sep 2009 15:01:10 +0200 From: Raul User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Chris Ruiz References: <54854a7a0907150322n52a3595el5352a3987d2c75ac@mail.gmail.com> <58c737d70907151035ya9a829eyf4945d1fadc4ce0e@mail.gmail.com> <4A5EFFF7.4060708@pop.isdefe.es> <4AA797D1.9050409@pop.isdefe.es> In-Reply-To: <4AA797D1.9050409@pop.isdefe.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Andrew Tulloch , freebsd-current@freebsd.org Subject: Re: Boot-time hang with the CISS driver on HP 385 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 13:01:12 -0000 Raul escribió: [....] > ciss0: PERFORMANT Transport > ciss0: can't allocate interrupt > panic: mtx_unlock() of spin mutex (null) @ > /usr/src/sys/dev/ciss/ciss.c:1903 > cpuid = 0 > KBD: enter: panic > .... [....] After (some) re-reading and comparing dmesg's of other colleagues with this hardware (hp dl 385) something wrong was happening with the irq mapping on my boxes (acpi?). Several upgrades of bios, other OS running on them before ... whatever. As a quick and dirty try i've erased nvram leaving behind all previous settings. As a result, boot process goes further ... and stop setting something about ipv6. I'll see more tomorrow. Maybe this can also help on other systems with similar ciss controllers. Regars, Raul. From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 13:47:46 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C71D5106566C for ; Fri, 11 Sep 2009 13:47:46 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1C8908FC1C for ; Fri, 11 Sep 2009 13:47:45 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA16086 for ; Fri, 11 Sep 2009 16:47:44 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4AAA54FF.9080701@icyb.net.ua> Date: Fri, 11 Sep 2009 16:47:43 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: crashinfo issue in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 13:47:46 -0000 I had a panic (provoked via sw watchdog, nothing exciting) and after reboot I noticed that couple of processes dumped core, apparently while running as part of crashinfo procedure. savecore: reboot after panic: watchdog timeout savecore: writing core to vmcore.0 kernel: pid 725 (ps), uid 0: exited on signal 11 (core dumped) kernel: pid 742 (fstat), uid 0: exited on signal 11 core.0.txt accordingly has: ------------------------------------------------------------------------ ps -axl Segmentation fault (core dumped) ------------------------------------------------------------------------ fstat Segmentation fault ------------------------------------------------------------------------ The world doesn't have debug symbols, so gdb doesn't produce much. Still, it gives some insights: ps: #0 0x0000000800959df6 in bcopy () from /lib/libc.so.7 #1 0x000000080076f11c in _kvm_freeprocs () from /lib/libkvm.so.5 #2 0x000000080076f830 in kvm_getprocs () from /lib/libkvm.so.5 #3 0x0000000000405273 in uname () core size is about 1G. I couldn't find fstat core file. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 13:54:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFC8D1065670 for ; Fri, 11 Sep 2009 13:54:17 +0000 (UTC) (envelope-from andrewwtulloch@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id 819B98FC08 for ; Fri, 11 Sep 2009 13:54:17 +0000 (UTC) Received: by ewy4 with SMTP id 4so1111483ewy.36 for ; Fri, 11 Sep 2009 06:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=uFoLQsgkye2LdrsOaMoi/39iC55feBPdh4yB4e1fDZE=; b=RKx/RYOrIFXTVa9iRJ36W+/SCkdzJiTc9BcUxAp1UW/iFl7oQP4o5RTS5spvlxhKy4 PPGK3OOwk6m3Cibe1bPpGebT5awkdObrKyCNzqj1YKqsYLUvYF8B5tom0ujmqRmBuRQP c/+zUbv6YD2DlXSwHOAbckzewZvSkLmBL+WFo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Pen9Hcet1Aqg0n3gMU7UNLgGjidaeld1zu434ZQpdszwimV3XIoLf0ahu0xKKg9R15 w3tcEwfgmY8Lt5VZPCP6LuUnAOgeb9OySinKCrRKdPFUNNRm+e4OJg7HR2SkhXZb4Q/+ K6ovfh5NVWkF1NMjoEPXjt32nxtgRCCIRT4G8= MIME-Version: 1.0 Sender: andrewwtulloch@gmail.com Received: by 10.216.53.21 with SMTP id f21mr433822wec.48.1252677256430; Fri, 11 Sep 2009 06:54:16 -0700 (PDT) In-Reply-To: <4AAA4A16.4060709@pop.isdefe.es> References: <54854a7a0907150322n52a3595el5352a3987d2c75ac@mail.gmail.com> <58c737d70907151035ya9a829eyf4945d1fadc4ce0e@mail.gmail.com> <4A5EFFF7.4060708@pop.isdefe.es> <4AA797D1.9050409@pop.isdefe.es> <4AAA4A16.4060709@pop.isdefe.es> Date: Fri, 11 Sep 2009 14:54:16 +0100 X-Google-Sender-Auth: cb060ab997d69b4e Message-ID: <54854a7a0909110654g4dadea54p9e01bf908fc0c850@mail.gmail.com> From: Andrew Tulloch To: Raul Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 11 Sep 2009 13:56:38 +0000 Cc: Chris Ruiz , freebsd-current@freebsd.org Subject: Re: Boot-time hang with the CISS driver on HP 385 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 13:54:18 -0000 2009/9/11 Raul : > Raul escribi=F3: > > [....] >> >> ciss0: PERFORMANT Transport >> ciss0: can't allocate interrupt >> panic: mtx_unlock() of spin mutex (null) @ >> /usr/src/sys/dev/ciss/ciss.c:1903 >> cpuid =3D 0 >> KBD: enter: panic >> .... > > [....] > > After (some) re-reading and comparing dmesg's of other colleagues with th= is > hardware (hp dl 385) something wrong was happening with the irq mapping o= n > my boxes (acpi?). Several upgrades of bios, other OS running on them befo= re > ... whatever. As a quick and dirty try i've erased nvram leaving behind a= ll > previous settings. As a result, boot process goes further ... and stop > setting something about ipv6. I'll see more tomorrow. > > Maybe this can also help on other systems with similar ciss controllers. > > Regars, > Raul. Raul, I found my issues seemed to be related to the bge controller in the machine and setting the tunable: hw.bge.allow_asf=3D0 resolved the problem for me and the machine would reliably boot and has worked flawlessly since, have you tried that at all? I've seen other people mentioning similar issues with bge0 in HP machines not working with 8.0 This tunable defaults to 0 on RELENG_7, but 1 on RELENG_8 might be worth changing it back if it makes a lot of machine unbootable? Regards, Andrew From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 14:23:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B386B106568D for ; Fri, 11 Sep 2009 14:23:38 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward14.yandex.ru (forward14.yandex.ru [95.108.130.92]) by mx1.freebsd.org (Postfix) with ESMTP id 427A08FC0C for ; Fri, 11 Sep 2009 14:23:38 +0000 (UTC) Received: from smtp12.yandex.ru (smtp12.yandex.ru [95.108.131.191]) by forward14.yandex.ru (Yandex) with ESMTP id 734592680BCF for ; Fri, 11 Sep 2009 18:23:36 +0400 (MSD) Received: from btr.properlan.net (vpn.heavennet.ru [77.72.136.194]) by smtp12.yandex.ru (Yandex) with ESMTPSA id 402C14CC0130 for ; Fri, 11 Sep 2009 18:23:36 +0400 (MSD) Message-ID: <4AAA5D61.6020900@yandex.ru> Date: Fri, 11 Sep 2009 18:23:29 +0400 From: "Andrey V. Elsukov" User-Agent: Thunderbird 2.0.0.22 (X11/20090821) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1252679016 X-Yandex-Spam: 1 X-Yandex-Front: smtp12.yandex.ru Subject: 9.0-CURRENT - panic on detaching USB flash (not mounted) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 14:23:38 -0000 Hi, All. My system is fresh CURRENT: FreeBSD btr.properlan.net 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r197070: Thu Sep 10 21:40:35 MSD 2009 butcher@btr.properlan.net:/usr/obj/usr/src/sys/GENERIC amd64 I successful unmount my USB flash and got fatal trap when i removed it. This portion from dmesg: --- syscall (10, FreeBSD ELF64, unlink), rip = 0x8007316fc, rsp = 0x7fffffffe218, rbp = 0x800803d28 --- lock order reversal: 1st 0xffffff0005a609d0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1200 2nd 0xffffff00059d0270 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1345 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xcf3 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 ffs_sync() at ffs_sync+0x2d7 dounmount() at dounmount+0x2ca unmount() at unmount+0x27e syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (22, FreeBSD ELF64, unmount), rip = 0x8006a09dc, rsp = 0x7fffffffe308, rbp = 0 --- ugen3.2: at usbus3 (disconnected) uhub8: at uhub3, port 3, addr 2 (disconnected) ugen3.3: at usbus3 (disconnected) Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff804c3b10 stack pointer = 0x28:0xffffff80752399a0 frame pointer = 0x28:0xffffff80752399c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 14 (usbus3) panic: from debugger cpuid = 0 Uptime: 21m50s Physical memory: 4077 MB This from kgdb: #0 doadump () at pcpu.h:223 #1 0xffffffff805826a3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff80582b2c in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xffffffff801d9057 in db_panic (addr=) at /usr/src/sys/ddb/db_command.c:478 #4 0xffffffff801d9501 in db_command (last_cmdp=0xffffffff80be9aa0, cmd_table= ) at /usr/src/sys/ddb/db_command.c:445 #5 0xffffffff801d9750 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0xffffffff801db719 in db_trap (type=) at /usr/src/sys/ddb/db_main.c:229 #7 0xffffffff805b2295 in kdb_trap (type=9, code=0, tf=0xffffff80752398f0) at /usr/src/sys/kern/subr_kdb.c:535 #8 0xffffffff80866afd in trap_fatal (frame=0xffffff80752398f0, eva=) at /usr/src/sys/amd64/amd64/trap.c:847 #9 0xffffffff808675a6 in trap (frame=0xffffff80752398f0) at /usr/src/sys/amd64/amd64/trap.c:639 #10 0xffffffff8084d253 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #11 0xffffffff804c3b10 in usbd_transfer_stop (xfer=0xffffff8000e6aa90) at /usr/src/sys/dev/usb/usb_transfer.c:1694 #12 0xffffffff804c4547 in usbd_transfer_drain (xfer=0xffffff8000e6aa90) at /usr/src/sys/dev/usb/usb_transfer.c:1786 #13 0xffffffff804c5065 in usbd_transfer_unsetup (pxfer=0xffffff0003a214b8, n_setup=) at /usr/src/sys/dev/usb/usb_transfer.c:1166 #14 0xffffffff804aadc7 in umass_detach (dev=) at /usr/src/sys/dev/usb/storage/umass.c:1662 #15 0xffffffff805ac29b in device_detach (dev=0xffffff0003a18400) at device_if.h:212 #16 0xffffffff805ac4e1 in device_delete_child (dev=0xffffff0003a18600, child=0xffffff0003a18400) at /usr/src/sys/kern/subr_bus.c:1820 #17 0xffffffff805ac4c4 in device_delete_child (dev=0xffffff000391ec00, child=0xffffff0003a18600) at /usr/src/sys/kern/subr_bus.c:1815 #18 0xffffffff804b6f88 in usb_unconfigure (udev=0xffffff00039a6000, flag=) at /usr/src/sys/dev/usb/usb_device.c:1022 #19 0xffffffff804b72cd in usb_free_device (udev=0xffffff00039a6000, flag=) at /usr/src/sys/dev/usb/usb_device.c:1985 #20 0xffffffff804bea38 in uhub_explore (udev=0xffffff0003974000) at /usr/src/sys/dev/usb/usb_hub.c:322 #21 0xffffffff804aab41 in usb_bus_explore (pm=) at /usr/src/sys/dev/usb/controller/usb_controller.c:239 #22 0xffffffff804c1290 in usb_process (arg=) at /usr/src/sys/dev/usb/usb_process.c:164 #23 0xffffffff8055a92a in fork_exit ( callout=0xffffffff804c11d0 , arg=0xffffff80002f0d68, frame=0xffffff8075239c80) at /usr/src/sys/kern/kern_fork.c:843 #24 0xffffffff8084d72e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:561 #25 0x0000000000000000 in ?? () -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 14:26:54 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E47CF1065670 for ; Fri, 11 Sep 2009 14:26:54 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 7EEF88FC1A for ; Fri, 11 Sep 2009 14:26:54 +0000 (UTC) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id n8BEQqIk022365; Fri, 11 Sep 2009 15:26:52 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Mm75P-0001a0-W1; Fri, 11 Sep 2009 15:26:51 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n8BEQpTL046491; Fri, 11 Sep 2009 15:26:51 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n8BEQp9i046490; Fri, 11 Sep 2009 15:26:51 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Andriy Gapon In-Reply-To: <4AAA54FF.9080701@icyb.net.ua> References: <4AAA54FF.9080701@icyb.net.ua> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 11 Sep 2009 15:26:51 +0100 Message-Id: <1252679211.31066.43.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: crashinfo issue in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 14:26:55 -0000 On Fri, 2009-09-11 at 16:47 +0300, Andriy Gapon wrote: > I had a panic (provoked via sw watchdog, nothing exciting) and after reboot I > noticed that couple of processes dumped core, apparently while running as part of > crashinfo procedure. > > savecore: reboot after panic: watchdog timeout > savecore: writing core to vmcore.0 > kernel: pid 725 (ps), uid 0: exited on signal 11 (core dumped) > kernel: pid 742 (fstat), uid 0: exited on signal 11 > > core.0.txt accordingly has: > ------------------------------------------------------------------------ > ps -axl > Segmentation fault (core dumped) You need at least r196990 (which has not yet been MFC'd) and http://people.freebsd.org/~gavin/PRs/137890.2.diff . Hopefully both of these will appear in 8.x. > ------------------------------------------------------------------------ > fstat > Segmentation fault > ------------------------------------------------------------------------ I suspect this will be also fixed by the above patches. Gavin From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 14:41:39 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CF3D106568B; Fri, 11 Sep 2009 14:41:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4AE8FC12; Fri, 11 Sep 2009 14:41:37 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA16762; Fri, 11 Sep 2009 17:41:36 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4AAA61A0.2040600@icyb.net.ua> Date: Fri, 11 Sep 2009 17:41:36 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: Gavin Atkinson References: <4AAA54FF.9080701@icyb.net.ua> <1252679211.31066.43.camel@buffy.york.ac.uk> In-Reply-To: <1252679211.31066.43.camel@buffy.york.ac.uk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: crashinfo issue in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 14:41:39 -0000 on 11/09/2009 17:26 Gavin Atkinson said the following: > On Fri, 2009-09-11 at 16:47 +0300, Andriy Gapon wrote: >> I had a panic (provoked via sw watchdog, nothing exciting) and after reboot I >> noticed that couple of processes dumped core, apparently while running as part of >> crashinfo procedure. >> >> savecore: reboot after panic: watchdog timeout >> savecore: writing core to vmcore.0 >> kernel: pid 725 (ps), uid 0: exited on signal 11 (core dumped) >> kernel: pid 742 (fstat), uid 0: exited on signal 11 >> >> core.0.txt accordingly has: >> ------------------------------------------------------------------------ >> ps -axl >> Segmentation fault (core dumped) > > You need at least r196990 (which has not yet been MFC'd) and > http://people.freebsd.org/~gavin/PRs/137890.2.diff . Hopefully both of > these will appear in 8.x. I mentioned HEAD in the subject, but didn't say specifically that this is very recent HEAD - r197046. And amd64. Sorry for withholding such important details. So that patch is not in HEAD yet? I will try it then, thanks! >> ------------------------------------------------------------------------ >> fstat >> Segmentation fault >> ------------------------------------------------------------------------ > > I suspect this will be also fixed by the above patches. > > Gavin -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 15:00:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6651A106568F for ; Fri, 11 Sep 2009 15:00:29 +0000 (UTC) (envelope-from jfb@mr-paradox.net) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [IPv6:2001:470:b:28:f::1]) by mx1.freebsd.org (Postfix) with ESMTP id 50C8A8FC15 for ; Fri, 11 Sep 2009 15:00:29 +0000 (UTC) Received: by vexbert.mr-paradox.net (Postfix, from userid 16139) id 176C584562; Fri, 11 Sep 2009 11:00:29 -0400 (EDT) Date: Fri, 11 Sep 2009 11:00:27 -0400 From: Jeff Blank To: freebsd-current@freebsd.org Message-ID: <20090911150027.GA4187@mr-happy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e Subject: 8.0-BETA4 LOR vfs(syncer)/zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 15:00:29 -0000 this didn't seem to cause me any problems, but I thought I'd mention it anyway, since I didn't find anything that looked similar in the list archives, at the sources.zabbadoz.net LOR list, or with a quick google. happened with 8.0-BETA4/amd64 from around 0200 UTC Sep 10, GENERIC kernel. Jeff lock order reversal: 1st 0xffffff0005feb620 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:1693 2nd 0xffffff014651f270 zfs (zfs) @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:152 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xcf3 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 zfs_znode_cache_constructor() at zfs_znode_cache_constructor+0x4e zfs_znode_alloc() at zfs_znode_alloc+0x39 zfs_zget() at zfs_zget+0x25d zfs_get_data() at zfs_get_data+0x4d zil_commit() at zil_commit+0x532 zfs_sync() at zfs_sync+0xa6 sync_fsync() at sync_fsync+0x13a sync_vnode() at sync_vnode+0x157 sched_sync() at sched_sync+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff82531dfd30, rbp = 0 --- From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 15:20:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C74561065672 for ; Fri, 11 Sep 2009 15:20:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 932128FC28 for ; Fri, 11 Sep 2009 15:20:02 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4379E46B03; Fri, 11 Sep 2009 11:20:02 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 849858A020; Fri, 11 Sep 2009 11:20:01 -0400 (EDT) From: John Baldwin To: Nick Hilliard Date: Fri, 11 Sep 2009 11:19:04 -0400 User-Agent: KMail/1.9.7 References: <4A9BF23F.6070801@netability.ie> <200909081325.13149.jhb@freebsd.org> <4AAA3744.5020604@netability.ie> In-Reply-To: <4AAA3744.5020604@netability.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909111119.04511.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 11 Sep 2009 11:20:01 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 15:20:02 -0000 On Friday 11 September 2009 7:40:52 am Nick Hilliard wrote: > On 08/09/2009 18:25, John Baldwin wrote: > > So as with the other pciconf output I got, it seems that it is reading the > > registers ok in both cases. Can you add some printfs to the ata driver to > > figure out when it starts behaving differently (e.g. reading a value from a > > register) between the mcfg=0 and mcfg=1 cases on 8? > > oh my, this is causing sadness. > > I've installed 8.0 on a usb key and am running into the mountroot problem > that others are seeing: Hmm, I figured you could just install 8.0 onto the system with mcfg disabled and set mcfg=1 when booting a test kernel so you didn't have to go the full-blown USB key route. > You'll have to excuse me but my ata driver clue is epsilon away from zero. > If you can tell me what sort of stuff to put where, I can build a kernel > with local mods and report on what it's doing. But being inventive with > this is beyond my understanding of what's going on in the pcie subsystem. > Sorry :-( Ah, I would probably start with adding printfs to the various routines in sys/dev/ata/chipsets/ata-nvidia.c. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 15:26:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92C7B1065694 for ; Fri, 11 Sep 2009 15:26:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4D23E8FC12 for ; Fri, 11 Sep 2009 15:26:25 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D723346B23; Fri, 11 Sep 2009 11:26:24 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 0225A8A01B; Fri, 11 Sep 2009 11:26:24 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 11 Sep 2009 11:22:59 -0400 User-Agent: KMail/1.9.7 References: <4A93BF0C.8040601@web.de> <20090910174640.GA30706@triton8.kn-bremen.de> <20090910190800.GA14191@onelab2.iet.unipi.it> In-Reply-To: <20090910190800.GA14191@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909111123.00257.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 11 Sep 2009 11:26:24 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Juergen Lock , Avi Kivity , qemu-devel@nongnu.org, Jan Kiszka , Mohammed Gamal , Luigi Rizzo Subject: Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 15:26:25 -0000 On Thursday 10 September 2009 3:08:00 pm Luigi Rizzo wrote: > On Thu, Sep 10, 2009 at 07:46:40PM +0200, Juergen Lock wrote: > > On Wed, Sep 09, 2009 at 10:46:16PM +0200, Luigi Rizzo wrote: > > > On Mon, Sep 07, 2009 at 10:59:55PM +0200, Juergen Lock wrote: > > > > [I'm copying freebsd-current@FreeBSD.org because ppl there might know > > > > more about this...] > > > > > > > > qemu on FreeBSD hosts used to be able to run a (FreeBSD at least) guest > > > > with the same HZ as the host (like, 1000) with (mostly) proper timing > > > > once, but no longer. :( It seems there are two problems involved: > > > > > > > > a) use of apic seems to cause the clock irq rate to be doubled to 2 * HZ > > > > (can anyone explain why?), i.e. a FreeBSD 7 guest on a FreeBSD 7 host > > > > only gets proper timing after setting hint.apic.0.disabled=1 via the > > > > loader. (as can be verified by `vmstat -i' and `time sleep 2' in an > > > > installed guest or via the fixit->cdrom/dvd shell on a FreeBSD livefs > > > > or dvd1 iso.) > > > > > > > > b) qemu running on FreeBSD 8 hosts (and most likely head) has the > > > > additional problem of running its timers only at HZ/2 when using > > > > setitimer(2) (called `-clock unix' in qemu), as seen below. (as also > > > > > > this problem in 8.x is caused by the bug i described here yesterday: > > > > > > http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html > > > > > > In qeumu, the setitimer call (in file vl.c) has a timeout of 1 tick > > > which maps to callout_reset(..., 1, ...) and because (due to the bug) > > > 8.x processes callouts 1 tick late, this effectively halves the clock rate. > > > > > Thanx for the pointer! > > > > The proposed patch in that post didn't make a different here tho, > > guest still sees only half host HZ clock irq rate. (i.e. ~500 Hz.) > > > > Here is the patch I used, to make sure I patched what you meant... > > > > Index: sys/kern/kern_timeout.c > > @@ -323,7 +323,7 @@ softclock(void *arg) > > steps = 0; > > cc = (struct callout_cpu *)arg; > > CC_LOCK(cc); > > - while (cc->cc_softticks != ticks) { > > + while (cc->cc_softticks-1 != ticks) { > > /* > > * cc_softticks may be modified by hard clock, so cache > > * it while we work on a given bucket. > > > > as mentioned in the followup message in that thread, > you also need this change in callout_tick() > > mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET); > - for (; (cc->cc_softticks - ticks) < 0; cc->cc_softticks++) { > + for (; (cc->cc_softticks - ticks) <= 0; cc->cc_softticks++) { > bucket = cc->cc_softticks & callwheelmask; I would fix the style in the first hunk (spaces around '-') but I think you should commit this and get it into 8.0. I think a per-CPU ticks might prove very problematic as 'ticks' is rather widely used (though I would find that cleaner perhaps). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 15:26:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D42111065672; Fri, 11 Sep 2009 15:26:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A6A708FC08; Fri, 11 Sep 2009 15:26:26 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 583B446B03; Fri, 11 Sep 2009 11:26:26 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 8DD8B8A01F; Fri, 11 Sep 2009 11:26:25 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 11 Sep 2009 11:26:12 -0400 User-Agent: KMail/1.9.7 References: <4AAA54FF.9080701@icyb.net.ua> <1252679211.31066.43.camel@buffy.york.ac.uk> In-Reply-To: <1252679211.31066.43.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909111126.13209.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 11 Sep 2009 11:26:25 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Gavin Atkinson , Andriy Gapon Subject: Re: crashinfo issue in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 15:26:26 -0000 On Friday 11 September 2009 10:26:51 am Gavin Atkinson wrote: > On Fri, 2009-09-11 at 16:47 +0300, Andriy Gapon wrote: > > I had a panic (provoked via sw watchdog, nothing exciting) and after reboot I > > noticed that couple of processes dumped core, apparently while running as part of > > crashinfo procedure. > > > > savecore: reboot after panic: watchdog timeout > > savecore: writing core to vmcore.0 > > kernel: pid 725 (ps), uid 0: exited on signal 11 (core dumped) > > kernel: pid 742 (fstat), uid 0: exited on signal 11 > > > > core.0.txt accordingly has: > > ------------------------------------------------------------------------ > > ps -axl > > Segmentation fault (core dumped) > > You need at least r196990 (which has not yet been MFC'd) and > http://people.freebsd.org/~gavin/PRs/137890.2.diff . Hopefully both of > these will appear in 8.x. I think that patch looks ok to go in FWIW. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 15:33:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A49A8106566C; Fri, 11 Sep 2009 15:33:44 +0000 (UTC) (envelope-from nick-lists@netability.ie) Received: from mail.acquirer.com (mail.acquirer.com [87.198.142.193]) by mx1.freebsd.org (Postfix) with ESMTP id 29A6D8FC1D; Fri, 11 Sep 2009 15:33:43 +0000 (UTC) X-Envelope-To: freebsd-current@freebsd.org Received: from cupcake.internal.acquirer.com (cupcake.internal.acquirer.com [10.228.100.105]) (authenticated bits=0) by mail.acquirer.com (8.14.3/8.14.3) with ESMTP id n8BFXdFF033501 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 11 Sep 2009 16:33:39 +0100 (IST) (envelope-from nick-lists@netability.ie) Message-ID: <4AAA6DD3.7030902@netability.ie> Date: Fri, 11 Sep 2009 16:33:39 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: John Baldwin References: <4A9BF23F.6070801@netability.ie> <200909081325.13149.jhb@freebsd.org> <4AAA3744.5020604@netability.ie> <200909111119.04511.jhb@freebsd.org> In-Reply-To: <200909111119.04511.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, TW_CF autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muffin.acquirer.com Cc: freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 15:33:44 -0000 On 11/09/2009 16:19, John Baldwin wrote: > Hmm, I figured you could just install 8.0 onto the system with mcfg disabled > and set mcfg=1 when booting a test kernel so you didn't have to go the > full-blown USB key route. I don't have a spare disk handy for that - i use the machine for backups, so it's used at night mostly. > Ah, I would probably start with adding printfs to the various routines in > sys/dev/ata/chipsets/ata-nvidia.c. John - seriously, you're not hearing me. I don't know squat about what to look for here. I need instructions at the level of "print out variable X at line Y in file Z and reboot with configuration W in loader.conf. Really. I'm not trying to be unhelpful or dumbass or anything; it's just that any freebsd-fu I might have is right at the far end of the call stack to this. If you want, I can give you login access to the box. Nick From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 15:45:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52784106568B for ; Fri, 11 Sep 2009 15:45:06 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swipnet.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id D748E8FC21 for ; Fri, 11 Sep 2009 15:45:05 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=BjuGxOfPqQgA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=-o81O83pAAAA:8 a=6I5d2MoRAAAA:8 a=deaKlm17i6czcWyFV3AA:9 a=p6VA8ri13zjpyC12HScA:7 a=qX-Hg7h93VoDfbyUDFlNCihUr-AA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1134908799; Fri, 11 Sep 2009 17:45:03 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 11 Sep 2009 17:45:28 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <4AAA5D61.6020900@yandex.ru> In-Reply-To: <4AAA5D61.6020900@yandex.ru> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909111745.29780.hselasky@c2i.net> Cc: "Andrey V. Elsukov" Subject: Re: 9.0-CURRENT - panic on detaching USB flash (not mounted) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 15:45:06 -0000 On Friday 11 September 2009 16:23:29 Andrey V. Elsukov wrote: > Hi, All. > > > My system is fresh CURRENT: > FreeBSD btr.properlan.net 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r197070: > Thu Sep 10 21:40:35 MSD 2009 > butcher@btr.properlan.net:/usr/obj/usr/src/sys/GENERIC amd64 > > I successful unmount my USB flash and got fatal trap when i removed it. > > This portion from dmesg: Known issue: http://perforce.freebsd.org/chv.cgi?CH=168387 Download files using download link and build new kernel. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 15:50:03 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4736B1065670; Fri, 11 Sep 2009 15:50:03 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id DC98B8FC12; Fri, 11 Sep 2009 15:50:02 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id AC82A1CC94; Fri, 11 Sep 2009 17:50:01 +0200 (CEST) Date: Fri, 11 Sep 2009 17:50:01 +0200 From: Ed Schouten To: ddk ddk Message-ID: <20090911155001.GU2829@hoeg.nl> References: <4AA9F5E4.6020305@icyb.net.ua> <85911.11390.qm@web59108.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="to1uSGBmQtEag2WO" Content-Disposition: inline In-Reply-To: <85911.11390.qm@web59108.mail.re1.yahoo.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: swell.k@gmail.com, freebsd-current@FreeBSD.org, delphij@FreeBSD.ORG Subject: Re: vesa(4) and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 15:50:03 -0000 --to1uSGBmQtEag2WO Content-Type: multipart/mixed; boundary="jl/VStiZFoZxPJyo" Content-Disposition: inline --jl/VStiZFoZxPJyo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * ddk ddk wrote: > I think this is a problem that has added a new terminal > teken by ed@ > =20 > becouse there is no problem on freebsd 7 where is no teken > where I can switch to any low mode=20 Hmmm... As far as I know, syscons reinitializes the terminal completely when switching resolutions. Does it crash? If so, are you capable of obtainining a backtrace? In my newcons branch I do have a very small patch for libteken that changes the resizing behaviour. In my new vt console driver I do resize the terminal emulator without reinitializing it completely, so I had to make set_winsize() a bit more robust. I think it's very unlikely that this patch fixes the issue you are seeing, but please do try. --=20 Ed Schouten WWW: http://80386.nl/ --jl/VStiZFoZxPJyo Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="teken.diff" Content-Transfer-Encoding: quoted-printable Index: sys/teken/teken.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/teken/teken.c (revision 197020) +++ sys/teken/teken.c (working copy) @@ -341,10 +341,7 @@ { =20 t->t_winsize =3D *p; - /* XXX: bounds checking with cursor/etc! */ - t->t_scrollreg.ts_begin =3D 0; - t->t_scrollreg.ts_end =3D t->t_winsize.tp_row; - t->t_originreg =3D t->t_scrollreg; + teken_subr_do_reset(t); } =20 /* Index: sys/teken/teken_subr.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/teken/teken_subr.h (revision 197020) +++ sys/teken/teken_subr.h (working copy) @@ -927,6 +927,9 @@ =20 t->t_curattr =3D t->t_defattr; t->t_cursor.tp_row =3D t->t_cursor.tp_col =3D 0; + t->t_scrollreg.ts_begin =3D 0; + t->t_scrollreg.ts_end =3D t->t_winsize.tp_row; + t->t_originreg =3D t->t_scrollreg; t->t_stateflags =3D TS_AUTOWRAP; =20 teken_scs_set(t, 0, teken_scs_us_ascii); --jl/VStiZFoZxPJyo-- --to1uSGBmQtEag2WO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkqqcakACgkQ52SDGA2eCwVh5wCfSV1IHXcZKBgTx3C3OiMIkXdn Dn0AnAu6rJlRmlnP27TkYDwRG62VX7yQ =IIsd -----END PGP SIGNATURE----- --to1uSGBmQtEag2WO-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 16:04:12 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E2DF1065670 for ; Fri, 11 Sep 2009 16:04:12 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id C06668FC08 for ; Fri, 11 Sep 2009 16:04:11 +0000 (UTC) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id n8BG488o010158; Fri, 11 Sep 2009 17:04:08 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Mm8bY-0002Kw-RB; Fri, 11 Sep 2009 17:04:08 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n8BG48tB053211; Fri, 11 Sep 2009 17:04:08 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n8BG48Sr053210; Fri, 11 Sep 2009 17:04:08 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Andriy Gapon In-Reply-To: <4AAA61A0.2040600@icyb.net.ua> References: <4AAA54FF.9080701@icyb.net.ua> <1252679211.31066.43.camel@buffy.york.ac.uk> <4AAA61A0.2040600@icyb.net.ua> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 11 Sep 2009 17:04:08 +0100 Message-Id: <1252685048.31066.55.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: crashinfo issue in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 16:04:12 -0000 On Fri, 2009-09-11 at 17:41 +0300, Andriy Gapon wrote: > on 11/09/2009 17:26 Gavin Atkinson said the following: > > On Fri, 2009-09-11 at 16:47 +0300, Andriy Gapon wrote: > >> I had a panic (provoked via sw watchdog, nothing exciting) and after reboot I > >> noticed that couple of processes dumped core, apparently while running as part of > >> crashinfo procedure. > >> > >> savecore: reboot after panic: watchdog timeout > >> savecore: writing core to vmcore.0 > >> kernel: pid 725 (ps), uid 0: exited on signal 11 (core dumped) > >> kernel: pid 742 (fstat), uid 0: exited on signal 11 > >> > >> core.0.txt accordingly has: > >> ------------------------------------------------------------------------ > >> ps -axl > >> Segmentation fault (core dumped) > > > > You need at least r196990 (which has not yet been MFC'd) and > > http://people.freebsd.org/~gavin/PRs/137890.2.diff . Hopefully both of > > these will appear in 8.x. > > I mentioned HEAD in the subject, but didn't say specifically that this is very > recent HEAD - r197046. And amd64. Sorry for withholding such important details. > So that patch is not in HEAD yet? I will try it then, thanks! Hmm, in that case this is probably a different bug to the ones already found, and that patch won't help. Can you recompile ps and libkvm with debugging symbols, run it under gdb and get a backtrace? Your original stack trace shows kvm_getprocs() calling _kvm_freeprocs(), however the code doesn't appear to ever do this: indeed, nothing in libkvm calls _kvm_freeprocs() directly. Gavin From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 16:05:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EEC6106568B for ; Fri, 11 Sep 2009 16:05:53 +0000 (UTC) (envelope-from roberthuff@rcn.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 03EB28FC12 for ; Fri, 11 Sep 2009 16:05:52 +0000 (UTC) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 11 Sep 2009 12:05:52 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.10.7-GA) with ESMTP id QEC70098; Fri, 11 Sep 2009 12:05:50 -0400 (EDT) Received: from 209-6-22-227.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.22.227]) by smtp01.lnh.mail.rcn.net with ESMTP; 11 Sep 2009 12:05:51 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19114.30046.373632.669034@jerusalem.litteratus.org> Date: Fri, 11 Sep 2009 12:05:50 -0400 To: current@freebsd.org X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) Cc: Subject: custom kernel freezes when using KVM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 16:05:53 -0000 1) About two weeks ago I installed 8.0beta3/amd64 on new hardware. Except for one problem, now solved, everything went smoothly and I was a happy camper. 2) Several days later I hooked it up to a (USB-) KVM; I also connected a Windows XP box and was able to switch back and forth between them with no problems. 3) Three days ago, I updated the system source and did the per-handbook system upgrade using the appended kernel config file. 4) Since then, using the KVM - whether or not the Windows machine is running - causes the FreeBSD box to freeze hard (requires hardware reset). While I have updated installed ports (list available on request), it seems reasonable to believe this is a OS failure and the new kernel is responsible. Is there anything I left out, or put in, that would cause this breakage? Has snyone seen this kind of thing before? Respectfully, Robert Huff # # JERUSALEM -- kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.531.2.2 2009/08/13 17:54:11 attilio Exp $ cpu HAMMER ident JERUSALEM # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. # Use the following to compile in values accessible to the kernel # through getenv() (or kenv(1) in userland). The format of the file # is 'variable=value', see kenv(1) # # env "GENERIC.env" makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options GEOM_PART_BSD options GEOM_PART_EBR options GEOM_PART_EBR_COMPAT options GEOM_PART_MBR options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=1000 # Delay (in ms) before probing SCSI options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache # options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPFIREWALL_NAT #ipfw kernel nat support options LIBALIAS # required for NAT # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci device drm # DRM core module required by DRM drivers device radeondrm # ATI Radeon # Floppy drives # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers # output. Adds ~128k to driver. # output. Adds ~215k to driver. # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #XXX it is not 64-bit clean, -scottl # RAID controllers #XXX pointer/int warnings # atkbdc0 controls both the keyboard and the PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support # Serial (COM) ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): # PCI Ethernet NICs. # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support # ISA Ethernet NICs. pccard NICs included. # 'device ed' requires 'device miibus' # Wireless NIC cards # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # USB Serial devices device uark # Technologies ARK3116 based serial adapters device ubsa # Belkin F5U103 and compatible serial adapters device uftdi # For FTDI usb serial adapters device uipaq # Some WinCE based devices device uplcom # Prolific PL-2303 serial adapters device uslcom # SI Labs CP2101/CP2102 serial adapters device uvisor # Visor and Palm devices device uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus # FireWire support From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 16:40:02 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C998106566B; Fri, 11 Sep 2009 16:40:02 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1C5228FC13; Fri, 11 Sep 2009 16:39:59 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA17934; Fri, 11 Sep 2009 19:39:58 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4AAA7D5E.5050604@icyb.net.ua> Date: Fri, 11 Sep 2009 19:39:58 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: Gavin Atkinson References: <4AAA54FF.9080701@icyb.net.ua> <1252679211.31066.43.camel@buffy.york.ac.uk> <4AAA61A0.2040600@icyb.net.ua> <1252685048.31066.55.camel@buffy.york.ac.uk> In-Reply-To: <1252685048.31066.55.camel@buffy.york.ac.uk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: crashinfo issue in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 16:40:02 -0000 on 11/09/2009 19:04 Gavin Atkinson said the following: > > Hmm, in that case this is probably a different bug to the ones already > found, and that patch won't help. Can you recompile ps and libkvm with > debugging symbols, run it under gdb and get a backtrace? Your original > stack trace shows kvm_getprocs() calling _kvm_freeprocs(), however the > code doesn't appear to ever do this: indeed, nothing in libkvm calls > _kvm_freeprocs() directly. I tried debugging this and figured out that I am stupid - my world is at older revision than my kernel and it is couple revisions before r196990 that fixed the problem. So, sorry for the noise and big thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 16:57:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71CF1106568D; Fri, 11 Sep 2009 16:57:17 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 32F018FC0C; Fri, 11 Sep 2009 16:57:16 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9C7FD730DA; Fri, 11 Sep 2009 19:03:17 +0200 (CEST) Date: Fri, 11 Sep 2009 19:03:17 +0200 From: Luigi Rizzo To: John Baldwin Message-ID: <20090911170317.GA33232@onelab2.iet.unipi.it> References: <4A93BF0C.8040601@web.de> <20090910174640.GA30706@triton8.kn-bremen.de> <20090910190800.GA14191@onelab2.iet.unipi.it> <200909111123.00257.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200909111123.00257.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Juergen Lock , Avi Kivity , qemu-devel@nongnu.org, freebsd-current@freebsd.org, Jan Kiszka , Mohammed Gamal Subject: Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 16:57:17 -0000 On Fri, Sep 11, 2009 at 11:22:59AM -0400, John Baldwin wrote: > On Thursday 10 September 2009 3:08:00 pm Luigi Rizzo wrote: ... > > > Index: sys/kern/kern_timeout.c > > > @@ -323,7 +323,7 @@ softclock(void *arg) > > > steps = 0; > > > cc = (struct callout_cpu *)arg; > > > CC_LOCK(cc); > > > - while (cc->cc_softticks != ticks) { > > > + while (cc->cc_softticks-1 != ticks) { > > > /* > > > * cc_softticks may be modified by hard clock, so cache > > > * it while we work on a given bucket. > > > > > > > as mentioned in the followup message in that thread, > > you also need this change in callout_tick() > > > > mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET); > > - for (; (cc->cc_softticks - ticks) < 0; cc->cc_softticks++) { > > + for (; (cc->cc_softticks - ticks) <= 0; cc->cc_softticks++) { > > bucket = cc->cc_softticks & callwheelmask; > > I would fix the style in the first hunk (spaces around '-') but I think you > should commit this and get it into 8.0. I think a per-CPU ticks might prove > very problematic as 'ticks' is rather widely used (though I would find that > cleaner perhaps). i will ask permission to re -- i was hoping to get some feedback on the thread on -current but no response so far :( Note that the per-cpu ticks i was proposing were only visible to the timing wheels, which don't use absolute timeouts anyways. So i think the mechanism would be quite safe: right now, when you request a callout after x ticks, the code first picks a CPU (with some criteria), then puts the request in the timer wheel for that CPU using (now) the global 'ticks'. Replacing ticks with cc->cc_ticks, would completely remove the races in insertion and removal. I actually find the per-cpu ticks even less intrusive than this change. cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 17:25:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC1F91065693 for ; Fri, 11 Sep 2009 17:25:29 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id 346768FC0A for ; Fri, 11 Sep 2009 17:25:28 +0000 (UTC) Received: from lux.student.utwente.nl (lux.student.utwente.nl [130.89.170.81]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id n8BHOCJD031972 for ; Fri, 11 Sep 2009 19:24:12 +0200 From: Pieter de Goeje To: freebsd-current@freebsd.org Date: Fri, 11 Sep 2009 19:24:10 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909111924.10927.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Subject: BETA3: network processes hang in keglimit (unkillable) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 17:25:29 -0000 I just experienced a complete loss of network, where every network related process would sleep on "keglimit". I was unable to recover from this situation. I tried killing the processes with SIGKILL, but it didn't work, and I tried to bring the network interface (em) down and up again, which also didn't work. A reboot "solved" the problem. The machine was handling some major traffic, both TCP and UDP. Apparently the system was waiting on some resource to free up, but what could it be? How can this situation be avoided in the future? uname: 8.0-BETA3 FreeBSD 8.0-BETA3 #1: Sun Aug 30 01:23:36 CEST 2009 amd64 -- Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 17:32:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F8D5106566C for ; Fri, 11 Sep 2009 17:32:43 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward13.yandex.ru (forward13.yandex.ru [95.108.130.120]) by mx1.freebsd.org (Postfix) with ESMTP id 15A378FC0A for ; Fri, 11 Sep 2009 17:32:42 +0000 (UTC) Received: from smtp13.yandex.ru (smtp13.yandex.ru [95.108.130.68]) by forward13.yandex.ru (Yandex) with ESMTP id 516CAA781C3; Fri, 11 Sep 2009 21:32:41 +0400 (MSD) Received: from btr.properlan.net (vpn.heavennet.ru [77.72.136.194]) by smtp13.yandex.ru (Yandex) with ESMTPSA id 247AF322002F; Fri, 11 Sep 2009 21:32:41 +0400 (MSD) Message-ID: <4AAA89B1.7050802@yandex.ru> Date: Fri, 11 Sep 2009 21:32:33 +0400 From: "Andrey V. Elsukov" User-Agent: Thunderbird 2.0.0.22 (X11/20090821) MIME-Version: 1.0 To: Hans Petter Selasky References: <4AAA5D61.6020900@yandex.ru> <200909111745.29780.hselasky@c2i.net> In-Reply-To: <200909111745.29780.hselasky@c2i.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1252690361 X-Yandex-Spam: 1 X-Yandex-Front: smtp13.yandex.ru Cc: freebsd-current@freebsd.org Subject: Re: 9.0-CURRENT - panic on detaching USB flash (not mounted) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 17:32:43 -0000 Hans Petter Selasky wrote: > http://perforce.freebsd.org/chv.cgi?CH=168387 > > Download files using download link and build new kernel. Yes, it works with this patch. Thanks. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 17:38:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E3D71065670 for ; Fri, 11 Sep 2009 17:38:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by mx1.freebsd.org (Postfix) with ESMTP id 332018FC15 for ; Fri, 11 Sep 2009 17:38:50 +0000 (UTC) Received: by qyk33 with SMTP id 33so30294qyk.14 for ; Fri, 11 Sep 2009 10:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=fQjxKchYWyIpFUed+Fg2In71q3Th+HD2jvud0+MgQps=; b=ozTK2/8SHYW/hBvClCX/36xS3U78xcDuzHXMMVG9xPtvjwG5x9hJPRepwstX6bffh1 cuNujpCsXAEQDm+KFJkAxbNwIkan9ewoNd2Fke9OTsQwe2eE+SGiC6PIrCCJyQtTP5X7 00TVD0qooUYjfT16SIG/lV0kqsXBELKinydRM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=dQMOSOTvuld62DfjWGHDiTGjGW3cnY7g3+bGSBgHIr2OVc58H5FVuOSR03szSm66MF zdOn0P83t3ETieSmncezPvGIseDDzT6XWeOFISa9PUtxNqthLGjmZlegp4tdjsZX5DKl BPR51oGwURN1qDyZjUkaTZl/++jLsH1y3vSMk= Received: by 10.224.112.10 with SMTP id u10mr2753745qap.169.1252690730308; Fri, 11 Sep 2009 10:38:50 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 8sm128474qwj.18.2009.09.11.10.38.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 11 Sep 2009 10:38:49 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 11 Sep 2009 10:37:56 -0700 From: Pyun YongHyeon Date: Fri, 11 Sep 2009 10:37:56 -0700 To: Pieter de Goeje Message-ID: <20090911173756.GA1100@michelle.cdnetworks.com> References: <200909111924.10927.pieter@degoeje.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200909111924.10927.pieter@degoeje.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: BETA3: network processes hang in keglimit (unkillable) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 17:38:51 -0000 On Fri, Sep 11, 2009 at 07:24:10PM +0200, Pieter de Goeje wrote: > I just experienced a complete loss of network, where every network related > process would sleep on "keglimit". I was unable to recover from this > situation. I tried killing the processes with SIGKILL, but it didn't work, > and I tried to bring the network interface (em) down and up again, which also > didn't work. A reboot "solved" the problem. The machine was handling some > major traffic, both TCP and UDP. > > Apparently the system was waiting on some resource to free up, but what could > it be? How can this situation be avoided in the future? > > uname: 8.0-BETA3 FreeBSD 8.0-BETA3 #1: Sun Aug 30 01:23:36 CEST 2009 amd64 > Both em(4) and igb(4) had mbuf leak bug which was recently fixed by Jack. Check mbuf statistics with "netstat -m" and see whether you've reached mbuf resource limit(see 4K jumbo cluster counter). The leak can be easily seen on UDP traffic, especially NFS over UDP. From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 18:01:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FDDB1065672; Fri, 11 Sep 2009 18:01:37 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 569068FC20; Fri, 11 Sep 2009 18:01:37 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n8BI1a59027881; Fri, 11 Sep 2009 11:01:36 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Sep 2009 11:00:42 -0700 Message-ID: In-Reply-To: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NFS issues on 8.0-BETA4 Thread-Index: Acoy9I+eM34VDLUKS7OxiLwkzzLohwAFJ0GA References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org> From: "Li, Qing" To: "Doug Poland" , Cc: FreeBSD Current Subject: RE: NFS issues on 8.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 18:01:37 -0000 >=20 > I cannot sucessfully mount exports from the NFSv3 server on the > 8.0-BETA4 client. All works well with 7.2 clients. >=20 > The strange thing is, the directory in which I mount the nfs > filesystem disappears, and I get an error when I attempt to access the > directory. >=20 This may be a known issue that a couple of us have been working on yesterday. Would you be willing to try out a=20 temporary patch? -- Qing From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 18:05:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B85C106566B; Fri, 11 Sep 2009 18:05:57 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from dhcp-172-16-23-229.lon.corp.google.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E0E1C8FC15; Fri, 11 Sep 2009 18:05:56 +0000 (UTC) Message-ID: <4AAA9187.2020907@FreeBSD.org> Date: Fri, 11 Sep 2009 19:05:59 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Pawel Jakub Dawidek , Kip Macy , FreeBSD Current References: <4AA40E30.50109@FreeBSD.org> In-Reply-To: <4AA40E30.50109@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: panic: sx_xlock() of destroyed sx @ /zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 18:05:57 -0000 Kris Kennaway wrote: > 9.0 doing I/O to a zfs: > > panic: sx_xlock() of destroyed sx @ > /zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535 > > db> wh > Tracing pid 14 tid 100047 td 0xffffff000357c720 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x17b > _sx_xlock() at _sx_xlock+0xe9 > zfs_range_unlock() at zfs_range_unlock+0x38 > zfs_get_data() at zfs_get_data+0xd7 > zil_commit() at zil_commit+0x532 > zfs_sync() at zfs_sync+0xa6 > sync_fsync() at sync_fsync+0x13a > VOP_FSYNC_APV() at VOP_FSYNC_APV+0xb7 > sync_vnode() at sync_vnode+0x157 > sched_sync() at sched_sync+0x1d1 > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8125da0d30, rbp = 0 --- > > This was essentially just doing make world + cvs update + tar creation > in a loop and failed after about a week. > > Kris > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > Any ideas? Machine is still in DDB. Kris From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 19:09:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB68A106566B for ; Fri, 11 Sep 2009 19:09:23 +0000 (UTC) (envelope-from doug@polands.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.124]) by mx1.freebsd.org (Postfix) with ESMTP id AA2338FC14 for ; Fri, 11 Sep 2009 19:09:23 +0000 (UTC) Received: from haran.polands.org ([75.87.219.217]) by hrndva-omta03.mail.rr.com with ESMTP id <20090911184517571.VOXC4372@hrndva-omta03.mail.rr.com>; Fri, 11 Sep 2009 18:45:17 +0000 Received: from email.polands.org (ammon.polands.org [172.16.1.7]) by haran.polands.org (8.14.3/8.14.3) with ESMTP id n8BIjGuR077851; Fri, 11 Sep 2009 13:45:16 -0500 (CDT) (envelope-from doug@polands.org) Received: from 209.103.215.99 (SquirrelMail authenticated user djp) by email.polands.org with HTTP; Fri, 11 Sep 2009 13:45:17 -0500 Message-ID: In-Reply-To: References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org> Date: Fri, 11 Sep 2009 13:45:17 -0500 From: "Doug Poland" To: "Li, Qing" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-stable@freebsd.org, FreeBSD Current Subject: RE: NFS issues on 8.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 19:09:24 -0000 On Fri, September 11, 2009 13:00, Li, Qing wrote: >> >> I cannot successfully mount exports from the NFSv3 server on the >> 8.0-BETA4 client. All works well with 7.2 clients. >> >> The strange thing is, the directory in which I mount the nfs >> filesystem disappears, and I get an error when I attempt to access >> the directory. >> > > This may be a known issue that a couple of us have been > working on yesterday. Would you be willing to try out a > temporary patch? > > -- Qing > I'd be happy to assist anyway I can. -- Regards, Doug From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 19:14:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C669106568B for ; Fri, 11 Sep 2009 19:14:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CDA438FC12 for ; Fri, 11 Sep 2009 19:14:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7C32146B2A; Fri, 11 Sep 2009 15:14:46 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id AE15D8A027; Fri, 11 Sep 2009 15:14:45 -0400 (EDT) From: John Baldwin To: Luigi Rizzo Date: Fri, 11 Sep 2009 13:01:54 -0400 User-Agent: KMail/1.9.7 References: <4A93BF0C.8040601@web.de> <200909111123.00257.jhb@freebsd.org> <20090911170317.GA33232@onelab2.iet.unipi.it> In-Reply-To: <20090911170317.GA33232@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909111301.55692.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 11 Sep 2009 15:14:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Juergen Lock , Avi Kivity , qemu-devel@nongnu.org, freebsd-current@freebsd.org, Jan Kiszka , Mohammed Gamal Subject: Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 19:14:47 -0000 On Friday 11 September 2009 1:03:17 pm Luigi Rizzo wrote: > On Fri, Sep 11, 2009 at 11:22:59AM -0400, John Baldwin wrote: > > On Thursday 10 September 2009 3:08:00 pm Luigi Rizzo wrote: > ... > > > > Index: sys/kern/kern_timeout.c > > > > @@ -323,7 +323,7 @@ softclock(void *arg) > > > > steps = 0; > > > > cc = (struct callout_cpu *)arg; > > > > CC_LOCK(cc); > > > > - while (cc->cc_softticks != ticks) { > > > > + while (cc->cc_softticks-1 != ticks) { > > > > /* > > > > * cc_softticks may be modified by hard clock, so cache > > > > * it while we work on a given bucket. > > > > > > > > > > as mentioned in the followup message in that thread, > > > you also need this change in callout_tick() > > > > > > mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET); > > > - for (; (cc->cc_softticks - ticks) < 0; cc->cc_softticks++) { > > > + for (; (cc->cc_softticks - ticks) <= 0; cc->cc_softticks++) { > > > bucket = cc->cc_softticks & callwheelmask; > > > > I would fix the style in the first hunk (spaces around '-') but I think you > > should commit this and get it into 8.0. I think a per-CPU ticks might prove > > very problematic as 'ticks' is rather widely used (though I would find that > > cleaner perhaps). > > i will ask permission to re -- i was hoping to get some feedback > on the thread on -current but no response so far :( > > Note that the per-cpu ticks i was proposing were only visible to the > timing wheels, which don't use absolute timeouts anyways. > So i think the mechanism would be quite safe: right now, when you > request a callout after x ticks, the code first picks a CPU > (with some criteria), then puts the request in the timer wheel for > that CPU using (now) the global 'ticks'. Replacing ticks with cc->cc_ticks, > would completely remove the races in insertion and removal. > > I actually find the per-cpu ticks even less intrusive than this change. Well, it depends. If TCP ever started using per-CPU callouts (i.e. callout_reset_on()) it would probably need to start using the per-CPU ticks instead of the global ticks, etc. You could have 'ticks' just be == to CPU 0's ticks perhaps. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 19:28:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D726106566C for ; Fri, 11 Sep 2009 19:28:24 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id 12B698FC17 for ; Fri, 11 Sep 2009 19:28:23 +0000 (UTC) Received: from lux.student.utwente.nl (lux.student.utwente.nl [130.89.170.81]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id n8BJSGJD019785; Fri, 11 Sep 2009 21:28:16 +0200 From: Pieter de Goeje To: freebsd-current@freebsd.org, pyunyh@gmail.com Date: Fri, 11 Sep 2009 21:28:15 +0200 User-Agent: KMail/1.9.10 References: <200909111924.10927.pieter@degoeje.nl> <20090911173756.GA1100@michelle.cdnetworks.com> In-Reply-To: <20090911173756.GA1100@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909112128.15645.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Subject: Re: BETA3: network processes hang in keglimit (unkillable) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 19:28:24 -0000 On Friday 11 September 2009, Pyun YongHyeon wrote: > On Fri, Sep 11, 2009 at 07:24:10PM +0200, Pieter de Goeje wrote: > > I just experienced a complete loss of network, where every network > > related process would sleep on "keglimit". I was unable to recover from > > this situation. I tried killing the processes with SIGKILL, but it didn't > > work, and I tried to bring the network interface (em) down and up again, > > which also didn't work. A reboot "solved" the problem. The machine was > > handling some major traffic, both TCP and UDP. > > > > Apparently the system was waiting on some resource to free up, but what > > could it be? How can this situation be avoided in the future? > > > > uname: 8.0-BETA3 FreeBSD 8.0-BETA3 #1: Sun Aug 30 01:23:36 CEST 2009 > > amd64 > > Both em(4) and igb(4) had mbuf leak bug which was recently fixed by > Jack. Check mbuf statistics with "netstat -m" and see whether > you've reached mbuf resource limit(see 4K jumbo cluster counter). > The leak can be easily seen on UDP traffic, especially NFS over UDP. Ok, that matches my usage (NFS over UDP), so I will monitor mbuf usage and test Jack's fixes when they're MFCed (or sooner if I can reproduce this). Thank you for your reply, Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 20:03:28 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADD30106568B for ; Fri, 11 Sep 2009 20:03:28 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 126128FC17 for ; Fri, 11 Sep 2009 20:03:27 +0000 (UTC) Received: by bwz2 with SMTP id 2so977718bwz.43 for ; Fri, 11 Sep 2009 13:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=lDCHb32TqgR+X8LxkNV9M6DnotuTU6ov6MuOsDmnDyg=; b=gSGwwYQIsErjEXyuKC94DJnHbK3fSMDwBCQQc3H4scYoMD3sOeWVKojz8R9bgcL7YG lSaWpwsRO6ysKqHAsOLv7HvQi723EzXUGQdZ/QnYt5jdDFTgmIol01/0LiKigjjjSJze JIACWOjnZRWU/boz36jmpoFAwJtsXOkIQCPWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=SrWuh1NaRatYl6Or7xv5KYy2CvQ/Mb0X1EngpCn5doYCtELuj0ysQa/8jVBIuzrIpl J8qsjs18iX7zPUv+bjn+7wmUglIq+/7D0a8LBJSRqHxOJJUBBlhELbSVs2dI+RbIR8zl cS1f6trdtlwIdGwvSg/Gp8Qya/ftRw0jlAAYU= MIME-Version: 1.0 Received: by 10.239.143.215 with SMTP id l23mr291387hba.163.1252699406623; Fri, 11 Sep 2009 13:03:26 -0700 (PDT) Date: Fri, 11 Sep 2009 20:03:26 +0000 Message-ID: From: "b. f." To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: delphij@FreeBSD.org Subject: Re: vesa(4) and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 20:03:28 -0000 After the recent x86emu/vesa/dpms commits, I'm now able to use some more graphics modes with syscons on amd64. That's good. Not so good is the fact that my HP Pavilion desktop running 9-CURRENT i386 r197085 with devic sc options SC_PIXEL_MODE device vga options VGA_WIDTH90 in the kernel and agp, dpms, x86emu, and vesa loaded as kernel modules can no longer use the 132x60 mode that had been my default syscons mode, and now yields a blank screen. Even worse is the fact that my Toshiba laptop, with nearly the same configuration, locks up with a screen full of zeroes every time I load the new vesa kernel module, when formerly it had no such problem. Other than simplifying the organization of the code, is there any advantage to be gained from forcing those platforms that are capable of native vesa to use x86emu? Because up to this point there are serious disadvantages to doing so. Regards, b. From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 20:32:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8444F1065672 for ; Fri, 11 Sep 2009 20:32:39 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 239298FC1C for ; Fri, 11 Sep 2009 20:32:38 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABdRqkqDaFvI/2dsb2JhbADdWoQYBYFU X-IronPort-AV: E=Sophos;i="4.44,372,1249272000"; d="scan'208";a="45973473" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 11 Sep 2009 16:32:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 18D5E9400A6; Fri, 11 Sep 2009 16:32:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeLkRbP3-ion; Fri, 11 Sep 2009 16:32:36 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id D1936940078; Fri, 11 Sep 2009 16:32:36 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n8BKboE10143; Fri, 11 Sep 2009 16:37:51 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 11 Sep 2009 16:37:50 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Doug Poland In-Reply-To: Message-ID: References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, FreeBSD Current Subject: RE: NFS issues on 8.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 20:32:39 -0000 >> >> I cannot sucessfully mount exports from the NFSv3 server on the >> 8.0-BETA4 client. All works well with 7.2 clients. >> >> The strange thing is, the directory in which I mount the nfs >> filesystem disappears, and I get an error when I attempt to access the >> directory. >> I went and looked at the message over in stable@ (I guess I have to join that mailing list, too:-). I think that the second mount attempt, which failed with errno==64 EHOSTDOWN probably gives you a better indication of what is broken and hints at a networking problem, which hopefully others can help with? mount_nfs currently has the quirk that, if you don't specify either "udp" or "tcp", it will use UDP for the mount protocol and then switch to TCP for NFS. (I didn't make it that way, but noticed it when I was adding changes for the experimental client.) So, you might want to try adding "udp" or "tcp" to the mount options for your "simplified mount" and see what happens? (I suggest this, since it seems to have been able to talk to mountd on the server, but not NFS on the server and the only explanation I can think of is the switch to TCP for that.) I think the first case failed after the retrycnt, due to the "soft" option, but hadn't succeeded in doing any NFS Getattr, so the mount point's type wasn't VDIR--> returning errno==1 EPERM for the "ls -l". If the mount attempts with "udp" or "tcp" specified give you the same behaviour, you could try using wireshark to capture the traffic. (Wireshark is pretty good at decoding NFS traffic.) If you don't have wireshark, you can use "tcpdump -w -s 0 " to capture the traffic in a file that can be fed to wireshark later. (I'd be happy to look at the traffic, if you were to email me the above .) Good luck with it, rick ps: I'll assume that the client can talk to the server for other stuff ok. pss: A big change between 7 and 8 is use of a new kernel RPC layer that handles the RPC transport (again, I wasn't the author, but am somewhat familiar with it). From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 20:43:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 269421065692; Fri, 11 Sep 2009 20:43:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id B6E3F8FC14; Fri, 11 Sep 2009 20:43:08 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG9TqkqDaFvJ/2dsb2JhbADdWIQYBYFU X-IronPort-AV: E=Sophos;i="4.44,372,1249272000"; d="scan'208";a="45974893" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 11 Sep 2009 16:43:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 06B86FB80A3; Fri, 11 Sep 2009 16:43:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1B5J+4Mj8Vi; Fri, 11 Sep 2009 16:43:07 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id E57C8FB80A1; Fri, 11 Sep 2009 16:43:06 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n8BKmL612171; Fri, 11 Sep 2009 16:48:21 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 11 Sep 2009 16:48:21 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Doug Poland In-Reply-To: Message-ID: References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, FreeBSD Current Subject: RE: NFS issues on 8.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 20:43:09 -0000 On Fri, 11 Sep 2009, Rick Macklem wrote: > > >>> >>> I cannot sucessfully mount exports from the NFSv3 server on the >>> 8.0-BETA4 client. All works well with 7.2 clients. >>> >>> The strange thing is, the directory in which I mount the nfs >>> filesystem disappears, and I get an error when I attempt to access the >>> directory. >>> I just took another glance at your email and see you have your server configured for UDP only, so that explains it. As noted in the last posting, the current mount_nfs.c switches to TCP for NFS by default, so... - add "udp" to your mount options OR - add "-t" to your nfs_server_flags and I think things will work better. I vaguely recall posting w.r.t. this uses UDP for the mount protocol and then TCP for NFS by default and didn't really get any responses. (I'm new to this and probably posted to freebsd-fs or freebsd-arch.) At that time, I didn't realize the change was post FreeBSD7, so I didn't do anything more about it. Good luck with it and let us know how it goes, rick From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 20:52:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20609106566C for ; Fri, 11 Sep 2009 20:52:13 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 064088FC1F for ; Fri, 11 Sep 2009 20:52:13 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n8BKqA5L021889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Sep 2009 13:52:11 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 45DC41CC39; Fri, 11 Sep 2009 13:52:10 -0700 (PDT) To: Borodin Oleg In-reply-to: Your message of "Sun, 06 Sep 2009 22:40:21 +0300." <4AA41025.5080908@yandex.ru> Date: Fri, 11 Sep 2009 13:52:10 -0700 From: "Kevin Oberman" Message-Id: <20090911205210.45DC41CC39@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-09-11_12:2009-09-01, 2009-09-11, 2009-09-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0909110116 Cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant not found AP without SSID in beacon packet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 20:52:13 -0000 I seem to be seeing the same thing with my ath 5212. As long as the SSID is announced, it works like a champ, but my home system does not do so and the wpa_supplicant does not work with it on V8. My config file: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel ap_scan=1 network={ ssid="babcom" scan_ssid=1 key_mgmt=NONE wep_key0=01234567890... wep_tx_keyidx=0 } Yes, I know I REALLY, REALLY, REALLY need to switch over to WPA. As soon as I get some time. I added ap_scan since the V8.0 upgrade, but it is otherwise the configuration that worked on V7.2. When the supplicant runs, I see the key and key index set on the interface, fur the SSID remains blank. If I issue the command 'ifconfig wlan0 ssid babcom', the card associates almost immediately. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > Date: Sun, 06 Sep 2009 22:40:21 +0300 > From: Borodin Oleg > Sender: owner-freebsd-current@freebsd.org > > > Hi! > > wpa_supplicant "not found" AP without SSID in beacon packets. With same > device and configuration, but FreeBSD7.2 - work without problems. > > uname: > FreeBSD flashbsd.home 8.0-BETA3 FreeBSD 8.0-BETA3 #4 r196775: Thu Sep 3 > 13:12:37 EEST 2009 > ziggi@eee.home:/usr/obj/usr/src/sys/EEE04 i386 > > wireless device: > ath0: mem 0xfbef0000-0xfbefffff irq 18 at device 0.0 > on pci1 > ath0@pci0:1:0:0: class=0x020000 card=0x10261a3b chip=0x001c168c > rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR5006 family 802.11abg Wireless NIC' > class = network > subclass = ethernet > > Access point - Cisco 877w, IOS 12.4T8 > > ----------- Variant 1. SSID not send in beacon packets from Cisco access > point - > Cisco conf fragment : > ! > dot11 mbssid > ! > dot11 ssid WNET1 > vlan 1 > authentication open. > authentication key-management wpa > wpa-psk ascii 7 10682F4857474B2D2A > ! > dot11 ssid WNET2 > vlan 2 > authentication open. > authentication key-management wpa > wpa-psk ascii 7 15342D5D567A72020E > ! > dot11 ssid WNET3 > vlan 3 > authentication open. > authentication key-management wpa > wpa-psk ascii 7 0220220A595656076A > ! > > Result FreeBSD8Beta3 wpa_suplicant & wlandebug: > > Starting AP scan (broadcast SSID) > wlan0: ieee80211_ioctl_scanreq: flags 0x52 duration 0x7fffffff mindwell > 0 maxdwe > ll 0 nssid 0 > wlan0: ieee80211_check_scan: active scan, append, nojoin, once > wlan0: sta_pick_bss: no scan candidate > wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0 > maxdwell 0 > , desired mode auto, append, nojoin, once > wlan0: scan set 1g, 6g, 11g, 7g, 13g, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 12g, > 14b dwel > l min 20ms max 200ms > wlan0: scan_task: chan 3g -> 1g [active, dwell min 20ms max 200ms] > wlan0: send probe req on channel 1 bssid ff:ff:ff:ff:ff:ff ssid "" > wlan0: received beacon from 00:23:5e:75:f7:c0 rssi 45 > wlan0: [00:23:5e:75:f7:c0] discard unhandled information element, id > 133, len 30 <-------- ???? > > wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3 > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 44 > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id > 133, len 30 > > wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3 > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 46 > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id > 133, len 30 > > wlan0: [00:23:5e:75:f7:c2] discard beacon frame, for off-channel 3 > wlan0: scan_task: chan 1g -> 6g [active, dwell min 20ms max 200ms] > wlan0: send probe req on channel 6 bssid ff:ff:ff:ff:ff:ff ssid "" > wlan0: scan_task: chan 6g -> 11g [active, dwell min 20ms max 200ms] > wlan0: send probe req on channel 11 bssid ff:ff:ff:ff:ff:ff ssid "" > wlan0: scan_task: chan 11g -> 7g [active, dwell min 20ms max 200ms] > wlan0: send probe req on channel 7 bssid ff:ff:ff:ff:ff:ff ssid "" > wlan0: scan_task: chan 7g -> 13g [passive, dwell min 20ms max 200ms] > EAPOL: disable timer tick > wlan0: scan_task: chan 13g -> 2g [active, dwell min 20ms max 200ms] > wlan0: send probe req on channel 2 bssid ff:ff:ff:ff:ff:ff ssid "" > wlan0: received beacon from 00:23:5e:75:f7:c1 rssi 56 > wlan0: [00:23:5e:75:f7:c1] discard unhandled information element, id > 133, len 30 > ... > [00:23:5e:75:f7:c1] new beacon on chan 3 (bss chan 3) 0x00 rssi 55 > [00:23:5e:75:f7:c1] caps 0x431 bintval 100 erp 0x100 > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 53 > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id > 133, len 30 > > [00:23:5e:75:f7:c2] new beacon on chan 3 (bss chan 3) 0x00 rssi 53 > [00:23:5e:75:f7:c2] caps 0x431 bintval 100 erp 0x100 > wlan0: scan_task: chan 3g -> 4g [active, dwell min 20ms max 200ms] > wlan0: send probe req on channel 4 bssid ff:ff:ff:ff:ff:ff ssid "" > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 52 > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id > 133, len 30 > ... > Scan results: 3 > CTRL-EVENT-SCAN-RESULTS > Selecting BSS from priority group 0 > Try to find WPA-enabled AP > 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > Try to find non-WPA AP > 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > No suitable AP found. <--------------------- > Setting scan request: 5 sec 0 usec > > ---------------- 2 On _any_ SSID in beacon packet: > > dot11 ssid WNET1 > vlan 1 > authentication open > authentication key-management wpa > mbssid guest-mode <--------------------------- On SSID sending > wpa-psk ascii 7 10682F4857474B2D2A > ! > dot11 ssid WNET2 > vlan 2 > authentication open > authentication key-management wpa > wpa-psk ascii 7 15342D5D567A72020E > ! > dot11 ssid WNET3 > vlan 3 > authentication open > authentication key-management wpa > wpa-psk ascii 7 0220220A595656076A > ! > > Result wpa_supplicant: > > Received 0 bytes of scan results (3 BSSes) > Scan results: 3 > CTRL-EVENT-SCAN-RESULTS > Selecting BSS from priority group 0 > Try to find WPA-enabled AP > 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > skip - SSID mismatch > 2: 00:23:5e:75:f7:c0 ssid='WNET1' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > selected based on WPA IE > selected WPA AP 00:23:5e:75:f7:c0 ssid='WNET1' > <---------------------------------------- > Trying to associate with 00:23:5e:75:f7:c0 (SSID='WNET1' freq=2422 MHz) > Cancelling scan request > > > > /etc/wpa_upplicant.conf: > # $Id$ > ctrl_interface=/var/run/wpa_supplicant > ctrl_interface_group=wheel > #eapol_version=1 > #ap_scan=1 > fast_reauth=1 > network={ > ssid="WNET1" > # scan_ssid=1 > proto=RSN WPA > key_mgmt=WPA-PSK > pairwise=CCMP TKIP > group=CCMP TKIP > psk=8c23bb58a1a94b3b56b90d8f7422a29b18f495b517f33fc6728ff2a3ad4aae1f > } > #EOF > > -- > > Best regards, > > Borodin Oleg > Kaliningrad,Russia > ziggi@inbox.ru From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 20:57:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 806C81065672 for ; Fri, 11 Sep 2009 20:57:49 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail4.es.net [IPv6:2001:400:6000:6::2]) by mx1.freebsd.org (Postfix) with ESMTP id 109D28FC0A for ; Fri, 11 Sep 2009 20:57:48 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n8BKvi9P010536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 11 Sep 2009 13:57:47 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 4819E1CC37 for ; Fri, 11 Sep 2009 13:57:44 -0700 (PDT) To: freebsd-current@freebsd.org In-reply-to: Your message of "Fri, 11 Sep 2009 13:52:10 PDT." <20090911205210.45DC41CC39@ptavv.es.net> Date: Fri, 11 Sep 2009 13:57:44 -0700 From: "Kevin Oberman" Message-Id: <20090911205744.4819E1CC37@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-09-11_12:2009-09-01, 2009-09-11, 2009-09-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0909110116 Subject: Re: wpa_supplicant not found AP without SSID in beacon packet X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 20:57:49 -0000 My sincere apologies for the top post. When I looked at it, I couldn't believe I had done it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > Date: Fri, 11 Sep 2009 13:52:10 -0700 > From: "Kevin Oberman" > Sender: owner-freebsd-current@freebsd.org > > I seem to be seeing the same thing with my ath 5212. As long as the SSID > is announced, it works like a champ, but my home system does not do so > and the wpa_supplicant does not work with it on V8. > > My config file: > ctrl_interface=/var/run/wpa_supplicant > ctrl_interface_group=wheel > ap_scan=1 > network={ > ssid="babcom" > scan_ssid=1 > key_mgmt=NONE > wep_key0=01234567890... > wep_tx_keyidx=0 > } > > Yes, I know I REALLY, REALLY, REALLY need to switch over to WPA. As soon > as I get some time. > > I added ap_scan since the V8.0 upgrade, but it is otherwise the > configuration that worked on V7.2. > > When the supplicant runs, I see the key and key index set on the > interface, fur the SSID remains blank. If I issue the command 'ifconfig > wlan0 ssid babcom', the card associates almost immediately. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > > > Date: Sun, 06 Sep 2009 22:40:21 +0300 > > From: Borodin Oleg > > Sender: owner-freebsd-current@freebsd.org > > > > > > Hi! > > > > wpa_supplicant "not found" AP without SSID in beacon packets. With same > > device and configuration, but FreeBSD7.2 - work without problems. > > > > uname: > > FreeBSD flashbsd.home 8.0-BETA3 FreeBSD 8.0-BETA3 #4 r196775: Thu Sep 3 > > 13:12:37 EEST 2009 > > ziggi@eee.home:/usr/obj/usr/src/sys/EEE04 i386 > > > > wireless device: > > ath0: mem 0xfbef0000-0xfbefffff irq 18 at device 0.0 > > on pci1 > > ath0@pci0:1:0:0: class=0x020000 card=0x10261a3b chip=0x001c168c > > rev=0x01 hdr=0x00 > > vendor = 'Atheros Communications Inc.' > > device = 'AR5006 family 802.11abg Wireless NIC' > > class = network > > subclass = ethernet > > > > Access point - Cisco 877w, IOS 12.4T8 > > > > ----------- Variant 1. SSID not send in beacon packets from Cisco access > > point - > > Cisco conf fragment : > > ! > > dot11 mbssid > > ! > > dot11 ssid WNET1 > > vlan 1 > > authentication open. > > authentication key-management wpa > > wpa-psk ascii 7 10682F4857474B2D2A > > ! > > dot11 ssid WNET2 > > vlan 2 > > authentication open. > > authentication key-management wpa > > wpa-psk ascii 7 15342D5D567A72020E > > ! > > dot11 ssid WNET3 > > vlan 3 > > authentication open. > > authentication key-management wpa > > wpa-psk ascii 7 0220220A595656076A > > ! > > > > Result FreeBSD8Beta3 wpa_suplicant & wlandebug: > > > > Starting AP scan (broadcast SSID) > > wlan0: ieee80211_ioctl_scanreq: flags 0x52 duration 0x7fffffff mindwell > > 0 maxdwe > > ll 0 nssid 0 > > wlan0: ieee80211_check_scan: active scan, append, nojoin, once > > wlan0: sta_pick_bss: no scan candidate > > wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0 > > maxdwell 0 > > , desired mode auto, append, nojoin, once > > wlan0: scan set 1g, 6g, 11g, 7g, 13g, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 12g, > > 14b dwel > > l min 20ms max 200ms > > wlan0: scan_task: chan 3g -> 1g [active, dwell min 20ms max 200ms] > > wlan0: send probe req on channel 1 bssid ff:ff:ff:ff:ff:ff ssid "" > > wlan0: received beacon from 00:23:5e:75:f7:c0 rssi 45 > > wlan0: [00:23:5e:75:f7:c0] discard unhandled information element, id > > 133, len 30 <-------- ???? > > > > wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3 > > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 44 > > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id > > 133, len 30 > > > > wlan0: [00:23:5e:75:f7:c0] discard beacon frame, for off-channel 3 > > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 46 > > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id > > 133, len 30 > > > > wlan0: [00:23:5e:75:f7:c2] discard beacon frame, for off-channel 3 > > wlan0: scan_task: chan 1g -> 6g [active, dwell min 20ms max 200ms] > > wlan0: send probe req on channel 6 bssid ff:ff:ff:ff:ff:ff ssid "" > > wlan0: scan_task: chan 6g -> 11g [active, dwell min 20ms max 200ms] > > wlan0: send probe req on channel 11 bssid ff:ff:ff:ff:ff:ff ssid "" > > wlan0: scan_task: chan 11g -> 7g [active, dwell min 20ms max 200ms] > > wlan0: send probe req on channel 7 bssid ff:ff:ff:ff:ff:ff ssid "" > > wlan0: scan_task: chan 7g -> 13g [passive, dwell min 20ms max 200ms] > > EAPOL: disable timer tick > > wlan0: scan_task: chan 13g -> 2g [active, dwell min 20ms max 200ms] > > wlan0: send probe req on channel 2 bssid ff:ff:ff:ff:ff:ff ssid "" > > wlan0: received beacon from 00:23:5e:75:f7:c1 rssi 56 > > wlan0: [00:23:5e:75:f7:c1] discard unhandled information element, id > > 133, len 30 > > ... > > [00:23:5e:75:f7:c1] new beacon on chan 3 (bss chan 3) 0x00 rssi 55 > > [00:23:5e:75:f7:c1] caps 0x431 bintval 100 erp 0x100 > > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 53 > > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id > > 133, len 30 > > > > [00:23:5e:75:f7:c2] new beacon on chan 3 (bss chan 3) 0x00 rssi 53 > > [00:23:5e:75:f7:c2] caps 0x431 bintval 100 erp 0x100 > > wlan0: scan_task: chan 3g -> 4g [active, dwell min 20ms max 200ms] > > wlan0: send probe req on channel 4 bssid ff:ff:ff:ff:ff:ff ssid "" > > wlan0: received beacon from 00:23:5e:75:f7:c2 rssi 52 > > wlan0: [00:23:5e:75:f7:c2] discard unhandled information element, id > > 133, len 30 > > ... > > Scan results: 3 > > CTRL-EVENT-SCAN-RESULTS > > Selecting BSS from priority group 0 > > Try to find WPA-enabled AP > > 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > > skip - SSID mismatch > > 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > > skip - SSID mismatch > > 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > > skip - SSID mismatch > > Try to find non-WPA AP > > 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > > skip - SSID mismatch > > 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > > skip - SSID mismatch > > 2: 00:23:5e:75:f7:c0 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > > skip - SSID mismatch > > No suitable AP found. <--------------------- > > Setting scan request: 5 sec 0 usec > > > > ---------------- 2 On _any_ SSID in beacon packet: > > > > dot11 ssid WNET1 > > vlan 1 > > authentication open > > authentication key-management wpa > > mbssid guest-mode <--------------------------- On SSID sending > > wpa-psk ascii 7 10682F4857474B2D2A > > ! > > dot11 ssid WNET2 > > vlan 2 > > authentication open > > authentication key-management wpa > > wpa-psk ascii 7 15342D5D567A72020E > > ! > > dot11 ssid WNET3 > > vlan 3 > > authentication open > > authentication key-management wpa > > wpa-psk ascii 7 0220220A595656076A > > ! > > > > Result wpa_supplicant: > > > > Received 0 bytes of scan results (3 BSSes) > > Scan results: 3 > > CTRL-EVENT-SCAN-RESULTS > > Selecting BSS from priority group 0 > > Try to find WPA-enabled AP > > 0: 00:23:5e:75:f7:c1 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > > skip - SSID mismatch > > 1: 00:23:5e:75:f7:c2 ssid='' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > > skip - SSID mismatch > > 2: 00:23:5e:75:f7:c0 ssid='WNET1' wpa_ie_len=24 rsn_ie_len=0 caps=0x31 > > selected based on WPA IE > > selected WPA AP 00:23:5e:75:f7:c0 ssid='WNET1' > > <---------------------------------------- > > Trying to associate with 00:23:5e:75:f7:c0 (SSID='WNET1' freq=2422 MHz) > > Cancelling scan request > > > > > > > > /etc/wpa_upplicant.conf: > > # $Id$ > > ctrl_interface=/var/run/wpa_supplicant > > ctrl_interface_group=wheel > > #eapol_version=1 > > #ap_scan=1 > > fast_reauth=1 > > network={ > > ssid="WNET1" > > # scan_ssid=1 > > proto=RSN WPA > > key_mgmt=WPA-PSK > > pairwise=CCMP TKIP > > group=CCMP TKIP > > psk=8c23bb58a1a94b3b56b90d8f7422a29b18f495b517f33fc6728ff2a3ad4aae1f > > } > > #EOF > > > > -- > > > > Best regards, > > > > Borodin Oleg > > Kaliningrad,Russia > > ziggi@inbox.ru > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 21:00:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 858E31065742; Fri, 11 Sep 2009 21:00:59 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206049004.chello.pl [87.206.49.4]) by mx1.freebsd.org (Postfix) with ESMTP id 830668FC29; Fri, 11 Sep 2009 21:00:58 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C224A45DF4; Fri, 11 Sep 2009 23:00:56 +0200 (CEST) Received: from localhost (abig24.neoplus.adsl.tpnet.pl [83.7.122.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4EB9745C9C; Fri, 11 Sep 2009 23:00:51 +0200 (CEST) Date: Fri, 11 Sep 2009 23:00:53 +0200 From: Pawel Jakub Dawidek To: Kris Kennaway Message-ID: <20090911210053.GA2090@garage.freebsd.pl> References: <4AA40E30.50109@FreeBSD.org> <4AAA9187.2020907@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: <4AAA9187.2020907@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: FreeBSD Current , Kip Macy Subject: Re: panic: sx_xlock() of destroyed sx @ /zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 21:00:59 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 11, 2009 at 07:05:59PM +0100, Kris Kennaway wrote: > Kris Kennaway wrote: > >9.0 doing I/O to a zfs: > > > >panic: sx_xlock() of destroyed sx @=20 > >/zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common= /fs/zfs/zfs_rlock.c:535=20 > > > >db> wh > >Tracing pid 14 tid 100047 td 0xffffff000357c720 > >kdb_enter() at kdb_enter+0x3d > >panic() at panic+0x17b > >_sx_xlock() at _sx_xlock+0xe9 > >zfs_range_unlock() at zfs_range_unlock+0x38 > >zfs_get_data() at zfs_get_data+0xd7 > >zil_commit() at zil_commit+0x532 > >zfs_sync() at zfs_sync+0xa6 > >sync_fsync() at sync_fsync+0x13a > >VOP_FSYNC_APV() at VOP_FSYNC_APV+0xb7 > >sync_vnode() at sync_vnode+0x157 > >sched_sync() at sched_sync+0x1d1 > >fork_exit() at fork_exit+0x12a > >fork_trampoline() at fork_trampoline+0xe > >--- trap 0, rip =3D 0, rsp =3D 0xffffff8125da0d30, rbp =3D 0 --- > > > >This was essentially just doing make world + cvs update + tar creation= =20 > >in a loop and failed after about a week. >=20 > Any ideas? Machine is still in DDB. I was trying to reproduce it by doing much more frequent syncs and lowering vnodes limit, so they are inactivated more often, but I wasn't able to reproduce it. The problem here is that we lock a range for the given znode, but before we unlock the range, znode is destroyed. If you compile ZFS with debug (you have to uncomment CFLAGS+=3D-DDEBUG=3D1 in sys/modules/zfs/Makefile and recompile), we should be able to catch who is killing the znode, because then, avl_destroy(&zp->z_range_avl) should trigger a panic that tree isn't empty. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKqrqFForvXbEpPzQRAo0AAJ9qiQytYhMXS2/Sy3whsqGYseIkrwCgvUTw JOs40l7NHt5hF1F0znmR++M= =n+gL -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 21:37:28 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B174C1065672 for ; Fri, 11 Sep 2009 21:37:28 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 723928FC0C for ; Fri, 11 Sep 2009 21:37:28 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id ADE151E0038B; Fri, 11 Sep 2009 23:37:26 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n8BLZ9uV098014; Fri, 11 Sep 2009 23:35:09 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id n8BLZ8EW098012; Fri, 11 Sep 2009 23:35:08 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Fri, 11 Sep 2009 23:35:08 +0200 To: qemu-devel@nongnu.org Message-ID: <20090911213508.GA97446@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Olivier =?us-ascii?B?PT9pc28tODg1OS0xP1E/Q29jaGFyZC1MYWJiPUU5Pz0=?= , freebsd-current@FreeBSD.org Subject: qemu serial: lost tx irqs (affectig FreeBSD's new uart(4) driver) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 21:37:28 -0000 Hi! I got a report of FreeBSD guest's new uart(4) driver misbehaving in qemu again(?) (output stopping for no apparent reason), and now found out the problem is tx irqs (UART_IIR_THRI) are getting lost because serial_update_irq() checks for the rx condtion, ... if ((s->ier & UART_IER_RDI) && (s->lsr & UART_LSR_DR)) first before checking for the tx irq condition, ... if ((s->ier & UART_IER_THRI) && s->thr_ipending) which at least in this case (FreeBSD 8 guest after doing set console="comconsole" at the loader prompt or when simply echo'ing text to /dev/ttyu0 or typing to the serial port from cu(1) on a `regular' vga console) causes the second condition (.. && s->thr_ipending) to be never reached anymore, or only after a very long delay. Moving that condition up so it is checked first like this, Index: qemu/hw/serial.c @@ -189,7 +188,9 @@ static void serial_update_irq(SerialStat { uint8_t tmp_iir = UART_IIR_NO_INT; - if ((s->ier & UART_IER_RLSI) && (s->lsr & UART_LSR_INT_ANY)) { + if ((s->ier & UART_IER_THRI) && s->thr_ipending) { + tmp_iir = UART_IIR_THRI; + } else if ((s->ier & UART_IER_RLSI) && (s->lsr & UART_LSR_INT_ANY)) { tmp_iir = UART_IIR_RLSI; } else if ((s->ier & UART_IER_RDI) && s->timeout_ipending) { /* Note that(s->ier & UART_IER_RDI) can mask this interrupt, @@ -202,8 +203,6 @@ static void serial_update_irq(SerialStat } else if (s->recv_fifo.count >= s->recv_fifo.itl) { tmp_iir = UART_IIR_RDI; } - } else if ((s->ier & UART_IER_THRI) && s->thr_ipending) { - tmp_iir = UART_IIR_THRI; } else if ((s->ier & UART_IER_MSI) && (s->msr & UART_MSR_ANY_DELTA)) { tmp_iir = UART_IIR_MSI; } ...fixes the issue for me, but I'm not 100% sure if this might cause rx irqs to come (too?) late when a guest keeps sending while its receiving at the same time. Anyone care to comment? :) Thanx, Juergen From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 22:33:52 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D1D7106566C for ; Fri, 11 Sep 2009 22:33:52 +0000 (UTC) (envelope-from roberthuff@rcn.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 EF3E48FC0C for ; Fri, 11 Sep 2009 22:33:51 +0000 (UTC) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 11 Sep 2009 18:33:51 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.10.7-GA) with ESMTP id QED37431; Fri, 11 Sep 2009 18:33:15 -0400 (EDT) Received: from 209-6-22-227.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.22.227]) by smtp01.lnh.mail.rcn.net with ESMTP; 11 Sep 2009 18:33:15 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19114.53291.368699.66866@jerusalem.litteratus.org> Date: Fri, 11 Sep 2009 18:33:15 -0400 To: current@freebsd.org X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) Cc: Subject: custom kernel freezes when using KVM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 22:33:52 -0000 1) About two weeks ago I installed 8.0beta3/amd64 on new hardware. Except for one problem, now solved, everything went smoothly and I was a happy camper. 2) Several days later I hooked it up to a (USB-) KVM; I also connected a Windows XP box and was able to switch back and forth between them with no problems. 3) Three days ago, I updated the system source and did the per-handbook system upgrade using the appended kernel config file. 4) Since then, using the KVM - whether or not the Windows machine is running - causes the FreeBSD box to freeze hard (requires hardware reset). While I have updated installed ports (list available on request), it seems reasonable to believe this is a OS failure and the new kernel is responsible. Is there anything I left out, or put in, that would cause this breakage? Has snyone seen this kind of thing before? Respectfully, Robert Huff # # JERUSALEM -- kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.531.2.2 2009/08/13 17:54:11 attilio Exp $ cpu HAMMER ident JERUSALEM # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. # Use the following to compile in values accessible to the kernel # through getenv() (or kenv(1) in userland). The format of the file # is 'variable=value', see kenv(1) # # env "GENERIC.env" makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options GEOM_PART_BSD options GEOM_PART_EBR options GEOM_PART_EBR_COMPAT options GEOM_PART_MBR options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=1000 # Delay (in ms) before probing SCSI options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache # options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPFIREWALL_NAT #ipfw kernel nat support options LIBALIAS # required for NAT # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci device drm # DRM core module required by DRM drivers device radeondrm # ATI Radeon # Floppy drives # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers # output. Adds ~128k to driver. # output. Adds ~215k to driver. # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #XXX it is not 64-bit clean, -scottl # RAID controllers #XXX pointer/int warnings # atkbdc0 controls both the keyboard and the PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support # Serial (COM) ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): # PCI Ethernet NICs. # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support # ISA Ethernet NICs. pccard NICs included. # 'device ed' requires 'device miibus' # Wireless NIC cards # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # USB Serial devices device uark # Technologies ARK3116 based serial adapters device ubsa # Belkin F5U103 and compatible serial adapters device uftdi # For FTDI usb serial adapters device uipaq # Some WinCE based devices device uplcom # Prolific PL-2303 serial adapters device uslcom # SI Labs CP2101/CP2102 serial adapters device uvisor # Visor and Palm devices device uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus # FireWire support From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 23:03:16 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B721106566C for ; Fri, 11 Sep 2009 23:03:16 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail2.es.net [IPv6:2001:400:107:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 350C48FC13 for ; Fri, 11 Sep 2009 23:03:16 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n8BN3BJG005807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 11 Sep 2009 16:03:14 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 21FB21CC37 for ; Fri, 11 Sep 2009 16:03:11 -0700 (PDT) To: current@freebsd.org Date: Fri, 11 Sep 2009 16:03:11 -0700 From: "Kevin Oberman" Message-Id: <20090911230311.21FB21CC37@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-09-11_12:2009-09-01, 2009-09-11, 2009-09-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0909110130 Cc: Subject: Fix for /usr/src/Makefile.inc1 in 8.0? (pr conf/137483) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 23:03:16 -0000 Some time ago it was noticed (by both myself and others) that the conditional code to implement some of the system build options in src.conf(5) was badly broken. Several options with broke the build or just didn't work correctly. Mostly incorrect nesting of if statements in the file. b.f. has made a patch for this and submitted it some time ago to re, but I suspect that it fell through the cracks with all of the critical issues to be attended to before 8.0 is ready. The PR is conf/137483. The breakage to buildworld is unquestionable and will bite a lot of systems when 8.0 is released. The patch is pretty straight-forward. I have been using it since I started running 8.0 a couple of months ago. I know RE has a lot to do in a very short time, but I would really hope that this can be addressed. And, if it can't be done for 8.0, can someone at least commit this to HEAD so it can be MFCed to make it easier for those who hit this problem in 8.0-RELEASE? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 17:50:14 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D17C1065696 for ; Fri, 11 Sep 2009 17:50:14 +0000 (UTC) (envelope-from ddkprog@yahoo.com) Received: from web59103.mail.re1.yahoo.com (web59103.mail.re1.yahoo.com [66.196.101.14]) by mx1.freebsd.org (Postfix) with SMTP id 04E0D8FC1C for ; Fri, 11 Sep 2009 17:50:13 +0000 (UTC) Received: (qmail 64872 invoked by uid 60001); 11 Sep 2009 17:50:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252691401; bh=iuWsJRnyxF9Mjmf0Z4CNUxFFFDaJ/m9Vj/VqSJ0UccQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=y6YQp9ERbmUPG1uzR+VH1ooLz7jIIY/8KY+6EcJbQxW7pH92m8U1dOeWohruaJOe/wk6EODoTSPakvVIXShe13HogkOmSjX53F23LqYJB4eVtNELLKiFNM+IuTeVn6lydSaXPahsN5Q+CN2uWx02dOKrJI/OVjOF0QKfPAJE508= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=s+AUFZaYi3+DMwsmCPuMuln2MTA6w1msn2XE9QXGtUm2aut5dfhn3JLLHihBsvr/EVDgwEW1BRjqSaB+f2EZlOw5Zkwc2Jf89GLYMLJFGxo4UXiQw++7O7C/GcdaGRhrOe5GoI6ZyxWqhKoN/zoRV+gZ2h8Cg8bvUKPStLj9XkE=; Message-ID: <898308.64226.qm@web59103.mail.re1.yahoo.com> X-YMail-OSG: n2lVuQUVM1llYgeuqqX8AonV7C_4rIVD4ehTo6OrKjshyKR3E4Xh_iO4YTJNvaPQA7wJs3NQYAlJbdbWtYfaJ2J0aD3PhUcETn90nhVICFnoz69AyXzmFYk_RMzAiE9SY_ti8RECXcPYUHvQK50qlgn__rhB0VwYUACV9QYWuMz0.SUUyYYi__sxCrvwTz3hV2_yJP_Vz3ZsBmnvQHOJFxTc9Lq4i.WeRKqk0i1fHKbb41kOkMI8GtTeJHNJ877q7gQOIX8PDGMjXfsiFsXOrwU- Received: from [95.109.154.178] by web59103.mail.re1.yahoo.com via HTTP; Fri, 11 Sep 2009 10:50:01 PDT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.347.2 Date: Fri, 11 Sep 2009 10:50:01 -0700 (PDT) From: ddk ddk To: Ed Schouten In-Reply-To: <20090911155001.GU2829@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 11 Sep 2009 23:43:52 +0000 Cc: swell.k@gmail.com, freebsd-current@FreeBSD.org, delphij@FreeBSD.ORG Subject: Re: vesa(4) and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 17:50:14 -0000 > > ddk ddk wrote: > >=A0 I think this is a problem that has added a new > terminal > >=A0 teken by ed@ > >=A0=20 > >=A0 becouse there is no problem on freebsd 7 where > is no teken > >=A0 where I can switch to any low mode=20 >=20 > Hmmm... As far as I know, syscons reinitializes the > terminal completely > when switching resolutions. Does it crash? If so, are you > capable of > obtainining a backtrace? >=20 > In my newcons branch I do have a very small patch for > libteken that > changes the resizing behaviour. In my new vt console driver > I do resize > the terminal emulator without reinitializing it completely, > so I had to > make set_winsize() a bit more robust. >=20 > I think it's very unlikely that this patch fixes the issue > you are > seeing, but please do try. >=20 the problem was localized=20 No more problems with switching to decrease the screen resolution in graphi= cs modes=20 (I just updated to tag =3D.=20 I used to use its working version of freebsd consisting of many patches)=20 but exists problem in switching graphic screen back to text mode on ttyv0 but only on ttyv0 I can not provide backtrace because the system is fully freezes sequence that leads to the problem=20 1) boot freebsd=20 2) stay only on ttyv0 3) kldload vesa=20 4) vidcontrol MODE_277 (800x600x32) 5) vidcontrol MODE_24 (80x24 text mode) The system immediately freezes switch to any of the consoles is an infinite beeeeeep if you do the same but on another ttyvX (/dev/ttyv1 .../dev/ttyv9) then there is no problem > --=20 > Ed Schouten > WWW: http://80386.nl/ > =0A=0A=0A From owner-freebsd-current@FreeBSD.ORG Fri Sep 11 23:48:24 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 386231065670; Fri, 11 Sep 2009 23:48:24 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id D19D78FC13; Fri, 11 Sep 2009 23:48:23 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 1FAFB1CC94; Sat, 12 Sep 2009 01:48:23 +0200 (CEST) Date: Sat, 12 Sep 2009 01:48:23 +0200 From: Ed Schouten To: ddk ddk Message-ID: <20090911234823.GW2829@hoeg.nl> References: <20090911155001.GU2829@hoeg.nl> <898308.64226.qm@web59103.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s/DY0TM5dkgdNyMY" Content-Disposition: inline In-Reply-To: <898308.64226.qm@web59103.mail.re1.yahoo.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: swell.k@gmail.com, freebsd-current@FreeBSD.org, delphij@FreeBSD.ORG Subject: Re: vesa(4) and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 23:48:24 -0000 --s/DY0TM5dkgdNyMY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, * ddk ddk wrote: > if you do the same but on another ttyvX (/dev/ttyv1 .../dev/ttyv9) > then there is no problem I suspect this has something to do with the fact that the screen buffer for window 0 is differently allocated than the other ones, because it has to be statically allocated to work very early on... --=20 Ed Schouten WWW: http://80386.nl/ --s/DY0TM5dkgdNyMY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkqq4ccACgkQ52SDGA2eCwWMOgCfaDmhtoJ2J0rvwaycr46Jumez CUoAnR5wqw/IbhIO4XZ3qPuR3y3i7gCy =BiP6 -----END PGP SIGNATURE----- --s/DY0TM5dkgdNyMY-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 00:29:24 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17343106566B for ; Sat, 12 Sep 2009 00:29:24 +0000 (UTC) (envelope-from ddkprog@yahoo.com) Received: from web59104.mail.re1.yahoo.com (web59104.mail.re1.yahoo.com [66.196.101.15]) by mx1.freebsd.org (Postfix) with SMTP id 9DD778FC15 for ; Sat, 12 Sep 2009 00:29:23 +0000 (UTC) Received: (qmail 5392 invoked by uid 60001); 12 Sep 2009 00:29:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252715362; bh=zGBDQfdpGBzSv/AflAXCc65eRrxC0+s1jdfJPXHJc3A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lR93+ZYod2rzGK1XfJ7XFeT8LpnYdPCLSx9KuHy48Hj7BkVl1OhSgEz/zCcCbDF1p1fCOe0ob0FHbreO9cclmQA8I9wlEiiW2ZYrpmXJwld7Ak0ClCnoEbjF6uIxklWen8EhdkDhYZ14kDgN+jwjg4iFNFvVc99ekIVgjpuusFA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=L8+iL6zRZVJJmMK+hlstOdEBtilHbv4LMvzSqcoiBFJ0/NfyIYdnNU8LwRPKUHys26M8TqZjJ9H9JmrW4fHLDNjZAo3zxd5ZU/JbAx8x71IoMXVfiWHUvFOaMEuSJ7HjvfI0X8NQD9UtHM3U7Pl6+JQd2MKwqX/PWP1T2DX/7wI=; Message-ID: <904348.4868.qm@web59104.mail.re1.yahoo.com> X-YMail-OSG: Jm3E02MVM1l9h62Hudx59OQK3PTMxEX2bblAcbof4y0pyinmx3EEcFEA2y6XuOMVh1QlvPYLClRZGMmC4arXbecqdL3Lec0jlY2HRD2CKBZdnHWmAvc_FRMRj8KavZ124xcqB_6K5.sw4xKAHOV4G8HDDNJP.WShP.UUVbgwXpcAyKUrRr6ZrziAzDy1OQDJ9fF6rTdA63l5QvZNEixZWRKbHj4Tuw9vFY5rC3GTVWabkaNopIqlHOao.KIGcwVlujzQn1jl22ILF9.1TCfzkDxw8vVevM9Aa7rjG6e1ZJ8c Received: from [95.109.154.178] by web59104.mail.re1.yahoo.com via HTTP; Fri, 11 Sep 2009 17:29:22 PDT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.347.2 Date: Fri, 11 Sep 2009 17:29:22 -0700 (PDT) From: ddk ddk To: Ed Schouten In-Reply-To: <20090911234823.GW2829@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sat, 12 Sep 2009 00:39:17 +0000 Cc: swell.k@gmail.com, freebsd-current@FreeBSD.org, delphij@FreeBSD.ORG Subject: Re: vesa(4) and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 00:29:24 -0000 > * ddk > wrote: > > if you do the same but on another ttyvX (/dev/ttyv1 > .../dev/ttyv9) > > then there is no problem > > I suspect this has something to do with the fact that the > screen buffer > for window 0 is differently allocated than the other ones, > because it > has to be statically allocated to work very early on... > I surprised even without the driver vesa using only options SC_PIXEL_MODE options VGA_WIDTH90 I got the same freezing but on the other consoles I will update the 9-current on my laptop with i386 arch and trying to duplicate these bugs quite possible that arch amd64 bug > -- > Ed Schouten > WWW: http://80386.nl/ > From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 02:03:55 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D76D1065670; Sat, 12 Sep 2009 02:03:55 +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 B5B5D8FC08; Sat, 12 Sep 2009 02:03:54 +0000 (UTC) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 7C3065C06F; Sat, 12 Sep 2009 10:03:53 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 3113355CDF7D; Sat, 12 Sep 2009 10:03:53 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id AyjuB3AMojK5; Sat, 12 Sep 2009 10:03:47 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 8A86255CDF7B; Sat, 12 Sep 2009 10:03:44 +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; b=viBWhxi8j5/UBVVCrg3onpuPMliDNtmU0yA//vjK38qxHThgz5jTDZPt8mxiwrtiP DHanW60w9Wcigjc9S8PDQ== Message-ID: <4AAB017D.7090909@delphij.net> Date: Fri, 11 Sep 2009 19:03:41 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.22 (X11/20090803) MIME-Version: 1.0 To: "b. f." References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------070706020609080506080705" Cc: freebsd-current@FreeBSD.org, delphij@FreeBSD.org Subject: Re: vesa(4) and amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 02:03:55 -0000 This is a multi-part message in MIME format. --------------070706020609080506080705 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, b. f. wrote: > After the recent x86emu/vesa/dpms commits, I'm now able to use some > more graphics modes with syscons on amd64. That's good. Not so good > is the fact that my HP Pavilion desktop running 9-CURRENT i386 r197085 > with > > devic sc > options SC_PIXEL_MODE > device vga > options VGA_WIDTH90 > > in the kernel and agp, dpms, x86emu, and vesa loaded as kernel modules > can no longer use the 132x60 mode that had been my default syscons > mode, and now yields a blank screen. Even worse is the fact that my > Toshiba laptop, with nearly the same configuration, locks up with a > screen full of zeroes every time I load the new vesa kernel module, > when formerly it had no such problem. Other than simplifying the > organization of the code, is there any advantage to be gained from > forcing those platforms that are capable of native vesa to use x86emu? > Because up to this point there are serious disadvantages to doing so. I think it was caused by some unrelated change. ddkprog@ has proposed a change, here is a slightly modified one, could you please give it a try? I'll try to see if I can have some clue myself tonight. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqrAXwACgkQi+vbBBjt66AK3wCgj9fnz60SWIIa7OUAdF/4x8aR evsAoJ3A8QObHWMYXsOXwKbuCBR0pxKe =Sr3u -----END PGP SIGNATURE----- --------------070706020609080506080705 Content-Type: text/plain; name="vesa.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vesa.diff" Index: sys/dev/fb/vesa.c =================================================================== --- sys/dev/fb/vesa.c (revision 197050) +++ sys/dev/fb/vesa.c (working copy) @@ -1126,7 +1126,7 @@ } else { vesa_adp->va_buffer = 0; vesa_adp->va_buffer_size = info.vi_buffer_size; - vesa_adp->va_window = (vm_offset_t)(emumem+L_ADD(info.vi_window)); + vesa_adp->va_window = info.vi_window + KERNBASE; vesa_adp->va_window_size = info.vi_window_size; vesa_adp->va_window_gran = info.vi_window_gran; } --------------070706020609080506080705-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 02:46:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA19E106566B for ; Sat, 12 Sep 2009 02:46:31 +0000 (UTC) (envelope-from pj@smo.de) Received: from mail.ilk.de (mx-out20.ilk.de [194.121.104.20]) by mx1.freebsd.org (Postfix) with ESMTP id 555A18FC12 for ; Sat, 12 Sep 2009 02:46:30 +0000 (UTC) Received: from bologna.intern.smo.de (pool20.ka.ilk.net [212.86.194.20]) by mail.ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id n8BL4eI3023315 for ; Fri, 11 Sep 2009 23:04:41 +0200 Received: from [192.168.153.208] (herdubreid.intern.smo.de [192.168.153.208]) by bologna.intern.smo.de (8.13.8+Sun/8.13.8) with ESMTP id n8BL4bW3025889 for ; Fri, 11 Sep 2009 23:04:37 +0200 (CEST) Message-ID: <4AAABBCB.8050302@smo.de> Date: Fri, 11 Sep 2009 23:06:19 +0200 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20090802 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: FreeBSD Current Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090200030202020307050603" Subject: [BETA2] Floppy drive no longer accessible X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 02:46:32 -0000 This is a cryptographically signed message in MIME format. --------------ms090200030202020307050603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi guys, I'm running 8.0-BETA2 (i386) and have some problems concerning my floppy drive -- it's no longer accessible because there's no entry in /dev: $ find /dev -name \*fd\* /dev/fd $ dmesg reports: $ dmesg | grep fd fdc1: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc1: [FILTER] fdc0: No FDOUT register! kern_openat(c44a7240,ffffff9c,bfbfd81b,0,a02,...) at kern_openat+0x11f kern_open(c44a7240,bfbfd81b,0,a01,180,...) at kern_open+0x35 --- syscall (5, FreeBSD ELF32, open), eip = 0x33f8f203, esp = 0xbfbfd3ec, ebp = 0xbfbfdc88 --- $ Asking Google for help on this, I did only find threads dating back to 2004. It used to work perfectly fine with 7.2-STABLE, but that's not much help now I guess ;-) Any hints on this? I think I'm going to upgrade to BETA4 -- it can only get better... I'm happy to provide more information if needed. Thanks for your help, Philipp --------------ms090200030202020307050603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQEjCC BP8wggLnoAMCAQICAwCHRzANBgkqhkiG9w0BAQUFADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5j LjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xh c3MgMyBSb290MB4XDTA5MDgwOTE5MDkxMFoXDTExMDgwOTE5MDkxMFowODEcMBoGA1UEAxMT UGhpbGlwcC1Kb2FjaGltIE9zdDEYMBYGCSqGSIb3DQEJARYJcGpAc21vLmRlMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHi5tzklVWnzS24cGcYFZYdq86t0pnwjP5Bp1dWX TuY8qU7i1gzCPWvHmmjicyKjwPOWN3ciM0pnhQK6NMqA1xf3OL9tLtETF/eC5Ey3oW0Lsoex jtOmeBfXxdd4o+41UkRx/vS5TWtHa3JILrBS71N34HK8RcPGlb/chw/XMX1atYbOEIg4fsaH IXsh87WNLEhMtTStUeDmRcx0lEZ11QhWJaJDlBmmbsFPZ70FbjnHVaFbZzZhWKJ8FSWgmYok 6Cibopn/Jpin4fYY7jnH/l6jlTipNEbFErMvfwdg8RQp0CHlwwH68O+Ejfb5JaPrkxl19H0p ZKhuBePQNVqqmwIDAQABo4H1MIHyMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1Rv IGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDov L3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGC NwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw AYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAUBgNVHREEDTALgQlwakBzbW8uZGUwDQYJKoZI hvcNAQEFBQADggIBAFjI0W2tTQ05mECbiTOz3Gi8tielpXmHyXeiQVCJPM/JaLV4yytUAQjf NoK0shJn52sVuvh0ZlvbD+o7XCSOGvq87Jt2mBLiQs8SAKc/SvyjNYSX+8pM1/wQ/EcJ5yNw vnkDCK5yvqIB8ItCIayeE6ybUZ1ga/HVIBfPSs+qPlajTYhaFMYk/QGQ2o8gwDTv08qizHnu iei2zOB/+dqFmBfAxxEnvOSWzmLr6ylAPMOfrOzkji803fwDjFVbAqpS5dfjCZsKm2dB6hzW uJRM0CpdY4jf5Ci3fCt1gSPnUOdOUC/FXuPmVeHccrfJpH9W0fyhG4MnoRqou/LpkbD4DEp+ +a0oaX4WvOXsXIqdZy/lpiFBtsI+easHmLZYVq9eEAz3vsX3zeFF3v6sY7UOOvxEiMFm1Y4W Ioh7gF4BQWUAi48gwlJYg/xtqQ3vdZhPvwGcIhqbkbxLAmaHjV3Nbrbo+p+xzDEv5CzQBwy6 MIe2TUfRjHymA3r2drx2Z/cLWRDgpzuKhnul6sDnkLVXFPP9Jidy7joSlndIjrJFR4+F3xfw 7tDHa1WHuGW5QGItblpG6bb34dxq9C1MGcMjMcIP7xYPGbjjUPZzPxT64T/jpzP2MoefRz4I M/8LKt8iMASoTaUUxwIGFZ87yU0k+fD7hZm7ZUkba77kDi7R+BsaMIIE/zCCAuegAwIBAgID AIdHMA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVo dHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwHhcN MDkwODA5MTkwOTEwWhcNMTEwODA5MTkwOTEwWjA4MRwwGgYDVQQDExNQaGlsaXBwLUpvYWNo aW0gT3N0MRgwFgYJKoZIhvcNAQkBFglwakBzbW8uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCseLm3OSVVafNLbhwZxgVlh2rzq3SmfCM/kGnV1ZdO5jypTuLWDMI9a8ea aOJzIqPA85Y3dyIzSmeFAro0yoDXF/c4v20u0RMX94LkTLehbQuyh7GO06Z4F9fF13ij7jVS RHH+9LlNa0drckgusFLvU3fgcrxFw8aVv9yHD9cxfVq1hs4QiDh+xocheyHztY0sSEy1NK1R 4OZFzHSURnXVCFYlokOUGaZuwU9nvQVuOcdVoVtnNmFYonwVJaCZiiToKJuimf8mmKfh9hju Ocf+XqOVOKk0RsUSsy9/B2DxFCnQIeXDAfrw74SN9vklo+uTGXX0fSlkqG4F49A1WqqbAgMB AAGjgfUwgfIwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3du IGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5v cmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2Nz cC5jYWNlcnQub3JnMBQGA1UdEQQNMAuBCXBqQHNtby5kZTANBgkqhkiG9w0BAQUFAAOCAgEA WMjRba1NDTmYQJuJM7PcaLy2J6WleYfJd6JBUIk8z8lotXjLK1QBCN82grSyEmfnaxW6+HRm W9sP6jtcJI4a+rzsm3aYEuJCzxIApz9K/KM1hJf7ykzX/BD8RwnnI3C+eQMIrnK+ogHwi0Ih rJ4TrJtRnWBr8dUgF89Kz6o+VqNNiFoUxiT9AZDajyDANO/TyqLMee6J6LbM4H/52oWYF8DH ESe85JbOYuvrKUA8w5+s7OSOLzTd/AOMVVsCqlLl1+MJmwqbZ0HqHNa4lEzQKl1jiN/kKLd8 K3WBI+dQ505QL8Ve4+ZV4dxyt8mkf1bR/KEbgyehGqi78umRsPgMSn75rShpfha85excip1n L+WmIUG2wj55qweYtlhWr14QDPe+xffN4UXe/qxjtQ46/ESIwWbVjhYiiHuAXgFBZQCLjyDC UliD/G2pDe91mE+/AZwiGpuRvEsCZoeNXc1utuj6n7HMMS/kLNAHDLowh7ZNR9GMfKYDevZ2 vHZn9wtZEOCnO4qGe6XqwOeQtVcU8/0mJ3LuOhKWd0iOskVHj4XfF/Du0MdrVYe4ZblAYi1u Wkbptvfh3Gr0LUwZwyMxwg/vFg8ZuONQ9nM/FPrhP+OnM/Yyh59HPggz/wsq3yIwBKhNpRTH AgYVnzvJTST58PuFmbtlSRtrvuQOLtH4GxowggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEB BAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1NVoXDTMzMDMyODA3MzY1NVowVDEU MBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEc MBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCC AgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++tykA10oZZkq5+gJJlz 2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUoqMV5CX1GuYrz 6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+lzNZ6MMD PWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rVO5J+ TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luL oFvqTpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQo cDggL9V/KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNj VSKRPFbnr9s6JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2v jBDTn8Rq+G8T/HNZ92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/ BAUwAwEB/zBdBggrBgEFBQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2Vy dC5vcmcvMCgGCCsGAQUFBzAChhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1Ud IARDMEEwPwYIKwYBBAGBkEowMzAxBggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3Jn L2luZGV4LnBocD9pZD0xMDANBgkqhkiG9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivce xDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KRwpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXB PohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueTuYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5E HMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86QfHjL8JxUFz90urj6CYXvwIRAY9kTq Uzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEiqogwAOKw1Ly+ZbrVA1d5m+jc yE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUKbL8Xx3JGV5yY9WxgY3pv XrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAXpS0Q65x6Sr297s79 7SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpWYwBkuV2kYn1X Nk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bjoVlX93Gy xG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HSbqUb mSeA5wupqAAxggMeMIIDGgIBATBbMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QC AwCHRzAJBgUrDgMCGgUAoIIBmDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wOTA5MTEyMTA2MTlaMCMGCSqGSIb3DQEJBDEWBBT1LCsthCLaEd8GbMv9EjBJ pelPgDBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwagYJKwYB BAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3 dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMAh0cwbAYLKoZI hvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8v d3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAwCHRzANBgkq hkiG9w0BAQEFAASCAQCnpBtHAjeKFXZBAthDnhmI28bn9IC/V38q87QFXSzN8vjCHxzY3BKk 2Tzdb/W8n8EY5ZhUVv1NqNcd0pE1msydS902TG2iyoKDQ+4mj5/kraOycs/KIJ7ETL2ZcjDJ 0IaviRKy8H4Lvbhp8X85YW7pqRDa+nkKIAFP1EDy2HUaXSImLXyjG+dExJlGf4mwjGFHWlOC xKZwswhUaWox5AjuqVNbZ/qIexVX40xaY2WFIwxAPxB8VJzSLXTq3vb4kBakyxRMhmatd1hN mEhv8GMmLNE6Xm4AvQxqY3vsD6/WrhatKS9d+nRuMtZCclqZKT1JtNBUlLF/YfAhh0FMOWWZ AAAAAAAA --------------ms090200030202020307050603-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 03:34:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F378C106568B for ; Sat, 12 Sep 2009 03:34:03 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id CCBE38FC0C for ; Sat, 12 Sep 2009 03:34:03 +0000 (UTC) Received: from unknown (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id C7E1081C6; Sat, 12 Sep 2009 03:34:02 +0000 (UTC) Date: Sat, 12 Sep 2009 04:34:08 +0100 From: Bruce Cran To: Philipp Ost Message-ID: <20090912043408.00000f6d@unknown> In-Reply-To: <4AAABBCB.8050302@smo.de> References: <4AAABBCB.8050302@smo.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: [BETA2] Floppy drive no longer accessible X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 03:34:04 -0000 On Fri, 11 Sep 2009 23:06:19 +0200 Philipp Ost wrote: > Hi guys, > > I'm running 8.0-BETA2 (i386) and have some problems concerning my > floppy drive -- it's no longer accessible because there's no entry > in /dev: > > $ find /dev -name \*fd\* > /dev/fd > $ There was a regression in the ACPI code that was fixed after 8.0-BETA2 - see the thread "fdc(4) regression: fdc0 fails to probe" for details. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 09:03:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA976106566B; Sat, 12 Sep 2009 09:03:59 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id 637E78FC0C; Sat, 12 Sep 2009 09:03:59 +0000 (UTC) Received: from a91-153-125-115.elisa-laajakaista.fi (a91-153-125-115.elisa-laajakaista.fi [91.153.125.115]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id 34AF9139710; Sat, 12 Sep 2009 12:03:54 +0300 (EEST) Date: Sat, 12 Sep 2009 12:03:53 +0300 From: Jaakko Heinonen To: Pawel Jakub Dawidek Message-ID: <20090912090353.GA806@a91-153-125-115.elisa-laajakaista.fi> References: <4AA40E30.50109@FreeBSD.org> <4AAA9187.2020907@FreeBSD.org> <20090911210053.GA2090@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090911210053.GA2090@garage.freebsd.pl> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Kris Kennaway , FreeBSD Current , Kip Macy Subject: Re: panic: sx_xlock() of destroyed sx @ /zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/co mmon/fs/zfs/zfs_rlock.c:535 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 09:03:59 -0000 On 2009-09-11, Pawel Jakub Dawidek wrote: > > >panic: sx_xlock() of destroyed sx @ > > >/zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535 > > I was trying to reproduce it by doing much more frequent syncs and > lowering vnodes limit, so they are inactivated more often, but I wasn't > able to reproduce it. > > The problem here is that we lock a range for the given znode, but before > we unlock the range, znode is destroyed. I wonder if this could be related to PR kern/132068 (i.e. zfs_zget() can return reclaimed vnodes). If you can reproduce the panic you could try this patch: http://www.saunalahti.fi/~jh3/patches/zfs_zget-vnode-reclaim-race.diff -- Jaakko From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 11:21:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F2011065676 for ; Sat, 12 Sep 2009 11:21:07 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by mx1.freebsd.org (Postfix) with ESMTP id C6C5B8FC13 for ; Sat, 12 Sep 2009 11:21:06 +0000 (UTC) Received: by vws27 with SMTP id 27so1108980vws.3 for ; Sat, 12 Sep 2009 04:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=F3JlaJWDNAbAKtYogR9PmcmgZ199OUqn8Lj0NW4ApLk=; b=eX/m+RJmNdhjwmcbHLNbEgDZaKM8AW+QAAK69PIWBMMq2IhHKPXQiaPvdiNMS4QPSm Xen8fYbT3j6+hKvyOIwbXK5KvrfFFAuvEPe7Ay4PSrXaJb5cgIdu5hcwvXPlAjSjsRSE jPs9GB4osNbm3yfzlHqZ6BpxBYvEm1r3/bElE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=sq9EFpIA8bQU2hSVzXU6u8wnwS7bxnEu3+Wu3rpm/D69H1oFc1YxMxO2g/SuPDranc ivtXrDwY79e5DrBgGX4NC7lLRTAulfPD+VK03U1GyxP8kZ0ONlRcAQ+uX6+dMtGa1v0l kj6q/3CzWkhU+lRM1cSPoCRhtTOJE8rGSeHhI= MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.220.69.211 with SMTP id a19mr4654156vcj.20.1252754465905; Sat, 12 Sep 2009 04:21:05 -0700 (PDT) In-Reply-To: <20090911213508.GA97446@triton8.kn-bremen.de> References: <20090911213508.GA97446@triton8.kn-bremen.de> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sat, 12 Sep 2009 13:20:45 +0200 X-Google-Sender-Auth: f46709ac4f9ffb91 Message-ID: <3131aa530909120420ge13c7arfd1eb6e9224d6581@mail.gmail.com> To: Juergen Lock Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 12 Sep 2009 11:33:05 +0000 Cc: freebsd-current@freebsd.org, qemu-devel@nongnu.org Subject: Re: qemu serial: lost tx irqs (affectig FreeBSD's new uart(4) driver) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 11:21:07 -0000 Hi, On Fri, Sep 11, 2009 at 11:35 PM, Juergen Lock wro= te: > ...fixes the issue for me, but I'm not 100% sure if this might cause > rx irqs to come (too?) late when a guest keeps sending while its > receiving at the same time. =A0Anyone care to comment? :) > Your patch fix the issue for me too. Thanks a lot's Juergen ! Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 14:41:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C36EA1065696; Sat, 12 Sep 2009 14:41:15 +0000 (UTC) (envelope-from doug@polands.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6418FC21; Sat, 12 Sep 2009 14:41:14 +0000 (UTC) Received: from haran.polands.org ([75.87.219.217]) by hrndva-omta01.mail.rr.com with ESMTP id <20090912144114123.WHNK11562@hrndva-omta01.mail.rr.com>; Sat, 12 Sep 2009 14:41:14 +0000 Received: from email.polands.org (ammon.polands.org [172.16.1.7]) by haran.polands.org (8.14.3/8.14.3) with ESMTP id n8CEfBsi081786; Sat, 12 Sep 2009 09:41:11 -0500 (CDT) (envelope-from doug@polands.org) Received: from 172.16.1.1 (SquirrelMail authenticated user djp) by email.polands.org with HTTP; Sat, 12 Sep 2009 09:41:13 -0500 Message-ID: <19c32ef4263ed3c2ab1624a43ae86c78.squirrel@email.polands.org> In-Reply-To: References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org> Date: Sat, 12 Sep 2009 09:41:13 -0500 From: "Doug Poland" To: "Rick Macklem" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "Li, Qing" , freebsd-stable@freebsd.org, FreeBSD Current , Andrzej Tobola Subject: RE: NFS issues on 8.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 14:41:15 -0000 On Fri, September 11, 2009 15:37, Rick Macklem wrote: > >>> >>> I cannot sucessfully mount exports from the NFSv3 server on the >>> 8.0-BETA4 client. All works well with 7.2 clients. >>> >>> The strange thing is, the directory in which I mount the nfs >>> filesystem disappears, and I get an error when I attempt to >>> access the directory. >>> > > I went and looked at the message over in stable@ (I guess I have to > join that mailing list, too:-). > > I think that the second mount attempt, which failed with errno==64 > EHOSTDOWN probably gives you a better indication of what is broken > and hints at a networking problem, which hopefully others can help > with? > > mount_nfs currently has the quirk that, if you don't specify either > "udp" or "tcp", it will use UDP for the mount protocol and then > switch to TCP for NFS. (I didn't make it that way, but noticed it > when I was adding changes for the experimental client.) So, you might > want to try adding "udp" or "tcp" to the mount options for your > "simplified mount" and see what happens? (I suggest this, since it > seems to have been able to talk to mountd on the server, but not NFS > on the server and the only explanation I can think of is the switch > to TCP for that.) > > I think the first case failed after the retrycnt, due to the "soft" > option, but hadn't succeeded in doing any NFS Getattr, so the mount > point's type wasn't VDIR--> returning errno==1 EPERM for the "ls -l". > > > If the mount attempts with "udp" or "tcp" specified give you the same > behaviour, you could try using wireshark to capture the traffic. > (Wireshark is pretty good at decoding NFS traffic.) If you don't have > wireshark, you can use "tcpdump -w -s 0 " to capture > the traffic in a file that can be fed to wireshark later. (I'd be > happy to look at the traffic, if you were to email me the above > .) > > Good luck with it, rick ps: I'll assume that the client can talk to > the server for other stuff ok. pss: A big change between 7 and 8 is > use of a new kernel RPC layer that handles the RPC transport (again, > I wasn't the author, but am somewhat familiar with it). > > Simply adding -o udp to my mount command made the NFS mount work correctly. Qing, would it be beneficial to attempt the patch in light of these findings? Thanks all for the help, sorry for the noise. -- Regards, Doug From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 15:32:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 456D5106568B; Sat, 12 Sep 2009 15:32:41 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206049004.chello.pl [87.206.49.4]) by mx1.freebsd.org (Postfix) with ESMTP id 79E0E8FC0C; Sat, 12 Sep 2009 15:32:39 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C017345E49; Sat, 12 Sep 2009 17:32:37 +0200 (CEST) Received: from localhost (abgy240.neoplus.adsl.tpnet.pl [83.7.88.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 14DB245C9F; Sat, 12 Sep 2009 17:32:30 +0200 (CEST) Date: Sat, 12 Sep 2009 17:32:30 +0200 From: Pawel Jakub Dawidek To: Jaakko Heinonen Message-ID: <20090912153230.GA5522@garage.freebsd.pl> References: <4AA40E30.50109@FreeBSD.org> <4AAA9187.2020907@FreeBSD.org> <20090911210053.GA2090@garage.freebsd.pl> <20090912090353.GA806@a91-153-125-115.elisa-laajakaista.fi> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <20090912090353.GA806@a91-153-125-115.elisa-laajakaista.fi> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Kris Kennaway , FreeBSD Current , Kip Macy Subject: Re: panic: sx_xlock() of destroyed sx @ /zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/co mmon/fs/zfs/zfs_rlock.c:535 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 15:32:41 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 12, 2009 at 12:03:53PM +0300, Jaakko Heinonen wrote: > On 2009-09-11, Pawel Jakub Dawidek wrote: > > > >panic: sx_xlock() of destroyed sx @=20 > > > >/zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/co= mmon/fs/zfs/zfs_rlock.c:535=20 > >=20 > > I was trying to reproduce it by doing much more frequent syncs and > > lowering vnodes limit, so they are inactivated more often, but I wasn't > > able to reproduce it. > >=20 > > The problem here is that we lock a range for the given znode, but before > > we unlock the range, znode is destroyed. >=20 > I wonder if this could be related to PR kern/132068 (i.e. zfs_zget() can > return reclaimed vnodes). >=20 > If you can reproduce the panic you could try this patch: >=20 > http://www.saunalahti.fi/~jh3/patches/zfs_zget-vnode-reclaim-race.diff Good catch. I modifed the kernel to reclaim all vnodes on every getnewvnode() and also slowed down zfs_reclaim_complete() and I was able to reproduce this race. I also found another problem - when we defer znode destruction there is a race where file system unmount or rollback can be called between zfs_freebsd_reclaim() and zfs_reclaim_complete(), which can case various problems. I almost have a patch ready, but it needs some more work. I'll post it ASAP. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKq78OForvXbEpPzQRAvwQAKCk4+jKFEmHIyjstvCeRvGrnkybAQCfTs+o RG/GjAuDr9gMnGlwZQJ6G10= =DogF -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 15:42:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FCAA106568B; Sat, 12 Sep 2009 15:42:36 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 001718FC12; Sat, 12 Sep 2009 15:42:35 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D9FDC730DA; Sat, 12 Sep 2009 17:48:36 +0200 (CEST) Date: Sat, 12 Sep 2009 17:48:36 +0200 From: Luigi Rizzo To: John Baldwin Message-ID: <20090912154836.GA47410@onelab2.iet.unipi.it> References: <4A93BF0C.8040601@web.de> <200909111123.00257.jhb@freebsd.org> <20090911170317.GA33232@onelab2.iet.unipi.it> <200909111301.55692.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200909111301.55692.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Juergen Lock , Avi Kivity , qemu-devel@nongnu.org, freebsd-current@freebsd.org, Jan Kiszka , Mohammed Gamal Subject: Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 15:42:36 -0000 On Fri, Sep 11, 2009 at 01:01:54PM -0400, John Baldwin wrote: > On Friday 11 September 2009 1:03:17 pm Luigi Rizzo wrote: ... > > Note that the per-cpu ticks i was proposing were only visible to the > > timing wheels, which don't use absolute timeouts anyways. > > So i think the mechanism would be quite safe: right now, when you > > request a callout after x ticks, the code first picks a CPU > > (with some criteria), then puts the request in the timer wheel for > > that CPU using (now) the global 'ticks'. Replacing ticks with cc->cc_ticks, > > would completely remove the races in insertion and removal. > > > > I actually find the per-cpu ticks even less intrusive than this change. > > Well, it depends. If TCP ever started using per-CPU callouts (i.e. > callout_reset_on()) It seems that this is already the case in practice. callout_reset() is just #defined to callout_reset_on(c, ... c->cc_cpu) so all calls end up there. c->cc_cpu is initialized in callout_init as c->c_cpu = timeout_cpu; (which is a static int variable; i still don't understand what is the final value it gets, because the comment says that kern_timeout_callwheel_alloc() can be called multiple times and here is where timeout_cpu is initialized.) cheers luigi From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 16:53:55 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C92AC1065696 for ; Sat, 12 Sep 2009 16:53:55 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 5917B8FC16 for ; Sat, 12 Sep 2009 16:53:55 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 5D51C1E0029B; Sat, 12 Sep 2009 18:53:54 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n8CGqO49038209; Sat, 12 Sep 2009 18:52:24 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id n8CGqNpg038208; Sat, 12 Sep 2009 18:52:23 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 12 Sep 2009 18:52:22 +0200 To: Jan Kiszka Message-ID: <20090912165222.GA38048@triton8.kn-bremen.de> References: <20090911213508.GA97446@triton8.kn-bremen.de> <4AAB938B.9080004@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AAB938B.9080004@web.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= , freebsd-current@FreeBSD.org, Juergen Lock , qemu-devel@nongnu.org Subject: Re: qemu serial: lost tx irqs (affectig FreeBSD's new uart(4) driver) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 16:53:56 -0000 On Sat, Sep 12, 2009 at 02:26:51PM +0200, Jan Kiszka wrote: > Juergen Lock wrote: > > Hi! > > > > I got a report of FreeBSD guest's new uart(4) driver misbehaving in > > qemu again(?) (output stopping for no apparent reason), and now found > > out the problem is tx irqs (UART_IIR_THRI) are getting lost because > > serial_update_irq() checks for the rx condtion, > > ... if ((s->ier & UART_IER_RDI) && (s->lsr & UART_LSR_DR)) > > first before checking for the tx irq condition, > > ... if ((s->ier & UART_IER_THRI) && s->thr_ipending) > > which at least in this case (FreeBSD 8 guest after doing > > set console="comconsole" > > at the loader prompt or when simply echo'ing text to /dev/ttyu0 > > or typing to the serial port from cu(1) on a `regular' vga console) > > causes the second condition (.. && s->thr_ipending) to be never > > reached anymore, or only after a very long delay. Moving that > > condition up so it is checked first like this, > > > > Index: qemu/hw/serial.c > > @@ -189,7 +188,9 @@ static void serial_update_irq(SerialStat > > { > > uint8_t tmp_iir = UART_IIR_NO_INT; > > > > - if ((s->ier & UART_IER_RLSI) && (s->lsr & UART_LSR_INT_ANY)) { > > + if ((s->ier & UART_IER_THRI) && s->thr_ipending) { > > + tmp_iir = UART_IIR_THRI; > > + } else if ((s->ier & UART_IER_RLSI) && (s->lsr & UART_LSR_INT_ANY)) { > > tmp_iir = UART_IIR_RLSI; > > } else if ((s->ier & UART_IER_RDI) && s->timeout_ipending) { > > /* Note that(s->ier & UART_IER_RDI) can mask this interrupt, > > @@ -202,8 +203,6 @@ static void serial_update_irq(SerialStat > > } else if (s->recv_fifo.count >= s->recv_fifo.itl) { > > tmp_iir = UART_IIR_RDI; > > } > > - } else if ((s->ier & UART_IER_THRI) && s->thr_ipending) { > > - tmp_iir = UART_IIR_THRI; > > } else if ((s->ier & UART_IER_MSI) && (s->msr & UART_MSR_ANY_DELTA)) { > > tmp_iir = UART_IIR_MSI; > > } > > > > ...fixes the issue for me, but I'm not 100% sure if this might cause > > rx irqs to come (too?) late when a guest keeps sending while its > > receiving at the same time. Anyone care to comment? :) > > The reordering violates the 16550A spec in that RX event overrules TX in > the IRQ status register. Maybe something else is wrong but it's not the > ordering in serial_update_irq. Well one problem seems to be the rx condition, ... if ((s->ier & UART_IER_RDI) && (s->lsr & UART_LSR_DR)) is not enough to trigger an irq, yet still causes the following conditions not to be checked anymore at all. And ideed, fixing that seems to get my FreeBSD 8 guest back to working order as well: Index: qemu/hw/serial.c @@ -196,12 +195,10 @@ static void serial_update_irq(SerialStat * this is not in the specification but is observed on existing * hardware. */ tmp_iir = UART_IIR_CTI; - } else if ((s->ier & UART_IER_RDI) && (s->lsr & UART_LSR_DR)) { - if (!(s->fcr & UART_FCR_FE)) { - tmp_iir = UART_IIR_RDI; - } else if (s->recv_fifo.count >= s->recv_fifo.itl) { - tmp_iir = UART_IIR_RDI; - } + } else if ((s->ier & UART_IER_RDI) && (s->lsr & UART_LSR_DR) && + (!(s->fcr & UART_FCR_FE) || + s->recv_fifo.count >= s->recv_fifo.itl)) { + tmp_iir = UART_IIR_RDI; } else if ((s->ier & UART_IER_THRI) && s->thr_ipending) { tmp_iir = UART_IIR_THRI; } else if ((s->ier & UART_IER_MSI) && (s->msr & UART_MSR_ANY_DELTA)) { Signed-off-by: Juergen Lock From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 18:01:12 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F06801065698 for ; Sat, 12 Sep 2009 18:01:12 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id A81BF8FC32 for ; Sat, 12 Sep 2009 18:01:12 +0000 (UTC) Received: from [89.178.148.191] (port=12364 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmWNH-0002Lt-3C for current@freebsd.org; Sat, 12 Sep 2009 21:26:59 +0400 Message-ID: <4AABD9E2.4030704@lissyara.su> Date: Sat, 12 Sep 2009 21:26:58 +0400 From: Alex Keda User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: Subject: make installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 18:01:13 -0000 I have problem, some as http://lists.freebsd.org/pipermail/freebsd-current/2009-June/007604.html if I install as: make -d A installworld I have ........... Searching for be_BY.UTF-8.msg.../usr/src/lib/libc.../usr/src/lib/libc/db/btree.../usr/src/lib/libc/db/db.../usr/src/lib/libc/db/hash.../usr/src/lib/libc/db/man.../usr/src/lib/libc/db/mpool.../usr/src/lib/libc/db/recno.../usr/src/lib/libc/compat-43.../usr/src/lib/libc/gdtoa.../usr/src/lib/libc/i386/gen.../usr/src/lib/libc/gen.../usr/src/lib/libc/gmon.../usr/src/lib/libc/inet.../usr/src/lib/libc/isc.../usr/src/lib/libc/locale.../usr/src/lib/libc/nameser.../usr/src/lib/libc/net.../usr/src/lib/libc/nls...here...returning /usr/src/lib/libc/nls/be_BY.UTF-8.msg be_BY.UTF-8.msg:@ = /usr/src/lib/libc/nls/be_BY.UTF-8.msg be_BY.UTF-8.msg:* = be_BY.UTF-8 be_BY.UTF-8.cat:< = /usr/src/lib/libc/nls/be_BY.UTF-8.msg Examining be_BY.UTF-8.msg...modified 19:48:32 Jul 03, 2009...up-to-date. Examining be_BY.UTF-8.cat...modified 21:21:15 Feb 27, 2009...modified before source (/usr/src/lib/libc/nls/be_BY.UTF-8.msg)...out-of-date. be_BY.UTF-8.cat:> = /usr/src/lib/libc/nls/be_BY.UTF-8.msg be_BY.UTF-8.cat:? = /usr/src/lib/libc/nls/be_BY.UTF-8.msg gencat be_BY.UTF-8.cat /usr/src/lib/libc/nls/be_BY.UTF-8.msg gencat:No such file or directory *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. HP2133# From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 18:15:58 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4B1110656C0 for ; Sat, 12 Sep 2009 18:15:58 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3238FC20 for ; Sat, 12 Sep 2009 18:15:58 +0000 (UTC) Received: from [89.178.148.191] (port=54321 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmX8e-000Cxn-Oj for current@freebsd.org; Sat, 12 Sep 2009 22:15:56 +0400 Message-ID: <4AABE559.1030609@lissyara.su> Date: Sat, 12 Sep 2009 22:15:53 +0400 From: Alex Keda User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: FreeBSD Current References: <4AABD9E2.4030704@lissyara.su> In-Reply-To: <4AABD9E2.4030704@lissyara.su> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: Subject: Re: make installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 18:15:58 -0000 Alex Keda пишет: > I have problem, some as > http://lists.freebsd.org/pipermail/freebsd-current/2009-June/007604.html > if I install as: > make -d A installworld > I have > ........... > Searching for > be_BY.UTF-8.msg.../usr/src/lib/libc.../usr/src/lib/libc/db/btree.../usr/src/lib/libc/db/db.../usr/src/lib/libc/db/hash.../usr/src/lib/libc/db/man.../usr/src/lib/libc/db/mpool.../usr/src/lib/libc/db/recno.../usr/src/lib/libc/compat-43.../usr/src/lib/libc/gdtoa.../usr/src/lib/libc/i386/gen.../usr/src/lib/libc/gen.../usr/src/lib/libc/gmon.../usr/src/lib/libc/inet.../usr/src/lib/libc/isc.../usr/src/lib/libc/locale.../usr/src/lib/libc/nameser.../usr/src/lib/libc/net.../usr/src/lib/libc/nls...here...returning > /usr/src/lib/libc/nls/be_BY.UTF-8.msg > be_BY.UTF-8.msg:@ = /usr/src/lib/libc/nls/be_BY.UTF-8.msg > be_BY.UTF-8.msg:* = be_BY.UTF-8 > be_BY.UTF-8.cat:< = /usr/src/lib/libc/nls/be_BY.UTF-8.msg > Examining be_BY.UTF-8.msg...modified 19:48:32 Jul 03, 2009...up-to-date. > Examining be_BY.UTF-8.cat...modified 21:21:15 Feb 27, 2009...modified > before source (/usr/src/lib/libc/nls/be_BY.UTF-8.msg)...out-of-date. > be_BY.UTF-8.cat:> = /usr/src/lib/libc/nls/be_BY.UTF-8.msg > be_BY.UTF-8.cat:? = /usr/src/lib/libc/nls/be_BY.UTF-8.msg > gencat be_BY.UTF-8.cat /usr/src/lib/libc/nls/be_BY.UTF-8.msg > gencat:No such file or directory > *** Error code 1 > > Stop in /usr/src/lib/libc. > *** Error code 1 > > Stop in /usr/src/lib. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > HP2133# make -f Makefile.inc1 install work correct From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 18:17:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C89B1065696 for ; Sat, 12 Sep 2009 18:17:42 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 53D588FC1B for ; Sat, 12 Sep 2009 18:17:42 +0000 (UTC) Received: from [89.178.148.191] (port=15711 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmXAL-000DKP-9c for current@freebsd.org; Sat, 12 Sep 2009 22:17:41 +0400 Message-ID: <4AABE5C4.20703@lissyara.su> Date: Sat, 12 Sep 2009 22:17:40 +0400 From: Alex Keda User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: FreeBSD Current References: <4AABD9E2.4030704@lissyara.su> In-Reply-To: <4AABD9E2.4030704@lissyara.su> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: Subject: Re: make installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 18:17:42 -0000 Alex Keda пишет: > I have problem, some as > http://lists.freebsd.org/pipermail/freebsd-current/2009-June/007604.html > if I install as: > make -d A installworld > I have > ........... > Searching for > be_BY.UTF-8.msg.../usr/src/lib/libc.../usr/src/lib/libc/db/btree.../usr/src/lib/libc/db/db.../usr/src/lib/libc/db/hash.../usr/src/lib/libc/db/man.../usr/src/lib/libc/db/mpool.../usr/src/lib/libc/db/recno.../usr/src/lib/libc/compat-43.../usr/src/lib/libc/gdtoa.../usr/src/lib/libc/i386/gen.../usr/src/lib/libc/gen.../usr/src/lib/libc/gmon.../usr/src/lib/libc/inet.../usr/src/lib/libc/isc.../usr/src/lib/libc/locale.../usr/src/lib/libc/nameser.../usr/src/lib/libc/net.../usr/src/lib/libc/nls...here...returning > /usr/src/lib/libc/nls/be_BY.UTF-8.msg > be_BY.UTF-8.msg:@ = /usr/src/lib/libc/nls/be_BY.UTF-8.msg > be_BY.UTF-8.msg:* = be_BY.UTF-8 > be_BY.UTF-8.cat:< = /usr/src/lib/libc/nls/be_BY.UTF-8.msg > Examining be_BY.UTF-8.msg...modified 19:48:32 Jul 03, 2009...up-to-date. > Examining be_BY.UTF-8.cat...modified 21:21:15 Feb 27, 2009...modified > before source (/usr/src/lib/libc/nls/be_BY.UTF-8.msg)...out-of-date. > be_BY.UTF-8.cat:> = /usr/src/lib/libc/nls/be_BY.UTF-8.msg > be_BY.UTF-8.cat:? = /usr/src/lib/libc/nls/be_BY.UTF-8.msg > gencat be_BY.UTF-8.cat /usr/src/lib/libc/nls/be_BY.UTF-8.msg > gencat:No such file or directory > *** Error code 1 > > Stop in /usr/src/lib/libc. > *** Error code 1 > > Stop in /usr/src/lib. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > HP2133# So, I have incorrect time on machine HP2133# ntpdate ntp.ru 12 Sep 22:15:23 ntpdate[26877]: step time server 193.124.11.11 offset 17001417.656556 sec HP2133# now, I rebuild world. may be it's problem... > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 18:51:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5916106566B; Sat, 12 Sep 2009 18:51:03 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id B9B918FC0C; Sat, 12 Sep 2009 18:51:03 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n8CIp1OK017936; Sat, 12 Sep 2009 11:51:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 12 Sep 2009 11:50:52 -0700 Message-ID: In-Reply-To: <19c32ef4263ed3c2ab1624a43ae86c78.squirrel@email.polands.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NFS issues on 8.0-BETA4 Thread-Index: AcoztxUv2JquA1NTSJGTKEOhBVZWHgAIsefg References: <9ef3bf09fa0e081eca3965e3f0e84f82.squirrel@email.polands.org> <19c32ef4263ed3c2ab1624a43ae86c78.squirrel@email.polands.org> From: "Li, Qing" To: "Doug Poland" , "Rick Macklem" Cc: freebsd-stable@freebsd.org, FreeBSD Current , Andrzej Tobola Subject: RE: NFS issues on 8.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 18:51:03 -0000 Hi Doug, > > > Simply adding -o udp to my mount command made the NFS mount work > correctly. Qing, would it be beneficial to attempt the patch in light > of these findings? >=20 Have you tried the patch that I sent you privately? Does it work for you? Thanks, -- Qing From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 19:12:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F083D10656A5; Sat, 12 Sep 2009 19:12:08 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206049004.chello.pl [87.206.49.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3E31D8FC15; Sat, 12 Sep 2009 19:12:07 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 83F8E45C98; Sat, 12 Sep 2009 21:12:06 +0200 (CEST) Received: from localhost (chello087206049004.chello.pl [87.206.49.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4A1504569A; Sat, 12 Sep 2009 21:12:01 +0200 (CEST) Date: Sat, 12 Sep 2009 21:11:58 +0200 From: Pawel Jakub Dawidek To: Kris Kennaway Message-ID: <20090912191158.GA2091@garage.freebsd.pl> References: <4AA40E30.50109@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <4AA40E30.50109@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Jaakko Heinonen , Kip Macy , FreeBSD Current Subject: Re: panic: sx_xlock() of destroyed sx @ /zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c:535 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 19:12:09 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 06, 2009 at 08:32:00PM +0100, Kris Kennaway wrote: > 9.0 doing I/O to a zfs: >=20 > panic: sx_xlock() of destroyed sx @=20 > /zoo/kris/src8/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/= fs/zfs/zfs_rlock.c:535 > db> wh > Tracing pid 14 tid 100047 td 0xffffff000357c720 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x17b > _sx_xlock() at _sx_xlock+0xe9 > zfs_range_unlock() at zfs_range_unlock+0x38 > zfs_get_data() at zfs_get_data+0xd7 > zil_commit() at zil_commit+0x532 > zfs_sync() at zfs_sync+0xa6 > sync_fsync() at sync_fsync+0x13a > VOP_FSYNC_APV() at VOP_FSYNC_APV+0xb7 > sync_vnode() at sync_vnode+0x157 > sched_sync() at sched_sync+0x1d1 > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff8125da0d30, rbp =3D 0 --- >=20 > This was essentially just doing make world + cvs update + tar creation=20 > in a loop and failed after about a week. Ok, here is a patch to try: http://people.freebsd.org/~pjd/patches/zfs_races.patch Actually I think I'll just commit it as I was able to reproduce and understand your problem. The patch fixes three races: - The check to see that we lost race in zfs_zget() wasn't tight enough. This was found by Jaakko Heinonen and part of the patch is based on his work. - There was a race where rollback could be called between zfs_freebsd_reclaim() and zfs_reclaim_complete(). - There was a race where forced unmount could be called between zfs_freebsd_reclaim() and zfs_reclaim_complete(). --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKq/J+ForvXbEpPzQRAvq1AKCQv76of165XEVM1UogksBvYJjMoACg5DQF odE/ziQRpYGrHvWi0HMzKY4= =85gN -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 20:34:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2451C106566B for ; Sat, 12 Sep 2009 20:34:27 +0000 (UTC) (envelope-from pj@smo.de) Received: from mail.ilk.de (mx-out20.ilk.de [194.121.104.20]) by mx1.freebsd.org (Postfix) with ESMTP id 8B52B8FC08 for ; Sat, 12 Sep 2009 20:34:26 +0000 (UTC) Received: from bologna.intern.smo.de (pool33.ka.ilk.net [212.86.194.33]) by mail.ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id n8CKYLZP007900; Sat, 12 Sep 2009 22:34:21 +0200 Received: from [192.168.153.208] (herdubreid.intern.smo.de [192.168.153.208]) by bologna.intern.smo.de (8.13.8+Sun/8.13.8) with ESMTP id n8CKY6Qd026942; Sat, 12 Sep 2009 22:34:06 +0200 (CEST) Message-ID: <4AAC0626.9070806@smo.de> Date: Sat, 12 Sep 2009 22:35:50 +0200 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20090802 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: Bruce Cran References: <4AAABBCB.8050302@smo.de> <20090912043408.00000f6d@unknown> In-Reply-To: <20090912043408.00000f6d@unknown> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090901010403050107070506" Cc: FreeBSD Current Subject: Re: [BETA2] Floppy drive no longer accessible X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 20:34:27 -0000 This is a cryptographically signed message in MIME format. --------------ms090901010403050107070506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce Cran wrote: > On Fri, 11 Sep 2009 23:06:19 +0200 > Philipp Ost wrote: > > >>Hi guys, >> >>I'm running 8.0-BETA2 (i386) and have some problems concerning my >>floppy drive -- it's no longer accessible because there's no entry >>in /dev: >> >>$ find /dev -name \*fd\* >>/dev/fd >>$ > > > There was a regression in the ACPI code that was fixed after 8.0-BETA2 > - see the thread "fdc(4) regression: fdc0 fails to probe" for details. Now, this is something I'm really uncomfortable with as I actually have read that particular thread. Thanks for heads-up anyway. In the meantime I updated my system to BETA4 and everything is running fine so far. Sorry for the noise, Philipp --------------ms090901010403050107070506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQEjCC BP8wggLnoAMCAQICAwCHRzANBgkqhkiG9w0BAQUFADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5j LjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xh c3MgMyBSb290MB4XDTA5MDgwOTE5MDkxMFoXDTExMDgwOTE5MDkxMFowODEcMBoGA1UEAxMT UGhpbGlwcC1Kb2FjaGltIE9zdDEYMBYGCSqGSIb3DQEJARYJcGpAc21vLmRlMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHi5tzklVWnzS24cGcYFZYdq86t0pnwjP5Bp1dWX TuY8qU7i1gzCPWvHmmjicyKjwPOWN3ciM0pnhQK6NMqA1xf3OL9tLtETF/eC5Ey3oW0Lsoex jtOmeBfXxdd4o+41UkRx/vS5TWtHa3JILrBS71N34HK8RcPGlb/chw/XMX1atYbOEIg4fsaH IXsh87WNLEhMtTStUeDmRcx0lEZ11QhWJaJDlBmmbsFPZ70FbjnHVaFbZzZhWKJ8FSWgmYok 6Cibopn/Jpin4fYY7jnH/l6jlTipNEbFErMvfwdg8RQp0CHlwwH68O+Ejfb5JaPrkxl19H0p ZKhuBePQNVqqmwIDAQABo4H1MIHyMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1Rv IGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDov L3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGC NwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw AYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAUBgNVHREEDTALgQlwakBzbW8uZGUwDQYJKoZI hvcNAQEFBQADggIBAFjI0W2tTQ05mECbiTOz3Gi8tielpXmHyXeiQVCJPM/JaLV4yytUAQjf NoK0shJn52sVuvh0ZlvbD+o7XCSOGvq87Jt2mBLiQs8SAKc/SvyjNYSX+8pM1/wQ/EcJ5yNw vnkDCK5yvqIB8ItCIayeE6ybUZ1ga/HVIBfPSs+qPlajTYhaFMYk/QGQ2o8gwDTv08qizHnu iei2zOB/+dqFmBfAxxEnvOSWzmLr6ylAPMOfrOzkji803fwDjFVbAqpS5dfjCZsKm2dB6hzW uJRM0CpdY4jf5Ci3fCt1gSPnUOdOUC/FXuPmVeHccrfJpH9W0fyhG4MnoRqou/LpkbD4DEp+ +a0oaX4WvOXsXIqdZy/lpiFBtsI+easHmLZYVq9eEAz3vsX3zeFF3v6sY7UOOvxEiMFm1Y4W Ioh7gF4BQWUAi48gwlJYg/xtqQ3vdZhPvwGcIhqbkbxLAmaHjV3Nbrbo+p+xzDEv5CzQBwy6 MIe2TUfRjHymA3r2drx2Z/cLWRDgpzuKhnul6sDnkLVXFPP9Jidy7joSlndIjrJFR4+F3xfw 7tDHa1WHuGW5QGItblpG6bb34dxq9C1MGcMjMcIP7xYPGbjjUPZzPxT64T/jpzP2MoefRz4I M/8LKt8iMASoTaUUxwIGFZ87yU0k+fD7hZm7ZUkba77kDi7R+BsaMIIE/zCCAuegAwIBAgID AIdHMA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVo dHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwHhcN MDkwODA5MTkwOTEwWhcNMTEwODA5MTkwOTEwWjA4MRwwGgYDVQQDExNQaGlsaXBwLUpvYWNo aW0gT3N0MRgwFgYJKoZIhvcNAQkBFglwakBzbW8uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCseLm3OSVVafNLbhwZxgVlh2rzq3SmfCM/kGnV1ZdO5jypTuLWDMI9a8ea aOJzIqPA85Y3dyIzSmeFAro0yoDXF/c4v20u0RMX94LkTLehbQuyh7GO06Z4F9fF13ij7jVS RHH+9LlNa0drckgusFLvU3fgcrxFw8aVv9yHD9cxfVq1hs4QiDh+xocheyHztY0sSEy1NK1R 4OZFzHSURnXVCFYlokOUGaZuwU9nvQVuOcdVoVtnNmFYonwVJaCZiiToKJuimf8mmKfh9hju Ocf+XqOVOKk0RsUSsy9/B2DxFCnQIeXDAfrw74SN9vklo+uTGXX0fSlkqG4F49A1WqqbAgMB AAGjgfUwgfIwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3du IGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5v cmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2Nz cC5jYWNlcnQub3JnMBQGA1UdEQQNMAuBCXBqQHNtby5kZTANBgkqhkiG9w0BAQUFAAOCAgEA WMjRba1NDTmYQJuJM7PcaLy2J6WleYfJd6JBUIk8z8lotXjLK1QBCN82grSyEmfnaxW6+HRm W9sP6jtcJI4a+rzsm3aYEuJCzxIApz9K/KM1hJf7ykzX/BD8RwnnI3C+eQMIrnK+ogHwi0Ih rJ4TrJtRnWBr8dUgF89Kz6o+VqNNiFoUxiT9AZDajyDANO/TyqLMee6J6LbM4H/52oWYF8DH ESe85JbOYuvrKUA8w5+s7OSOLzTd/AOMVVsCqlLl1+MJmwqbZ0HqHNa4lEzQKl1jiN/kKLd8 K3WBI+dQ505QL8Ve4+ZV4dxyt8mkf1bR/KEbgyehGqi78umRsPgMSn75rShpfha85excip1n L+WmIUG2wj55qweYtlhWr14QDPe+xffN4UXe/qxjtQ46/ESIwWbVjhYiiHuAXgFBZQCLjyDC UliD/G2pDe91mE+/AZwiGpuRvEsCZoeNXc1utuj6n7HMMS/kLNAHDLowh7ZNR9GMfKYDevZ2 vHZn9wtZEOCnO4qGe6XqwOeQtVcU8/0mJ3LuOhKWd0iOskVHj4XfF/Du0MdrVYe4ZblAYi1u Wkbptvfh3Gr0LUwZwyMxwg/vFg8ZuONQ9nM/FPrhP+OnM/Yyh59HPggz/wsq3yIwBKhNpRTH AgYVnzvJTST58PuFmbtlSRtrvuQOLtH4GxowggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEB BAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1NVoXDTMzMDMyODA3MzY1NVowVDEU MBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEc MBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCC AgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++tykA10oZZkq5+gJJlz 2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUoqMV5CX1GuYrz 6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+lzNZ6MMD PWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rVO5J+ TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luL oFvqTpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQo cDggL9V/KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNj VSKRPFbnr9s6JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2v jBDTn8Rq+G8T/HNZ92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/ BAUwAwEB/zBdBggrBgEFBQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2Vy dC5vcmcvMCgGCCsGAQUFBzAChhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1Ud IARDMEEwPwYIKwYBBAGBkEowMzAxBggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3Jn L2luZGV4LnBocD9pZD0xMDANBgkqhkiG9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivce xDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KRwpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXB PohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueTuYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5E HMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86QfHjL8JxUFz90urj6CYXvwIRAY9kTq Uzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEiqogwAOKw1Ly+ZbrVA1d5m+jc yE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUKbL8Xx3JGV5yY9WxgY3pv XrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAXpS0Q65x6Sr297s79 7SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpWYwBkuV2kYn1X Nk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bjoVlX93Gy xG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HSbqUb mSeA5wupqAAxggMeMIIDGgIBATBbMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QC AwCHRzAJBgUrDgMCGgUAoIIBmDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wOTA5MTIyMDM1NTBaMCMGCSqGSIb3DQEJBDEWBBTiMk2YdlY6ZtxNjb2hwGIo 4C3dQTBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwagYJKwYB BAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3 dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMAh0cwbAYLKoZI hvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8v d3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAwCHRzANBgkq hkiG9w0BAQEFAASCAQA9JQ/48aojs8UMlxVup6J1/MyCLqwmMnBxIH69XRw6OdoXUUoopq2M 6DZfzukHc3mxEGsKAQo2TGhlt9X9bHkkMIUtgdA+J+5lqMN1TAdmot04Ux4C+va2rajNjouf Y2syeFdjQ1mZweGdiDv1PyWAyn7j0YWbg8rMk6JKRsIB3N6Ja4OHKZhN3r+96CeWG3XxoQkU 1nbDvHJCz5kahaQOeDwnu2pOducij/T61uCVU64QLkW+XDQn2qslwMDOZNktznU1VVKqAEgy QenNN43T6fmiKfWjNrtCUZxGU2zvMOFVAK8OQ66wZGxryKYBXiBgAI5bwx6SrG4c8fK/DbXa AAAAAAAA --------------ms090901010403050107070506-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 12 22:09:44 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54354106566C for ; Sat, 12 Sep 2009 22:09:44 +0000 (UTC) (envelope-from vinnix.bsd@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id 127D28FC0C for ; Sat, 12 Sep 2009 22:09:43 +0000 (UTC) Received: by an-out-0708.google.com with SMTP id d14so812290and.13 for ; Sat, 12 Sep 2009 15:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kphN+nKiV+x5q+8uBYuZaLovAybPXOlfrlYhV+sLVAs=; b=k6Gf+LR6K0IwRiJi34wMHOkxWaSSd58GK1/31A1JcAMXwZ1zPuD67NHQzIVEpq3t1J l/LLQXekFU5ZN+FosRYJgDeLu++96ohQY2NgCILuGhebEZ1HKAcEXaxyUAQPnJMpoNXj J6Bxuo9M3lrBSC7AMHUqw29PP0dF86pE2OQ04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BwbzoSJE6WPC3e86fqUX7SfU9KxAokpsKwzo0/kIRSxmj+bEXv1tr2UwhoSkgjj1Mk GHuejbQpqNS46fz3pSdnoWXnoi+Q6xtPUKinfujV22MXhzWPLfilnESU+WRFjBZ208P6 e1VhOv5nwcbB3JDK2hYkbwFjlbQabJutn5O1g= MIME-Version: 1.0 Received: by 10.101.127.10 with SMTP id e10mr4994227ann.85.1252791519281; Sat, 12 Sep 2009 14:38:39 -0700 (PDT) In-Reply-To: <20090909181620.GA19090@e.0x20.net> References: <20090908201713.GD41185@e.0x20.net> <20090909104528.20b28e65@ernst.jennejohn.org> <20090909181620.GA19090@e.0x20.net> Date: Sat, 12 Sep 2009 18:38:39 -0300 Message-ID: <1e31c7980909121438p6389820fte3923b4c9c9729e8@mail.gmail.com> From: Vinicius Abrahao To: Lars Engels Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: CFH: fix multimedia/pwcbsd with usb2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 22:09:44 -0000 Hi Guys, Thanks for hard work with pwcbsd. Now the port is compile here at 9.0-current, but I'm have some trouble to load the module: KLD pwc.ko: depends on kernel - not available or version mismatch linker_load_file: Unsupported file type using the 9.0-CURRENT #16: Sun Sep 6 10:40:56 BRT 2009 . Any ideas? Thanks a lot, Vinicius On Wed, Sep 9, 2009 at 3:16 PM, Lars Engels wrote: > Gary, > > thanks a lot for the patches! pwcbsd compiles and my cam is showing > wonderful pictures (as long as I am not in front of it ;-) ). > I just commited the new port version, so have fun with your cams, > everbody! > > Lars >