From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 04:14: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 9C35A106564A for ; Sun, 12 Apr 2009 04:14:02 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4DC3B8FC1A for ; Sun, 12 Apr 2009 04:14:02 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n3C4E1Rk053004; Sat, 11 Apr 2009 21:14:01 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id d2jckg3dvg5jcbirzcdpeq3kri; Sat, 11 Apr 2009 21:14:01 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <49E16A89.3030108@freebsd.org> Date: Sat, 11 Apr 2009 21:14:01 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090409 SeaMonkey/1.1.15 MIME-Version: 1.0 To: John Nielsen References: <200903100104.53847.ken__6247.10998167775$1236647281$gmane$org@mthelicon.com> <200903102310.32735.lists@jnielsen.net> <49B73F99.9010200@freebsd.org> <200903112229.41052.lists@jnielsen.net> In-Reply-To: <200903112229.41052.lists@jnielsen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ZFS/extattr lockup (was Re: bsdtar lockup on Current-03/10/2009) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 04:14:02 -0000 John Nielsen wrote: > On Wednesday 11 March 2009 12:35:37 am Tim Kientzle wrote: >> John Nielsen wrote: >>> I today noticed the same problem on -CURRENT i386 built March 9. >>> ... using ZFS and initially >>> thought that was the source of the regression but I haven't produced >>> the lockup with anything but tar and the extattr removal hack seems >>> to have fixed it for now ... >> The common element so far seems to be ZFS. Can you verify that >> >> $ lsextattr -h user >> >> hangs on your system as well? That invokes the same >> extattr_list_link system call used by tar to enumerate >> the extended attributes on a file. > > Confirmed. I ran the command on a file in /root (UFS) with no problem. > Running again on a file in /home/john (ZFS) caused the hang. John Baldwin committed a fix for the ZFS problem (r189967, 2009-03-18 16:19:44UTC), so this should be fixed. Could you verify that lsextattr no longer hangs the kernel after this point? Could you verify that re-enabling extended attribute archiving in tar no longer hangs? I'd like to enable the extended attribute support in tar for real if this is really fixed. Thanks, Tim P.S. Here's the patch to enable extended attribute archiving in tar: Index: lib/libarchive/config_freebsd.h =================================================================== --- config_freebsd.h (revision 190954) +++ config_freebsd.h (working copy) @@ -34,12 +34,8 @@ #define HAVE_ACL_SET_FD_NP 1 #define HAVE_ACL_SET_FILE 1 #define HAVE_ACL_USER 1 -#if 0 -/* XXX Temporarily disable support for reading extended attributes from - * disk, as it seems to be badly broken on ZFS. XXX */ #define HAVE_EXTATTR_GET_FILE 1 #define HAVE_EXTATTR_LIST_FILE 1 -#endif #define HAVE_EXTATTR_SET_FD 1 #define HAVE_EXTATTR_SET_FILE 1 #define HAVE_SYS_ACL_H 1 From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 04:48:45 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71866106566B for ; Sun, 12 Apr 2009 04:48:45 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 0C36C8FC08 for ; Sun, 12 Apr 2009 04:48:44 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n3C4mZih068993; Sat, 11 Apr 2009 22:48:35 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49E172A3.2000108@samsco.org> Date: Sat, 11 Apr 2009 22:48:35 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Alan Cox References: <49E11CE7.5050903@cs.rice.edu> In-Reply-To: <49E11CE7.5050903@cs.rice.edu> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: current@freebsd.org Subject: Re: [Fwd: svn commit: r190949 - head/sys/vm] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 04:48:45 -0000 Off the top of my head, I would almost expect this to conflict with Java. Haven't tried it, though, so I can't do anything more than speculate. However, I would encourage testing here. Scott Alan Cox wrote: > It's possible that this could cause problems for "exotic" languages that > do their own memory management, i.e., they don't use libc's malloc(). > If anyone experiences or hears of such things, please let me know so > that we can get the problems sorted out well before the 8.0 release. > > Alan > > > ------------------------------------------------------------------------ > > Subject: > svn commit: r190949 - head/sys/vm > From: > Alan Cox > Date: > Sat, 11 Apr 2009 22:34:09 +0000 (UTC) > To: > src-committers@freebsd.org, svn-src-all@freebsd.org, > svn-src-head@freebsd.org > > To: > src-committers@freebsd.org, svn-src-all@freebsd.org, > svn-src-head@freebsd.org > > > Author: alc > Date: Sat Apr 11 22:34:08 2009 > New Revision: 190949 > URL: http://svn.freebsd.org/changeset/base/190949 > > Log: > Remove execute permission from the memory allocated by sbrk(). > > Pre-announced on: -arch (3/31/09) > Discussed with: rwatson > Tested by: marius (sparc64) > > Modified: > head/sys/vm/vm_unix.c > > Modified: head/sys/vm/vm_unix.c > ============================================================================== > --- head/sys/vm/vm_unix.c Sat Apr 11 22:07:19 2009 (r190948) > +++ head/sys/vm/vm_unix.c Sat Apr 11 22:34:08 2009 (r190949) > @@ -117,7 +117,7 @@ obreak(td, uap) > goto done; > } > rv = vm_map_insert(&vm->vm_map, NULL, 0, old, new, > - VM_PROT_ALL, VM_PROT_ALL, 0); > + VM_PROT_RW, VM_PROT_ALL, 0); > if (rv != KERN_SUCCESS) { > error = ENOMEM; > goto done; > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 04:58: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 421A4106566B for ; Sun, 12 Apr 2009 04:58:15 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 1CFE98FC14 for ; Sun, 12 Apr 2009 04:58:15 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id B5F5E2C2A91; Sat, 11 Apr 2009 23:58:14 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dxeuq4+R-SRp; Sat, 11 Apr 2009 23:58:07 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id D20E82C2ADC; Sat, 11 Apr 2009 23:58:06 -0500 (CDT) Message-ID: <49E174DE.90603@cs.rice.edu> Date: Sat, 11 Apr 2009 23:58:06 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: Scott Long References: <49E11CE7.5050903@cs.rice.edu> <49E172A3.2000108@samsco.org> In-Reply-To: <49E172A3.2000108@samsco.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: [Fwd: svn commit: r190949 - head/sys/vm] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 04:58:15 -0000 Scott Long wrote: > Off the top of my head, I would almost expect this to conflict with > Java. Haven't tried it, though, so I can't do anything more than > speculate. However, I would encourage testing here. > It doesn't. I verified that the Sun JVM works. Alan From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 05:52:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 875601065687 for ; Sun, 12 Apr 2009 05:52:42 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id E018A8FC1F for ; Sun, 12 Apr 2009 05:52:41 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n3C5qRMt001227 for ; Sun, 12 Apr 2009 00:52:27 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=Kkoq288JPkqVvd61g2Qmq95VIQ0H0oDEHKQu0KLaSUiIhHM9CWDnWMbHJ6nDb1BRo 5re8qIWOHPFzp3TayxEpr7aekvG2O+5YeRr82faM6KkWmr/O/Y1auOdX8ghUhrI0iJH sNgod0SeUFKIbX+R1XyrKROgzWwyQMV45HvlTQA= Message-ID: <49E1819B.7000604@jrv.org> Date: Sun, 12 Apr 2009 00:52:27 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: can't boot 5.5 TB GPT disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 05:52:43 -0000 FreeBSD bigback.housenet.jrv 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r190917: Sat Apr 11 19:48:25 CDT 2009 james@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 I can't boot a GPT partitioned 5.5 TB disc, where the UFS root partition is near the end of the disk. If I put another disk in the system and mount root from the GPT disk the system runs fine. The 5.5 TB disk is partitioned: bigback# gpart show => 34 11718748093 ad6 GPT (5.5T) 34 6 - free - (3.0K) 40 409600 1 efi (200M) 409640 11634190128 2 !6a898cc3-1dd2-11b2-99a6-080020736631 (5.4T) 11634599768 128 3 freebsd-boot (64K) 11634599896 4194304 4 freebsd-ufs (2.0G) 11638794200 33554432 5 freebsd-swap (16G) 11672348632 4194304 6 freebsd-ufs (2.0G) 11676542936 33554432 7 freebsd-ufs (16G) 11710097368 8388608 8 freebsd-ufs (4.0G) 11718485976 262151 - free - (128M) If I try to boot it (disk1 so pressing F5 here) it fails looking like this (there is no UART available so this is typed from a pic, with typos): F1 FreeBSD F5 Drive 1 Default: F1 BTX Loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 630kb/3136864kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (james@bigback.housenet.jrv, Sat Apr 11 08:19:00 CDT 2009 \ can't load 'kernel' Type '?' for a list of commands, 'help' for more details OK To get this far suggests to me that PMBR and GPTBOOT worked, and that the problem is elsewhere. Suggestions? Could there be a 32-bit truncation lurking in a loader somewhere? PS. Note that the "lsdev' command causes the loader to crash while printing out the info on the big disk, right after the EFI line for ad6p1... From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 15:03: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 E25CF106564A for ; Sun, 12 Apr 2009 15:03:47 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.43]) by mx1.freebsd.org (Postfix) with ESMTP id 7147C8FC16 for ; Sun, 12 Apr 2009 15:03:47 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [62.143.131.114] (helo=localhost) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Lt1Dm-0003mN-3Y; Sun, 12 Apr 2009 17:03:46 +0200 Date: Sun, 12 Apr 2009 17:03:35 +0200 From: Fabian Keil To: Maksim Yevmenkin Message-ID: <20090412170335.5a8a3169@fabiankeil.de> In-Reply-To: <200904082052.n38KqU9p075633@svn.freebsd.org> References: <200904082052.n38KqU9p075633@svn.freebsd.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/XF.egAMdjwX/4xA+pOVvpeE"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Df-Sender: 775067 Cc: freebsd-current@freebsd.org Subject: Re: svn commit: r190857 - head/sys/dev/kbdmux X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 15:03:48 -0000 --Sig_/XF.egAMdjwX/4xA+pOVvpeE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Maksim Yevmenkin wrote: > Author: emax > Date: Wed Apr 8 20:52:30 2009 > New Revision: 190857 > URL: http://svn.freebsd.org/changeset/base/190857 >=20 > Log: > Undo SVN rev 183283 > =20 > Do not use Giant for kbdmux(4) locking. This is wrong and apparently > causing more problems than it solves. This will re-open the issue > where interrupt handlers may race with kbdmux(4) in polling mode. > Typical symptoms include (but not limited to) duplicated and/or > missing characters when low level console functions (such as gets) > are used while interrupts are enabled (for example geli password > prompt, mountroot prompt etc.) > =20 > MFC after: 3 days >=20 > Modified: > head/sys/dev/kbdmux/kbdmux.c >=20 > Modified: head/sys/dev/kbdmux/kbdmux.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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/sys/dev/kbdmux/kbdmux.c Wed Apr 8 20:43:19 2009 (r190856) > +++ head/sys/dev/kbdmux/kbdmux.c Wed Apr 8 20:52:30 2009 (r190857) > @@ -104,10 +104,10 @@ MALLOC_DEFINE(M_KBDMUX, KEYBOARD_NAME, " > =20 > #define KBDMUX_LOCK_DESTROY(s) > =20 > -#define KBDMUX_LOCK(s) \ > - mtx_lock(&Giant) > -#define KBDMUX_UNLOCK(s) \ > - mtx_unlock(&Giant) > +#define KBDMUX_LOCK(s) > + > +#define KBDMUX_UNLOCK(s) > + > #define KBDMUX_LOCK_ASSERT(s, w) > =20 > #define KBDMUX_SLEEP(s, f, d, t) \ How about turning this into a compile-time or sysctl option or at least mentioning the change in /usr/src/UPDATING? With this commit, providing the geli key phrase on boot is impossible on my AMD64 dual core system. Not even enabling the "visible characters" option helps because obviously backspace is broken too. Before theses locks were introduces I worked around the problem with this gets() hack (which forced me to reduce the key entropy): http://www.fabiankeil.de/sourcecode/freebsd/gets-no-duplicates.diff and now I will simply revert your commit locally, but I assume I'm not the only geli user who prefers to be able to boot the system without local patches. Fabian --Sig_/XF.egAMdjwX/4xA+pOVvpeE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkniAtEACgkQBYqIVf93VJ3sowCfcIFWYNTuYq59ZHML1CnpeH78 WC8AnRh1Elv1zZ/lRpKQ46QJhz2skWiL =KY0+ -----END PGP SIGNATURE----- --Sig_/XF.egAMdjwX/4xA+pOVvpeE-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 16:48: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 E97851065670; Sun, 12 Apr 2009 16:48:38 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id CE9558FC0A; Sun, 12 Apr 2009 16:48:38 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.213.128] (jn@stealth.jnielsen.net [74.218.226.254]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id n3CGmaD1001878; Sun, 12 Apr 2009 12:48:38 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Sun, 12 Apr 2009 12:48:36 -0400 User-Agent: KMail/1.9.10 References: <200903100104.53847.ken__6247.10998167775$1236647281$gmane$org@mthelicon.com> <200903112229.41052.lists@jnielsen.net> <49E16A89.3030108@freebsd.org> In-Reply-To: <49E16A89.3030108@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904121248.36584.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Tim Kientzle Subject: Re: ZFS/extattr lockup (was Re: bsdtar lockup on Current-03/10/2009) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 16:48:39 -0000 On Sunday 12 April 2009 12:14:01 am Tim Kientzle wrote: > John Nielsen wrote: > > On Wednesday 11 March 2009 12:35:37 am Tim Kientzle wrote: > >> John Nielsen wrote: > >>> I today noticed the same problem on -CURRENT i386 built March 9. > >>> ... using ZFS and initially > >>> thought that was the source of the regression but I haven't > >>> produced the lockup with anything but tar and the extattr removal > >>> hack seems to have fixed it for now ... > >> > >> The common element so far seems to be ZFS. Can you verify that > >> > >> $ lsextattr -h user > >> > >> hangs on your system as well? That invokes the same > >> extattr_list_link system call used by tar to enumerate > >> the extended attributes on a file. > > > > Confirmed. I ran the command on a file in /root (UFS) with no > > problem. Running again on a file in /home/john (ZFS) caused the hang. > > John Baldwin committed a fix for the ZFS problem > (r189967, 2009-03-18 16:19:44UTC), so this should be fixed. > > Could you verify that lsextattr no longer hangs > the kernel after this point? > > Could you verify that re-enabling extended attribute > archiving in tar no longer hangs? > > I'd like to enable the extended attribute support > in tar for real if this is really fixed. Yes, I saw the commit and manually reverted libarchive to test on 3/20. I sent the post below but I don't know if it went through. Everything was solid then and has been since, so I think jhb's patch did the trick. JN ---------- Forwarded Message ---------- Subject: Re: repeatable ZFS panic: share->excl Date: Friday 20 March 2009 From: John Nielsen To: freebsd-current@freebsd.org On Wednesday 18 March 2009 12:09:18 pm John Baldwin wrote: > On Tuesday 17 March 2009 3:04:40 am Pawel Jakub Dawidek wrote: > > On Fri, Mar 13, 2009 at 02:08:03PM -0400, John Baldwin wrote: > > > John Baldwin wrote: > > > >Yes, I think that is the real bug. Looking at this further I > > > > think zfs_get_xattrdir() will return the vnode locked if it has > > > > to create a new node via zfs_make_attrdir() but only returns it > > > > held and unlocked if it finds an existing one. So my new patch > > > > is to just fix zfs_get_xattrdir() to unlock the vnode if it > > > > creates a new one like so: > > > > > > > >(Sorry, TBird is probably going to butcher all the whitespace): > > > > > > > >--- > > > >//depot/user/jhb/lock/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_d > >ir.c > > > > > >+++ > > > >/Users/jhb/work/p4/lock/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs > >_dir.c > > > > > >@@ -940,6 +940,7 @@ > > > > /* NB: we already did dmu_tx_wait() if necessary */ > > > > goto top; > > > > } > > > >+ VOP_UNLOCK(*xvpp, 0); > > > > > > > > return (error); > > > > } > > > > > > > >A non-butchered version is at > > > > www.FreeBSD.org/~jhb/patches/zfs_ea.patch. > > > > > > So lulf@ reports success with this patch. Pawel, can you review > > > it? > > > > Yes, it works for me too and looks good. The only thing we need to > > change is to check for error beeing 0 before unlocking the vnode. > > The zfs_make_xattrdir() function can still return with EIO, so I'd > > add something like this: > > > > if (error == 0) > > VOP_UNLOCK(*xvpp, 0); > > Yes, I realized this about 30 minutes after I sent this e-mail. :-P I > will commit a version with the error check today. > > > Thank you John for spending time on tracking this one down. > > Sure, was good to read a bit of the ZFS code. I had a chance to test this patch today and it looks good. Which is to say my system hasn't hung yet. :) I built world from 3/19 -HEAD and was able to "lsextattr -h user" on files on a ZFS without any ill effects. I un-patched libarchive (so it uses extended attributes again) and rebuilt and reinstalled it and bsdtar and was able to do portupgrades normally. Thanks to all involved. JN ------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 17:30: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 6E523106566C for ; Sun, 12 Apr 2009 17:30:54 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id CBC318FC14 for ; Sun, 12 Apr 2009 17:30:53 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by ewy19 with SMTP id 19so1706158ewy.43 for ; Sun, 12 Apr 2009 10:30:52 -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=DhFoGv+AEGyTEfqUCuiqUfghh3WnV3y7PxuoMi4oRxg=; b=BRMyoa1JHy02lHsXcWPPqVl7QpKlbPwTBPBa4U32BO+lRWrZfnn0QnGLMQ2ZpKPsVw xDjugARzX9sr9DasppoIFdP0caIdJF07uzb8rWejya8a/kT+rMga+q65XRL/LDr+NxO2 ag9NK2tN52RxtTmP11bLR23ppLe3X7PTbJZlI= 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=JE+1qAu9YhbEzTJAp+79RxRvB4pg1EnkU9v74FpZavoadCj3Hy/SAEcfQGyQyZ2tNO xBzPOsEtA6P84li/+HH2cDt1bvd0ceQAKCJ/ivcCCIGbKCVQasR/+6aMvzEOeN8/xSTw HVhjNk6Lts9QoC//7XYw+nsHPSF2JwbYH+OVo= MIME-Version: 1.0 Sender: maksim.yevmenkin@gmail.com Received: by 10.216.46.79 with SMTP id q57mr1324435web.212.1239555635089; Sun, 12 Apr 2009 10:00:35 -0700 (PDT) In-Reply-To: <20090412170335.5a8a3169@fabiankeil.de> References: <200904082052.n38KqU9p075633@svn.freebsd.org> <20090412170335.5a8a3169@fabiankeil.de> Date: Sun, 12 Apr 2009 10:00:35 -0700 X-Google-Sender-Auth: 8744dcb1db07f36d Message-ID: From: Maksim Yevmenkin To: Fabian Keil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: svn commit: r190857 - head/sys/dev/kbdmux X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 17:30:54 -0000 On Sun, Apr 12, 2009 at 8:03 AM, Fabian Keil wrote: > Maksim Yevmenkin wrote: > >> Author: emax >> Date: Wed Apr =A08 20:52:30 2009 >> New Revision: 190857 >> URL: http://svn.freebsd.org/changeset/base/190857 >> >> Log: >> =A0 Undo SVN rev 183283 >> >> =A0 Do not use Giant for kbdmux(4) locking. This is wrong and apparently >> =A0 causing more problems than it solves. This will re-open the issue >> =A0 where interrupt handlers may race with kbdmux(4) in polling mode. >> =A0 Typical symptoms include (but not limited to) duplicated and/or >> =A0 missing characters when low level console functions (such as gets) >> =A0 are used while interrupts are enabled (for example geli password >> =A0 prompt, mountroot prompt etc.) >> >> =A0 MFC after: =A03 days >> >> Modified: >> =A0 head/sys/dev/kbdmux/kbdmux.c [...] > How about turning this into a compile-time or sysctl option > or at least mentioning the change in /usr/src/UPDATING? i do not believe that compile-time nor sysctl option is the right choice here as it is never allowed to use locks in low-level keyboard drivers. entry in UPDATING is probably a good idea. > With this commit, providing the geli key phrase on > boot is impossible on my AMD64 dual core system. right, i really hate to say this, but the amount of bug reports, lor's etc.that were submitted after this change is far more (imo) than amount of people that ran relatively uncommon setup with encrypted root (which, btw, prompted the original commit). of course, there is no question, it has to be fixed. > Not even enabling the "visible characters" option helps > because obviously backspace is broken too. if you do not need kbdmix(4) you might just want to disable it on your system. i think it should help with your particular problem. > Before theses locks were introduces I worked around the problem > with this gets() hack (which forced me to reduce the key entropy): > http://www.fabiankeil.de/sourcecode/freebsd/gets-no-duplicates.diff > and now I will simply revert your commit locally, but I assume I'm > not the only geli user who prefers to be able to boot the system > without local patches. if your primary keyboard is atkbd(4), you might want to try the following patch. it is completely untested (i did not even compile it), so be warned ... Index: atkbd.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 --- atkbd.c (revision 190905) +++ atkbd.c (working copy) @@ -476,7 +476,7 @@ static int atkbd_intr(keyboard_t *kbd, void *arg) { - atkbd_state_t *state; + atkbd_state_t *state =3D (atkbd_state_t *)kbd->kb_data; int delay[2]; int c; @@ -485,7 +485,6 @@ * The keyboard was not detected before; * it must have been reconnected! */ - state =3D (atkbd_state_t *)kbd->kb_data; init_keyboard(state->kbdc, &kbd->kb_type, kbd->kb_config); KBD_FOUND_DEVICE(kbd); @@ -497,6 +496,9 @@ } if (KBD_IS_ACTIVE(kbd) && KBD_IS_BUSY(kbd)) { + if (state->ks_polling) + return 0; + /* let the callback function to process the input */ (*kbd->kb_callback.kc_func)(kbd, KBDIO_KEYINPUT, kbd->kb_callback.kc_arg); thanks, max From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 19:18: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 E8A8E1065679 for ; Sun, 12 Apr 2009 19:18:57 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 95E4B8FC1A for ; Sun, 12 Apr 2009 19:18:57 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so1090941ywh.13 for ; Sun, 12 Apr 2009 12:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=rDe8cfG+CrUIrXsJupdlSlmk2Ip6Jt6GRQ9JRSg9tCQ=; b=gX3JWCypk8bXiE3Rh3UHbRBdg5SKj5poSU8iGi2KLguYwFrdQttSD0h/OcLhVUS7pl 7O+L3nDzzFoWEa0RWQZXYMwDoGQ3kl7kWL00HIN7UqJCo/JFlkB0ld1DoVoCHOjBzkhK QUTkh/Uk4a0mUMGq8UqK7gMz5HkphDybM2/z4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=oDAp60SUzDWX2CIq2GDw8n1pHBZPboVZQRx5S0V51hkFVYlx17h53NELNesdNS36X2 kTmE2Vl0fK+J37hw1Y/jbme2vExg8IvoSy1FziX/yQvJIXNZAc/80kD6JxAO0HhTFT1Q zMDjdi+bcL8eRqPRySJIZGYz3RYxFtUGxojnw= Received: by 10.100.57.19 with SMTP id f19mr6166150ana.72.1239563936892; Sun, 12 Apr 2009 12:18:56 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.74.234]) by mx.google.com with ESMTPS id 4sm9178186yxd.36.2009.04.12.12.18.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 12 Apr 2009 12:18:56 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 5611DB8081; Sat, 11 Apr 2009 16:03:52 -0300 (BRT) Received: from 10.1.1.100 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Sat, 11 Apr 2009 16:03:52 -0300 (BRT) Message-ID: <4c84392f51488148040ecc5e99c9971b.squirrel@cygnus.homeunix.com> In-Reply-To: References: Date: Sat, 11 Apr 2009 16:03:52 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: ata and seagate microdrive problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 19:19:00 -0000 On Sat, April 11, 2009 15:29, Warren Block wrote: > On Thu, April 9, 2009 19:48, Nenhum_de_Nos wrote: >> >> I'm trying to install current on via itx using ide 44pin to cf >> adapter and a seagate 8GB microdrive. >> >> I thought it was to be ok, but just today when I received the adapter >> I got nowhere in this. I tried 7.1-STABLE and 8.0-CURRENT from >> 200902, and both fail to find it. the same thing in 7.1R. > > "Fail to find it" is a little vague. Is the CF card detected by the > BIOS? my bad, I forgot to say that. bios finds ok, I can install OpenBSD on it no problem. > Many CF-to-IDE adapters don't support DMA: > > http://lists.freebsd.org/pipermail/freebsd-small/2005-July/000441.html > > Lack of DMA support in the adapter results in errors, lots of them, > after the kernel boots. Disabling DMA as above fixed that on a 2G CF > card and CF-to-IDE adapter for me. I dit that. on 7.1R, and snapshots from stable and current from 200902. also tried hw.ata.ata_dma_check_80pin=0 on all, nothing. thanks for your input :) matheus > -Warren Block * Rapid City, South Dakota USA > _______________________________________________ > 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" > -- We will call you cygnus, The God of balance you shall be From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 20:11: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 AFC341065679; Sun, 12 Apr 2009 20:11:15 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f132.google.com (mail-qy0-f132.google.com [209.85.221.132]) by mx1.freebsd.org (Postfix) with ESMTP id 378B78FC14; Sun, 12 Apr 2009 20:11:15 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by qyk38 with SMTP id 38so358988qyk.3 for ; Sun, 12 Apr 2009 13:11:14 -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 :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=Ejv8UktpGvlhoofDwsfDzanIF9rWEf+oBQH6Y1g170s=; b=mjwPJ5zIomo2w5oG27fG6U7cJy/XXsGEs8TERFEDc0Sbi0YkXgNfGLqL0iLESlymFQ 6oxk+E95+ZVWEOMSc5Z2A3zLaoCQa4jYTdkAS7mQDEqd+NiRJZ0jLSJrGaTUW1/JzWT7 RckagtgoVBlD6SYX2H15krWEaiVQUn5leoQe0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=K/b7c/ykb/lX4UCd4AMVaVoEfVg6afLUFQE06GGUw3g1PAEh+cx1Sd/GL8jceUC+6b VdAIMVMfhEP1aKUBujUJOwdMpkhIVy4A1wD0stKfilzSt9YkmWnUwKf1lhF95lXdHnqL fN4Q+SRDPp1wNdKeQX0defCnm0jXerWW87rxs= Received: by 10.224.80.193 with SMTP id u1mr688758qak.104.1239565460167; Sun, 12 Apr 2009 12:44:20 -0700 (PDT) Received: from kan.dnsalias.net (c-98-217-224-113.hsd1.ma.comcast.net [98.217.224.113]) by mx.google.com with ESMTPS id 7sm6872025qwb.41.2009.04.12.12.44.19 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Apr 2009 12:44:19 -0700 (PDT) Date: Sun, 12 Apr 2009 15:44:13 -0400 From: Alexander Kabaev To: Maksim Yevmenkin Message-ID: <20090412154413.1e250cc7@kan.dnsalias.net> In-Reply-To: References: <200904082052.n38KqU9p075633@svn.freebsd.org> <20090412170335.5a8a3169@fabiankeil.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/FtTIo_vAVROr5Q4YsYU0pHp"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-current@freebsd.org Subject: Re: svn commit: r190857 - head/sys/dev/kbdmux X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 20:11:16 -0000 --Sig_/FtTIo_vAVROr5Q4YsYU0pHp Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 12 Apr 2009 10:00:35 -0700 Maksim Yevmenkin wrote: > On Sun, Apr 12, 2009 at 8:03 AM, Fabian Keil >=20 > > How about turning this into a compile-time or sysctl option > > or at least mentioning the change in /usr/src/UPDATING? >=20 > i do not believe that compile-time nor sysctl option is the right > choice here as it is never allowed to use locks in low-level keyboard > drivers. entry in UPDATING is probably a good idea. >=20 > > With this commit, providing the geli key phrase on > > boot is impossible on my AMD64 dual core system. >=20 > right, i really hate to say this, but the amount of bug reports, lor's > etc.that were submitted after this change is far more (imo) than > amount of people that ran relatively uncommon setup with encrypted > root (which, btw, prompted the original commit). of course, there is > no question, it has to be fixed. This also affects DDB prompts, correct? What is the timeframe for fixing this? --=20 Alexander Kabaev --Sig_/FtTIo_vAVROr5Q4YsYU0pHp Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQFJ4kSRQ6z1jMm+XZYRAhivAJwJSDjs2mHRaLYwxBCChqRBmZf5JACeNOR+ ZSbXLkWk3i2JykJil7jjUuQ= =2Aur -----END PGP SIGNATURE----- --Sig_/FtTIo_vAVROr5Q4YsYU0pHp-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 20:37: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 45DE51065808; Sun, 12 Apr 2009 20:37:53 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id BC84E8FC18; Sun, 12 Apr 2009 20:37:52 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id n3CKcWPp017014; Sun, 12 Apr 2009 16:38:32 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Doug Barton In-Reply-To: <49DE86EF.3030409@FreeBSD.org> References: <934e1d760904061455o4736d643o1d07e3292192d94c@mail.gmail.com> <1239078081.1908.41.camel@balrog.2hip.net> <49DAE987.7090802@freebsd.org> <1239086408.35025.59.camel@shumai.marcuscom.com> <20090407185915.GY31409@albert.catwhisker.org> <49DBA371.3080804@freebsd.org> <92cd2ff70904071637h362da63ua13c1f8eca6fc616@mail.gmail.com> <1239147806.98664.12.camel@shumai.marcuscom.com> <92cd2ff70904071653r4bf3b381lf5de220b2e280c0c@mail.gmail.com> <1239150469.98664.18.camel@shumai.marcuscom.com> <49DC405B.7090208@freebsd.org> <49DE86EF.3030409@FreeBSD.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-EPbWCHCYr29wKzTpXPUO" Organization: FreeBSD, Inc. Date: Sun, 12 Apr 2009 16:38:02 -0400 Message-Id: <1239568682.19630.48.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: Tim Kientzle , Freddie Cash , current@FreeBSD.org Subject: Re: Hal and KDM breakage (was Re: KDE4 and input events stalled) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 20:37:56 -0000 --=-EPbWCHCYr29wKzTpXPUO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2009-04-09 at 16:38 -0700, Doug Barton wrote: > Not sure if this is even possible, but I thought I'd throw it out > there. Would starting hald before ttys are loaded, then restarting it > again at the end of the boot process work to solve this issue? It > seems that you have 2 distinct 'flavors' of hald here (with vty > support, and without), so if it's smart enough to do the right thing > for its consumers when it is restarted I think this approach might work. Yes, this should work. If you modify hald's rc.d script to start immediately, then restart itself based on the getty delay already present, I believe both X and device management will work. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-EPbWCHCYr29wKzTpXPUO 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) iEYEABECAAYFAkniUSkACgkQb2iPiv4Uz4dNXgCdFJLnsQ9w9GaWlsF21gBVdrpo 3VoAoLDJN7s6TW7YhkCNkvLLrJSQi16m =TscK -----END PGP SIGNATURE----- --=-EPbWCHCYr29wKzTpXPUO-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 21:07: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 316BB106564A for ; Sun, 12 Apr 2009 21:07:39 +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 A529D8FC1E for ; Sun, 12 Apr 2009 21:07:38 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 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 240001672; Mon, 13 Apr 2009 00:07:37 +0300 Message-ID: <49E25818.1090600@FreeBSD.org> Date: Mon, 13 Apr 2009 00:07:36 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Diego Depaoli References: <1239063789.00097213.1239052203@10.7.7.3> <49DBAEB5.7010500@FreeBSD.org> <20090407200257.GB19850@home.opsec.eu> <49DBB3C0.9010800@FreeBSD.org> <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> <49DC6129.4070107@FreeBSD.org> <83e5fb980904101726m54af3a4boe875854b7e9bd11e@mail.gmail.com> In-Reply-To: <83e5fb980904101726m54af3a4boe875854b7e9bd11e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: AMD 780G chipset major issues 1/3 (ata, ataati) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 21:07:39 -0000 Diego Depaoli wrote: > On Wed, Apr 8, 2009 at 10:32 AM, Alexander Motin wrote: >> You can try to comment out 'ctlr->channels = 1;' line in your ata-ati.c >> file to allow second channel of the second controller to be attached. > I'm sorry, did not help. You haven't got second channel or it does not work? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 21:53: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 538B310656D5 for ; Sun, 12 Apr 2009 21:53:43 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id B43278FC0A for ; Sun, 12 Apr 2009 21:53:42 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by ewy19 with SMTP id 19so1758962ewy.43 for ; Sun, 12 Apr 2009 14:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=xCWEeCbqvrMDVqtn8MJCnKfqJpBhNoIq5WJ6beBMxIs=; b=GmiDAKsh02EwzO2U7ViuZlGWOI6cySMIOmfu/FQXo9sOPF7hB+xOfxt0dxkRX9uwaa NHqVvmjV1g3pvZCVYNVk51iCzeddUJHwTj9gB8SOD40svVYEx/wtfJtUqd9kHn6bk20I 01ea0VIxtcgmah4cfGnKeSRTJtEeGnSLGTZDU= 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=HkMkTLr0dAXMit2EUNRwOi578FRSNZUIrEbVkZaE78p0MqNtBvGh1ZF0/LHwwW3Oej A2an+eT1uyGv7NpXnsuyVeP8Xl90q3P7ML/6FgXIEnRcmoNHBXW/EbC8vFoZv/aRMENN 47HeOrOGNOre48jgvi071AuKxfLq4uw2kQnpU= MIME-Version: 1.0 Sender: maksim.yevmenkin@gmail.com Received: by 10.216.28.200 with SMTP id g50mr1373398wea.203.1239573221657; Sun, 12 Apr 2009 14:53:41 -0700 (PDT) In-Reply-To: <20090412154413.1e250cc7@kan.dnsalias.net> References: <200904082052.n38KqU9p075633@svn.freebsd.org> <20090412170335.5a8a3169@fabiankeil.de> <20090412154413.1e250cc7@kan.dnsalias.net> Date: Sun, 12 Apr 2009 14:53:41 -0700 X-Google-Sender-Auth: 5d58ad2f37f2465b Message-ID: From: Maksim Yevmenkin To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: svn commit: r190857 - head/sys/dev/kbdmux X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 21:53:44 -0000 On Sun, Apr 12, 2009 at 12:44 PM, Alexander Kabaev wrote: > On Sun, 12 Apr 2009 10:00:35 -0700 > Maksim Yevmenkin wrote: > >> On Sun, Apr 12, 2009 at 8:03 AM, Fabian Keil >> >> > How about turning this into a compile-time or sysctl option >> > or at least mentioning the change in /usr/src/UPDATING? >> >> i do not believe that compile-time nor sysctl option is the right >> choice here as it is never allowed to use locks in low-level keyboard >> drivers. entry in UPDATING is probably a good idea. >> >> > With this commit, providing the geli key phrase on >> > boot is impossible on my AMD64 dual core system. >> >> right, i really hate to say this, but the amount of bug reports, lor's >> etc.that were submitted after this change is far more (imo) than >> amount of people that ran relatively uncommon setup with encrypted >> root (which, btw, prompted the original commit). of course, there is >> no question, it has to be fixed. > > This also affects DDB prompts, correct? What is the timeframe for > fixing this? not really, imo. in ddb prompts interrupts are disabled (as i understand it). as far as fixing it, it could be as simple as the patch i sent in my previous email. thanks, max From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 21:58: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 A4DCE10657A3; Sun, 12 Apr 2009 21:58:04 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 040408FC14; Sun, 12 Apr 2009 21:58:03 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: by fxm11 with SMTP id 11so1816845fxm.43 for ; Sun, 12 Apr 2009 14:58:02 -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=BL7DKcPCCT69GSogWmROXKq1KAXpwioAB/mG7UAJT/c=; b=DebxOBkIk7RT3XtiV8oHlh22b9l9PZes+2KxT9XtiiQOf/Z0pWK4DgmV5p681HCCnP 11Acg/pthdSpntmk/6korBt1xyVjg1riRfF+bk4db5IRbmMW1bbS0eDTS4z5knTTtdxt qBq6K1CMzJBNvYQt8IzzLYkmZgtjB59gBMlEc= 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=rgYRENKuPRftJ1tXYS1a3YWMZRcn5mMYYgJq9/Iq1oYdUfh7G9VmwvJwFdIh6DJAf2 oUSERvGP/U9azdBeSoZTOwVhyQP+FZ+4Iy6qlqmRz4wP5dgj/RjLJVzJw2KAGvZayDJb uaB0qlVo4CeJohy7a/77P4fk+HiV7vNW2lPRU= MIME-Version: 1.0 Received: by 10.223.117.14 with SMTP id o14mr1587253faq.21.1239573482617; Sun, 12 Apr 2009 14:58:02 -0700 (PDT) In-Reply-To: <49E25818.1090600@FreeBSD.org> References: <1239063789.00097213.1239052203@10.7.7.3> <49DBAEB5.7010500@FreeBSD.org> <20090407200257.GB19850@home.opsec.eu> <49DBB3C0.9010800@FreeBSD.org> <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> <49DC6129.4070107@FreeBSD.org> <83e5fb980904101726m54af3a4boe875854b7e9bd11e@mail.gmail.com> <49E25818.1090600@FreeBSD.org> Date: Sun, 12 Apr 2009 23:58:02 +0200 Message-ID: <83e5fb980904121458s37bb3f52w54a0be23563e1006@mail.gmail.com> From: Diego Depaoli To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: AMD 780G chipset major issues 1/3 (ata, ataati) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 21:58:06 -0000 Apparently I got no changes. On 4/12/09, Alexander Motin wrote: > Diego Depaoli wrote: >> On Wed, Apr 8, 2009 at 10:32 AM, Alexander Motin wrote: >>> You can try to comment out 'ctlr->channels = 1;' line in your ata-ati.c >>> file to allow second channel of the second controller to be attached. >> I'm sorry, did not help. > > You haven't got second channel or it does not work? > > -- > Alexander Motin > -- Diego Depaoli From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 22:02: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 399D91065813; Sun, 12 Apr 2009 22:02:07 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id C57578FC19; Sun, 12 Apr 2009 22:02:06 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1110710yxm.13 for ; Sun, 12 Apr 2009 15:02:06 -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 :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=sxnWtQjkTMUNH+VY62F/xC19HIBpi+QcJ0/esMQsZos=; b=eBlm0ey2P8vurm+Yc5h0L1T699ZpbxmV07qH0gpNFxUHu3Hg35SMbhSFYmUB1/FzBq GOe6TODaN1f7h4kDFGLUWHgqnvpv9IHuaLh4QIR4woUOX4MlqLMtjxAEyI9uM4GRkiPC cn00qwQYp+k98xv8XTNS0dUtr3EhAH0vvMsQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=J8vqq0r9uD3r1HvDjTdRKydtWdFcx5C2KvE7gpgJb9Y4GaaOrdI4UVRiGvoQg6nEw0 cT33ellB0FWretXhjlzWX9dGiQrkip/cW2UXVwSWjxuwE1o5t+Mw/ZIxIwd2q0zQUjQa MBy1ksdSESnlqhI/t/5mGIVmeEAXyQu+ui8Fk= Received: by 10.100.42.4 with SMTP id p4mr6191094anp.115.1239573726071; Sun, 12 Apr 2009 15:02:06 -0700 (PDT) Received: from kan.dnsalias.net (c-98-217-224-113.hsd1.ma.comcast.net [98.217.224.113]) by mx.google.com with ESMTPS id 4sm9528823yxj.1.2009.04.12.15.02.04 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Apr 2009 15:02:05 -0700 (PDT) Date: Sun, 12 Apr 2009 18:01:59 -0400 From: Alexander Kabaev To: Maksim Yevmenkin Message-ID: <20090412180159.659d9195@kan.dnsalias.net> In-Reply-To: References: <200904082052.n38KqU9p075633@svn.freebsd.org> <20090412170335.5a8a3169@fabiankeil.de> <20090412154413.1e250cc7@kan.dnsalias.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/lA0KiIQHK6sTt1AFp2udYlU"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-current@freebsd.org Subject: Re: svn commit: r190857 - head/sys/dev/kbdmux X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 22:02:10 -0000 --Sig_/lA0KiIQHK6sTt1AFp2udYlU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 12 Apr 2009 14:53:41 -0700 Maksim Yevmenkin wrote: > On Sun, Apr 12, 2009 at 12:44 PM, Alexander Kabaev > wrote: > > On Sun, 12 Apr 2009 10:00:35 -0700 > > Maksim Yevmenkin wrote: > > >=20 > not really, imo. in ddb prompts interrupts are disabled (as i > understand it). >=20 > as far as fixing it, it could be as simple as the patch i sent in my > previous email. >=20 > thanks, > max Thanks. The situation is a whole lot better than what I was imagining then. --=20 Alexander Kabaev --Sig_/lA0KiIQHK6sTt1AFp2udYlU Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQFJ4mTcQ6z1jMm+XZYRAtMZAKCAx0InyUVHGguZ5J9cPgqYR4qhBACggKn5 AXLujnqfjGF7UzGawjvvzUE= =iQUp -----END PGP SIGNATURE----- --Sig_/lA0KiIQHK6sTt1AFp2udYlU-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 12 22:28: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 ECDD5106564A for ; Sun, 12 Apr 2009 22:28:55 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id C15DE8FC14 for ; Sun, 12 Apr 2009 22:28:55 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so1698385rvb.43 for ; Sun, 12 Apr 2009 15:28:55 -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=mYdLi1I5OEtFW7oZBld8+ejqp0qdSJdLmJpxWXdgg1w=; b=xyjs0wN6tNhErgqXHJ7/sDChDfFC0DNkjWSYoaxk0EZZjz6gOxT2AkbBQLRmVUFOLX 0Pkw5UfdfV80PB1IObMVQCVnINlZE7mTP3yAF4sHZGwKpjArbJBpoVE9x4/JnXHexUbq 9jA/aNges7ObUgth9cGfeBC91OHVK8SzvDBpI= 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=k9XYyek0KVNgxCI5adiB8ECqsEbUdBrY8ssODSz3uFXLqFbSuZv7WZgRruUfi2tjs1 1T5TRLWuIB79iI2OoV/vUT3EkeLrVi3masKWlqFjh0kx2YzGBzvJJHTX/bNBVQlKrLRx GPvchs/Lxl9pBLBCVeWDUYmbHhUJP2Cj4Y2GI= MIME-Version: 1.0 Received: by 10.141.198.2 with SMTP id a2mr2453433rvq.224.1239574009104; Sun, 12 Apr 2009 15:06:49 -0700 (PDT) In-Reply-To: <49E174DE.90603@cs.rice.edu> References: <49E11CE7.5050903@cs.rice.edu> <49E172A3.2000108@samsco.org> <49E174DE.90603@cs.rice.edu> Date: Sun, 12 Apr 2009 15:06:49 -0700 Message-ID: <7d6fde3d0904121506u5ed82765oe6fd73231f4c6b97@mail.gmail.com> From: Garrett Cooper To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: [Fwd: svn commit: r190949 - head/sys/vm] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Apr 2009 22:28:56 -0000 On Sat, Apr 11, 2009 at 9:58 PM, Alan Cox wrote: > Scott Long wrote: >> >> Off the top of my head, I would almost expect this to conflict with >> Java. =A0Haven't tried it, though, so I can't do anything more than >> speculate. =A0However, I would encourage testing here. >> > > It doesn't. =A0I verified that the Sun JVM works. Has this been verified with Perl / Python yet? -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 00:07:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AA41106566B; Mon, 13 Apr 2009 00:07:42 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id E54E08FC1A; Mon, 13 Apr 2009 00:07:41 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: by fxm11 with SMTP id 11so1842185fxm.43 for ; Sun, 12 Apr 2009 17:07:40 -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=XVcb6mChlUpKhw/wLiR0kQQ/FMFB9J/XfhMkg4CLuSk=; b=Dzxc6OJl4JVZxR9YGnIB21MLfLf1h+yuya+ILraFgamgQ1C+Br83FEMGTxNTHE2K6O fA8wYNLY3GErEfsEmashb13dT5ofsx2rqB3x3KCjBdlBuzQseiJzwgMEdBjHDIM/OiA2 zlO7HlUKSraP3j+Cu4XKtRtGveqYZ0ncTo8YM= 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=GT1sw8YHsrBvCJ/4/wA4p3RhMteJbsKcZeoXasyaj79EjUJw1LT2tqoEXdQx9L3Jos ar2ZfJdjrYkcVIB4aCKe3/vpKRT/iBjSJSQGJjqXmQM1eQ0jyGv9u4u3WSRKquGKoGr+ dSqia7b2UxE8Go98S81PV90QLFFXv+FhHb6VA= MIME-Version: 1.0 Received: by 10.223.113.9 with SMTP id y9mr1588821fap.61.1239581260645; Sun, 12 Apr 2009 17:07:40 -0700 (PDT) In-Reply-To: <83e5fb980904121458s37bb3f52w54a0be23563e1006@mail.gmail.com> References: <1239063789.00097213.1239052203@10.7.7.3> <49DBAEB5.7010500@FreeBSD.org> <20090407200257.GB19850@home.opsec.eu> <49DBB3C0.9010800@FreeBSD.org> <83e5fb980904071402k600cbc09hcde8994cb5465f52@mail.gmail.com> <49DC6129.4070107@FreeBSD.org> <83e5fb980904101726m54af3a4boe875854b7e9bd11e@mail.gmail.com> <49E25818.1090600@FreeBSD.org> <83e5fb980904121458s37bb3f52w54a0be23563e1006@mail.gmail.com> Date: Mon, 13 Apr 2009 02:07:40 +0200 Message-ID: <83e5fb980904121707s18b0a74bveb6294490935be89@mail.gmail.com> From: Diego Depaoli To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: AMD 780G chipset major issues 1/3 (ata, ataati) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Apr 2009 00:07:42 -0000 Loading ata-ati, even ata-siliconimage is loaded. It's right? On 4/12/09, Diego Depaoli wrote: > Apparently I got no changes. > > On 4/12/09, Alexander Motin wrote: >> Diego Depaoli wrote: >>> On Wed, Apr 8, 2009 at 10:32 AM, Alexander Motin >>> wrote: >>>> You can try to comment out 'ctlr->channels = 1;' line in your ata-ati.c >>>> file to allow second channel of the second controller to be attached. >>> I'm sorry, did not help. >> >> You haven't got second channel or it does not work? >> >> -- >> Alexander Motin >> > > > -- > Diego Depaoli > -- Diego Depaoli From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 01:34: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 3AE941065675 for ; Mon, 13 Apr 2009 01:34:38 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id B9B118FC14 for ; Mon, 13 Apr 2009 01:34:37 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n3D1YZWW024427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Apr 2009 01:34:35 GMT (envelope-from ben@wanderview.com) Message-Id: From: Ben Kelly To: Chuck Robey In-Reply-To: <49D8EC20.70700@telenix.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 12 Apr 2009 21:34:35 -0400 References: <49D8EC20.70700@telenix.org> X-Mailer: Apple Mail (2.930.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: freebsd-current@freebsd.org Subject: Re: comparing svn and cvs somewhat X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Apr 2009 01:34:38 -0000 On Apr 5, 2009, at 1:36 PM, Chuck Robey wrote: > I have gotten a local copy of the svn repo going on my home here, by > using > svnsync, which seems (by what I've read and been told) to be the > right method. > I'm wondering about a feature that is there for cvs, in cvsup, but > which seems > to be missing in svnsync for svn. > > What I'm after is a much better way to maintain a local repo than > what I'm > seeing now in maintaining my svn repo, with svnsync. The main > feature that I > think I'm missing is the ability to be able to compare files on a > central server > (something serving all FreeBSDers) to files on everybody's personal > repo, and > to automatically update them if there isn't a perfect comparison. > I'm not > talking about the varying ways that your repo might get damaged, but > I think > that svnsync only knows that you have a particular revision number, > not that the > file is correct. If your repo gets damage, I think that nothing > exists to > automatically fix it. > > So, if this feature IS something that's already available in svn, > I'd like to > here a summary of what tool to use the how to do it, so I can verify > myself that > what I'm thinking about already exists. That'd free me to begin > writing > software, to see if I could implement such a feature. I'm not truly > certain of > this, but it seems to me that implementing such a feature, using > something like > Python, would be very easy to do. Could end up with a svn version > of cvs's > cvsup. Maybe, call it svnup? I'm terrible at names, if you think > that name > makes no sense, please, tell me so. I looked into this a bit previously. I wanted something similar to cvsup to help me track remote repositories as vendor branches in my local repository. My initial research showed some feature requests for "svn export -r REV" which would have done most of this for me. Unfortunately the last time I looked it hadn't been implemented. So based on that I wrote a very-alpha proof of concept script you can find here: http://www.wanderview.com/svn/public/svnsnap/0.1/ Please use at your own risk because its only been tested very lightly. I've pretty much abandoned this script because I don't think a shell script wrapper can handle all the corner cases with the current support in the svn tools. In particular I know this script does not handle updates to file and directory permissions. I started working on a C utility that interfaced directly with the svn API's, but I got distracted by real life before getting it in working order. Anyway, I'm interested in a tool like this, but I doubt I will have a lot of time in the short term to work on it. Hope that helps. - Ben From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 05:06: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 512D0106564A for ; Mon, 13 Apr 2009 05:06:47 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: from iron2.pdx.net (iron2.pdx.net [69.64.224.71]) by mx1.freebsd.org (Postfix) with ESMTP id 37C878FC0C for ; Mon, 13 Apr 2009 05:06:46 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: (qmail 6601 invoked from network); 12 Apr 2009 22:06:42 -0700 Received: from 069-064-235-060.pdx.net (HELO ?192.168.1.51?) (69.64.235.60) by iron2.pdx.net with SMTP; 12 Apr 2009 22:06:42 -0700 From: Sean Bruno To: freebsd-current@freebsd.org Content-Type: text/plain Date: Sun, 12 Apr 2009 22:06:45 -0700 Message-Id: <1239599205.24831.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit Subject: NFS errors on compile of -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 05:06:47 -0000 [sean@bsd64 ~/bsd/head/sys/amd64/compile/SBP_TARG]$ make linking kernel.debug nfs_srvsubs.o(.text+0xd0c): In function `nfsrv_modevent': ../../../nfsserver/nfs_srvsubs.c:560: undefined reference to `nfsd_call_nfsserver' nfs_srvsubs.o(.text+0xd42):../../../nfsserver/nfs_srvsubs.c:569: undefined reference to `nfsd_call_nfsserver' *** Error code 1 Stop in /usr/home/sean/bsd/head/sys/amd64/compile/SBP_TARG. From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 09:30: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 1A248106566B for ; Mon, 13 Apr 2009 09:30:39 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 59B6F8FC12 for ; Mon, 13 Apr 2009 09:30:38 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: by fxm11 with SMTP id 11so1940348fxm.43 for ; Mon, 13 Apr 2009 02:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=r29cuWLL8zyRiyn192SAZLqHYvkW/O4PSdIuqjolHd8=; b=a+/0qfIhl9sfflSON2Ca4chIUCHs0ITOBNDXn1i+jHEUIxAvdKvU/mLu70qkRU91SN P3jg/zs4eHe0aVJQ996RiQVyogDhhCnyZx4Bw0tXlpQq4JrerMpKJGObSaruXRywxEOp LLiM3Yw5g6piZQhrceFYwQmKvzpSCtkwvZrU0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=rfoY47/6aho/DYSxbaPksUwz+dorA91ROUnCb4/yuCPgoCYJCFx+qV0ANL3Nt2gdSJ R/HE0Z3ic9mL16lwa3gMt0qXf7dNOa1GMzYRGVCaWWGRzBlATUSYt4og9ZD8eCgRNIJ3 WyuP5NihiDM3Y2PLd9pemGbVuqBwFQsbEZ/G0= MIME-Version: 1.0 Received: by 10.223.117.1 with SMTP id o1mr1667906faq.53.1239613421316; Mon, 13 Apr 2009 02:03:41 -0700 (PDT) Date: Mon, 13 Apr 2009 11:03:41 +0200 Message-ID: <7daacbbe0904130203m62080028v14f6a1e4a3285dc0@mail.gmail.com> From: Dominique Goncalves To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Unusable Xorg with USB mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Apr 2009 09:30:39 -0000 Hi, I upgraded my FreeBSD desktop (XFCE4 and some applications) from 7.1-RELEASE to 8.0-CURRENT r190942 all ports was build from scratch after removing old files with make delete-old delete-old-libs. Now it's very hard to listen music with mplayer, write text with vim, browse internet with firefox... it just stop working and restart when moving the mouse! Let me know if you need more information. Any help is really appreciated, Thanks. > dmesg 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-CURRENT #0 r190942: Sat Apr 11 22:05:48 CEST 2009 root@djdomics:/usr/obj/usr/src/sys/GENERIC_NODEBUG Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (2000.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff real memory = 805306368 (768 MB) avail memory = 774045696 (738 MB) ACPI APIC Table: MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xde000000-0xdeffffff,0xc0000000-0xcfffffff irq 16 at device 0.0 on pci1 isab0: at device 2.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 2.5 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] ohci0: mem 0xdfffc000-0xdfffcfff irq 20 at device 3.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xdfffd000-0xdfffdfff irq 21 at device 3.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ohci2: mem 0xdfffe000-0xdfffefff irq 22 at device 3.2 on pci0 ohci2: [ITHREAD] usbus2: on ohci2 ehci0: mem 0xdffff000-0xdfffffff irq 23 at device 3.3 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcm0: port 0xdc00-0xdc1f,0xd800-0xd80f,0xd400-0xd40f,0xd000-0xd03f irq 19 at device 8.0 on pci0 pcm0: [ITHREAD] pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0xd63b XIN2 Clock Source: 22.5792MHz(44.1kHz*512) MPU-401 UART(s) #: 1 AC'97 codec: not exist ADC #: 4 DAC #: 4 Multi-track converter type: I2S(96KHz support, 24bit resolution, ID#0x2) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0x04/0xfb/0x7e rl0: port 0xcc00-0xccff mem 0xdfffbf00-0xdfffbfff irq 18 at device 11.0 on pci0 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:10:dc:82:9b:d2 rl0: [ITHREAD] atrtc0: port 0x70-0x71 irq 8 on acpi0 fdc1: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc1: [FILTER] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 cpu0: on acpi0 p4tcc0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd27ff 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 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] fdc0: No FDOUT register! Timecounter "TSC" frequency 2000150592 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ad0: 57241MB at ata0-master UDMA100 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 ad1: 57241MB at ata0-slave UDMA100 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered acd0: DVDROM at ata1-master UDMA33 GEOM: ad0: partition 1 does not start on a track boundary. GEOM: ad0: partition 1 does not end on a track boundary. acd1: CDRW at ata1-slave UDMA33 GEOM: ad0s2: geometry does not match label (255h,63s != 16h,255s). GEOM: ad1: partition 1 does not start on a track boundary. GEOM: ad1: partition 1 does not end on a track boundary. uhub3: 6 ports with 6 removable, self powered acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 cd0 at ata1 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [196100 x 2048 byte records] cd1 at ata1 bus 0 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 33.000MB/s transfers cd1: cd present [3510947 x 2048 byte records] GEOM_LABEL: Label for provider acd0 is iso9660/DIE_HARD_1. GEOM_LABEL: Label for provider ad0s2a is ufsid/47fa91abbef03a13. GEOM_LABEL: Label for provider ad0s2d is ufsid/47fa91ad7b28768a. GEOM_LABEL: Label for provider ad0s2e is ufsid/47fa91abefc1e226. GEOM_LABEL: Label for provider ad0s2f is ufsid/47fa91abfb5c1768. GEOM: ad1s2: geometry does not match label (255h,63s != 16h,255s). GEOM: ad1s3: geometry does not match label (16h,63s != 16h,255s). ugen2.2: at usbus2 ums0: on usbus2 ums0: 3 buttons and [XYZ] coordinates ID=0 GEOM_LABEL: Label for provider acd1 is iso9660/CDROM. GEOM_LABEL: Label for provider ad1s2a is ufsid/423b25e8c0bf6015. GEOM_LABEL: Label for provider ad1s2d is ufsid/423b25e933d9f5b1. GEOM_LABEL: Label for provider ad1s2e is ufsid/423b25e88d1a575d. GEOM_LABEL: Label for provider ad1s2f is ufsid/423b25e8f04b19a7. GEOM_LABEL: Label for provider ad1s3g is ufsid/423de7c40ececa0b. GEOM_LABEL: Label for provider ad1s3i is ufsid/423de7c57cc3c44b. GEOM_LABEL: Label for provider ad1s3j is ufsid/423de7cf5ab394ca. acd1: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 Trying to mount root from ufs:/dev/ad0s2a GEOM_LABEL: Label ufsid/47fa91abbef03a13 removed. GEOM_LABEL: Label for provider ad0s2a is ufsid/47fa91abbef03a13. GEOM_LABEL: Label ufsid/47fa91abefc1e226 removed. GEOM_LABEL: Label for provider ad0s2e is ufsid/47fa91abefc1e226. GEOM_LABEL: Label ufsid/47fa91abfb5c1768 removed. GEOM_LABEL: Label for provider ad0s2f is ufsid/47fa91abfb5c1768. GEOM_LABEL: Label ufsid/47fa91ad7b28768a removed. GEOM_LABEL: Label for provider ad0s2d is ufsid/47fa91ad7b28768a. GEOM_LABEL: Label ufsid/47fa91abbef03a13 removed. GEOM_LABEL: Label ufsid/47fa91abefc1e226 removed. GEOM_LABEL: Label ufsid/47fa91abfb5c1768 removed. GEOM_LABEL: Label ufsid/47fa91ad7b28768a removed. rl0: link state changed to UP > vmstat -i interrupt total rate irq1: atkbd0 1823 1 irq14: ata0 10943 7 irq15: ata1 4692 3 irq18: rl0 32566 22 irq19: pcm0 99133 68 irq22: ohci2 31197 21 irq23: ehci0 2 0 cpu0: timer 2872088 1998 Total 3052444 2124 > cat /etc/rc.conf # -- sysinstall generated deltas -- # Mon Apr 7 23:50:43 2008 # Created: Mon Apr 7 23:50:43 2008 # Enable network daemons for user convenience. # Please make all changes to this file, not to /etc/defaults/rc.conf. # This file now contains just the overrides from /etc/defaults/rc.conf. hostname="djdomics" ifconfig_rl0="DHCP" keymap="fr.iso.acc" sshd_enable="YES" gnome_enable="YES" > cat /etc/X11/xorg.conf Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" Option "AllowEmptyInput" "off" EndSection Section "Files" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/lib/X11/fonts/misc/" FontPath "/usr/local/lib/X11/fonts/TTF/" FontPath "/usr/local/lib/X11/fonts/OTF" FontPath "/usr/local/lib/X11/fonts/Type1/" FontPath "/usr/local/lib/X11/fonts/100dpi/" FontPath "/usr/local/lib/X11/fonts/75dpi/" EndSection Section "Module" Load "dbe" Load "dri" Load "extmod" Load "glx" Load "record" Load "xtrap" Load "freetype" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbLayout" "fr" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" #DisplaySize 320 240 # mm Identifier "Monitor0" VendorName "FUS" ModelName "C700" HorizSync 30.0 - 72.0 VertRefresh 50.0 - 160.0 Option "DPMS" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "SWcursor" # [] #Option "HWcursor" # [] #Option "NoAccel" # [] #Option "ShadowFB" # [] #Option "UseFBDev" # [] #Option "Rotate" # [] #Option "VideoKey" # #Option "FlatPanel" # [] #Option "FPDither" # [] #Option "CrtcNumber" # #Option "FPScale" # [] #Option "FPTweak" # #Option "DualHead" # [] Identifier "Card0" Driver "nv" VendorName "nVidia Corporation" BoardName "NV36 [GeForce FX 5700LE]" BusID "PCI:1:0:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection -- There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 12:55: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 1E5E21065922 for ; Mon, 13 Apr 2009 12:55:17 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5B4178FC3C for ; Mon, 13 Apr 2009 12:55:16 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LtLgv-0000Qk-Ib; Mon, 13 Apr 2009 14:55:14 +0200 Message-ID: <49E3362B.9040704@gwdg.de> Date: Mon, 13 Apr 2009 14:55:07 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: Dominique Goncalves References: <7daacbbe0904130203m62080028v14f6a1e4a3285dc0@mail.gmail.com> In-Reply-To: <7daacbbe0904130203m62080028v14f6a1e4a3285dc0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current Subject: Re: Unusable Xorg with USB mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Apr 2009 12:55:19 -0000 Hi Dominique, On 13.04.2009 11:03 (UTC+1), Dominique Goncalves wrote: > Hi, > > I upgraded my FreeBSD desktop (XFCE4 and some applications) from > 7.1-RELEASE to 8.0-CURRENT r190942 all ports was build from scratch > after removing old files with make delete-old delete-old-libs. as far as I know 'make delete-old delete-old-libs' has to be done from /usr/src and so it removes obsolete files from system (see /usr/src/ObsoleteFiles.inc). To remove ports (/usr/ports) and build from scratch you have to 'pkg_delete -a' or something like this... > Now it's very hard to listen music with mplayer, write text with vim, > browse internet with firefox... it just stop working and restart when > moving the mouse! There had been many changes in CURRENT and xorg in the last time. USB is totally new, libusb is integrated in the system (please do not install that port!) etc. So please read /usr/ports/UPDATING, especially the entries 20090309 and 20090123. Hope I could help, Rainer > Let me know if you need more information. > > Any help is really appreciated, > Thanks. > >> dmesg > 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-CURRENT #0 r190942: Sat Apr 11 22:05:48 CEST 2009 > root@djdomics:/usr/obj/usr/src/sys/GENERIC_NODEBUG > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (2000.15-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 > Features=0x3febfbff > real memory = 805306368 (768 MB) > avail memory = 774045696 (738 MB) > ACPI APIC Table: > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: on hostb0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: mem > 0xde000000-0xdeffffff,0xc0000000-0xcfffffff irq 16 at device 0.0 on > pci1 > isab0: at device 2.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 2.5 on > pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > ohci0: mem 0xdfffc000-0xdfffcfff irq 20 at > device 3.0 on pci0 > ohci0: [ITHREAD] > usbus0: on ohci0 > ohci1: mem 0xdfffd000-0xdfffdfff irq 21 at > device 3.1 on pci0 > ohci1: [ITHREAD] > usbus1: on ohci1 > ohci2: mem 0xdfffe000-0xdfffefff irq 22 at > device 3.2 on pci0 > ohci2: [ITHREAD] > usbus2: on ohci2 > ehci0: mem 0xdffff000-0xdfffffff > irq 23 at device 3.3 on pci0 > ehci0: [ITHREAD] > usbus3: EHCI version 1.0 > usbus3: on ehci0 > pcm0: port > 0xdc00-0xdc1f,0xd800-0xd80f,0xd400-0xd40f,0xd000-0xd03f irq 19 at > device 8.0 on pci0 > pcm0: [ITHREAD] > pcm0: system configuration > SubVendorID: 0x1412, SubDeviceID: 0xd63b > XIN2 Clock Source: 22.5792MHz(44.1kHz*512) > MPU-401 UART(s) #: 1 > AC'97 codec: not exist > ADC #: 4 > DAC #: 4 > Multi-track converter type: I2S(96KHz support, 24bit resolution, ID#0x2) > S/PDIF(IN/OUT): 1/1 ID# 0x00 > GPIO(mask/dir/state): 0x04/0xfb/0x7e > rl0: port 0xcc00-0xccff mem > 0xdfffbf00-0xdfffbfff irq 18 at device 11.0 on pci0 > miibus0: on rl0 > rlphy0: PHY 0 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > rl0: Ethernet address: 00:10:dc:82:9b:d2 > rl0: [ITHREAD] > atrtc0: port 0x70-0x71 irq 8 on acpi0 > fdc1: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq > 6 drq 2 on acpi0 > fdc1: [FILTER] > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart1: [FILTER] > ppc0: port 0x378-0x37f irq 7 on acpi0 > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > ppc0: [ITHREAD] > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: [ITHREAD] > lpt0: on ppbus0 > lpt0: [ITHREAD] > lpt0: Interrupt-driven port > ppi0: on ppbus0 > cpu0: on acpi0 > p4tcc0: on cpu0 > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd27ff 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 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > fdc0: No FDOUT register! > Timecounter "TSC" frequency 2000150592 Hz quality 800 > Timecounters tick every 1.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > ad0: 57241MB at ata0-master UDMA100 > 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 > ad1: 57241MB at ata0-slave UDMA100 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > acd0: DVDROM at ata1-master UDMA33 > GEOM: ad0: partition 1 does not start on a track boundary. > GEOM: ad0: partition 1 does not end on a track boundary. > acd1: CDRW at ata1-slave UDMA33 > GEOM: ad0s2: geometry does not match label (255h,63s != 16h,255s). > GEOM: ad1: partition 1 does not start on a track boundary. > GEOM: ad1: partition 1 does not end on a track boundary. > uhub3: 6 ports with 6 removable, self powered > acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > cd0 at ata1 bus 0 target 1 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 33.000MB/s transfers > cd0: cd present [196100 x 2048 byte records] > cd1 at ata1 bus 0 target 0 lun 0 > cd1: Removable CD-ROM SCSI-0 device > cd1: 33.000MB/s transfers > cd1: cd present [3510947 x 2048 byte records] > GEOM_LABEL: Label for provider acd0 is iso9660/DIE_HARD_1. > GEOM_LABEL: Label for provider ad0s2a is ufsid/47fa91abbef03a13. > GEOM_LABEL: Label for provider ad0s2d is ufsid/47fa91ad7b28768a. > GEOM_LABEL: Label for provider ad0s2e is ufsid/47fa91abefc1e226. > GEOM_LABEL: Label for provider ad0s2f is ufsid/47fa91abfb5c1768. > GEOM: ad1s2: geometry does not match label (255h,63s != 16h,255s). > GEOM: ad1s3: geometry does not match label (16h,63s != 16h,255s). > ugen2.2: at usbus2 > ums0: on usbus2 > ums0: 3 buttons and [XYZ] coordinates ID=0 > GEOM_LABEL: Label for provider acd1 is iso9660/CDROM. > GEOM_LABEL: Label for provider ad1s2a is ufsid/423b25e8c0bf6015. > GEOM_LABEL: Label for provider ad1s2d is ufsid/423b25e933d9f5b1. > GEOM_LABEL: Label for provider ad1s2e is ufsid/423b25e88d1a575d. > GEOM_LABEL: Label for provider ad1s2f is ufsid/423b25e8f04b19a7. > GEOM_LABEL: Label for provider ad1s3g is ufsid/423de7c40ececa0b. > GEOM_LABEL: Label for provider ad1s3i is ufsid/423de7c57cc3c44b. > GEOM_LABEL: Label for provider ad1s3j is ufsid/423de7cf5ab394ca. > acd1: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 > Trying to mount root from ufs:/dev/ad0s2a > GEOM_LABEL: Label ufsid/47fa91abbef03a13 removed. > GEOM_LABEL: Label for provider ad0s2a is ufsid/47fa91abbef03a13. > GEOM_LABEL: Label ufsid/47fa91abefc1e226 removed. > GEOM_LABEL: Label for provider ad0s2e is ufsid/47fa91abefc1e226. > GEOM_LABEL: Label ufsid/47fa91abfb5c1768 removed. > GEOM_LABEL: Label for provider ad0s2f is ufsid/47fa91abfb5c1768. > GEOM_LABEL: Label ufsid/47fa91ad7b28768a removed. > GEOM_LABEL: Label for provider ad0s2d is ufsid/47fa91ad7b28768a. > GEOM_LABEL: Label ufsid/47fa91abbef03a13 removed. > GEOM_LABEL: Label ufsid/47fa91abefc1e226 removed. > GEOM_LABEL: Label ufsid/47fa91abfb5c1768 removed. > GEOM_LABEL: Label ufsid/47fa91ad7b28768a removed. > rl0: link state changed to UP > >> vmstat -i > interrupt total rate > irq1: atkbd0 1823 1 > irq14: ata0 10943 7 > irq15: ata1 4692 3 > irq18: rl0 32566 22 > irq19: pcm0 99133 68 > irq22: ohci2 31197 21 > irq23: ehci0 2 0 > cpu0: timer 2872088 1998 > Total 3052444 2124 > >> cat /etc/rc.conf > > # -- sysinstall generated deltas -- # Mon Apr 7 23:50:43 2008 > # Created: Mon Apr 7 23:50:43 2008 > # Enable network daemons for user convenience. > # Please make all changes to this file, not to /etc/defaults/rc.conf. > # This file now contains just the overrides from /etc/defaults/rc.conf. > hostname="djdomics" > ifconfig_rl0="DHCP" > keymap="fr.iso.acc" > sshd_enable="YES" > gnome_enable="YES" > >> cat /etc/X11/xorg.conf > Section "ServerLayout" > Identifier "X.org Configured" > Screen 0 "Screen0" 0 0 > InputDevice "Mouse0" "CorePointer" > InputDevice "Keyboard0" "CoreKeyboard" > Option "AllowEmptyInput" "off" > EndSection > > Section "Files" > ModulePath "/usr/local/lib/xorg/modules" > FontPath "/usr/local/lib/X11/fonts/misc/" > FontPath "/usr/local/lib/X11/fonts/TTF/" > FontPath "/usr/local/lib/X11/fonts/OTF" > FontPath "/usr/local/lib/X11/fonts/Type1/" > FontPath "/usr/local/lib/X11/fonts/100dpi/" > FontPath "/usr/local/lib/X11/fonts/75dpi/" > EndSection > > Section "Module" > Load "dbe" > Load "dri" > Load "extmod" > Load "glx" > Load "record" > Load "xtrap" > Load "freetype" > EndSection > > Section "InputDevice" > Identifier "Keyboard0" > Driver "kbd" > Option "XkbLayout" "fr" > EndSection > > Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/sysmouse" > Option "ZAxisMapping" "4 5 6 7" > EndSection > > Section "Monitor" > #DisplaySize 320 240 # mm > Identifier "Monitor0" > VendorName "FUS" > ModelName "C700" > HorizSync 30.0 - 72.0 > VertRefresh 50.0 - 160.0 > Option "DPMS" > EndSection > > Section "Device" > ### Available Driver options are:- > ### Values: : integer, : float, : "True"/"False", > ### : "String", : " Hz/kHz/MHz" > ### [arg]: arg optional > #Option "SWcursor" # [] > #Option "HWcursor" # [] > #Option "NoAccel" # [] > #Option "ShadowFB" # [] > #Option "UseFBDev" # [] > #Option "Rotate" # [] > #Option "VideoKey" # > #Option "FlatPanel" # [] > #Option "FPDither" # [] > #Option "CrtcNumber" # > #Option "FPScale" # [] > #Option "FPTweak" # > #Option "DualHead" # [] > Identifier "Card0" > Driver "nv" > VendorName "nVidia Corporation" > BoardName "NV36 [GeForce FX 5700LE]" > BusID "PCI:1:0:0" > EndSection > > Section "Screen" > Identifier "Screen0" > Device "Card0" > Monitor "Monitor0" > SubSection "Display" > Viewport 0 0 > Depth 1 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 4 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 8 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 15 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 16 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 24 > EndSubSection > EndSection > > > From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 13:24: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 AE255106566B for ; Mon, 13 Apr 2009 13:24:27 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id CC18A8FC15 for ; Mon, 13 Apr 2009 13:24:26 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: by bwz8 with SMTP id 8so2017717bwz.43 for ; Mon, 13 Apr 2009 06:24:25 -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=Otr8UvqX5Slhl7DeXdP8XnAB1eWYj1OsuskKUNTkY64=; b=dtP+xqyQMBEjqKITjkr8451giFiVr7mwD7fXDtKAfPoC8Mo0NO+hK6buwAwMl7dcaE dowdUfWmWX23ikK3R3lwEXYuiavf1C1s5TyD+NHxESbuTqyoL8Ec1O0pw2hR6TuC5bAo S017Ot4zQewLqM47a3fd7VygPBS6mb1Hq47H8= 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=n8hX3159p6Iay3Pbjx1sknEUgAG4+EbmhMzsQjiE9mWsJNYHeL2eOJu7dP9lJPwH7n ucXMRIxRqE3JUoZCri19dO4De9OtJDPw+tR3e4OVgQwMcWWXcrvieJ3N8aWq7OXjLvDQ SEYyHQlzOmjXX8sxBvpvVe1Gc4aVKS/pzys/Q= MIME-Version: 1.0 Received: by 10.223.113.200 with SMTP id b8mr1692277faq.84.1239629065734; Mon, 13 Apr 2009 06:24:25 -0700 (PDT) In-Reply-To: <49E3362B.9040704@gwdg.de> References: <7daacbbe0904130203m62080028v14f6a1e4a3285dc0@mail.gmail.com> <49E3362B.9040704@gwdg.de> Date: Mon, 13 Apr 2009 15:24:25 +0200 Message-ID: <7daacbbe0904130624r70509e06k1ceffecd7e902bb0@mail.gmail.com> From: Dominique Goncalves To: Rainer Hurling Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Subject: Re: Unusable Xorg with USB mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Apr 2009 13:24:28 -0000 Hi Rainer, On Mon, Apr 13, 2009 at 2:55 PM, Rainer Hurling wrote: > Hi Dominique, > > On 13.04.2009 11:03 (UTC+1), Dominique Goncalves wrote: >> >> Hi, >> >> I upgraded my FreeBSD desktop (XFCE4 and some applications) from >> 7.1-RELEASE to 8.0-CURRENT r190942 all ports was build from scratch >> after removing old files with make delete-old delete-old-libs. I should have been more precise, I followed these steps, upgrade to -CURRENT with the usual steps described in UPDATING (buildworld, buildkernel, installworld, installkernel, mergemaster, etc) # rm -fr /usr/local/* /var/db/pkg/* # cd /usr/src # yes | make delete-old # yes | make delete-old-libs and rebuild ports: xorg, xfce4, firefox3 > as far as I know 'make delete-old delete-old-libs' has to be done from > /usr/src and so it removes obsolete files from system (see > /usr/src/ObsoleteFiles.inc). > > To remove ports (/usr/ports) and build from scratch you have to 'pkg_dele= te > -a' or something like this... > >> Now it's very hard to listen music with mplayer, write text with vim, >> browse internet with firefox... it just stop working and restart when >> moving the mouse! > > There had been many changes in CURRENT and xorg in the last time. USB is > totally new, libusb is integrated in the system (please do not install th= at > port!) etc. > > So please read /usr/ports/UPDATING, especially the entries 20090309 and > 20090123. > > Hope I could help, > Rainer > > >> Let me know if you need more information. >> >> Any help is really appreciated, >> Thanks. >> >>> dmesg >> >> Copyright (c) 1992-2009 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> =A0 =A0 =A0 =A0The Regents of the University of California. All rights r= eserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 8.0-CURRENT #0 r190942: Sat Apr 11 22:05:48 CEST 2009 >> =A0 =A0root@djdomics:/usr/obj/usr/src/sys/GENERIC_NODEBUG >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (2000.15-MHz 686-class CPU) >> =A0Origin =3D "GenuineIntel" =A0Id =3D 0xf24 =A0Stepping =3D 4 >> >> =A0Features=3D0x3febfbff >> real memory =A0=3D 805306368 (768 MB) >> avail memory =3D 774045696 (738 MB) >> ACPI APIC Table: >> MADT: Forcing active-low polarity and level trigger for SCI >> ioapic0 irqs 0-23 on motherboard >> kbd1 at kbdmux0 >> acpi0: on motherboard >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >> acpi_button0: on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> agp0: on hostb0 >> pcib1: at device 1.0 on pci0 >> pci1: on pcib1 >> vgapci0: mem >> 0xde000000-0xdeffffff,0xc0000000-0xcfffffff irq 16 at device 0.0 on >> pci1 >> isab0: at device 2.0 on pci0 >> isa0: on isab0 >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 2.5 on >> pci0 >> ata0: on atapci0 >> ata0: [ITHREAD] >> ata1: on atapci0 >> ata1: [ITHREAD] >> ohci0: mem 0xdfffc000-0xdfffcfff irq 20 at >> device 3.0 on pci0 >> ohci0: [ITHREAD] >> usbus0: on ohci0 >> ohci1: mem 0xdfffd000-0xdfffdfff irq 21 at >> device 3.1 on pci0 >> ohci1: [ITHREAD] >> usbus1: on ohci1 >> ohci2: mem 0xdfffe000-0xdfffefff irq 22 at >> device 3.2 on pci0 >> ohci2: [ITHREAD] >> usbus2: on ohci2 >> ehci0: mem 0xdffff000-0xdfffffff >> irq 23 at device 3.3 on pci0 >> ehci0: [ITHREAD] >> usbus3: EHCI version 1.0 >> usbus3: on ehci0 >> pcm0: port >> 0xdc00-0xdc1f,0xd800-0xd80f,0xd400-0xd40f,0xd000-0xd03f irq 19 at >> device 8.0 on pci0 >> pcm0: [ITHREAD] >> pcm0: system configuration >> =A0SubVendorID: 0x1412, SubDeviceID: 0xd63b >> =A0XIN2 Clock Source: 22.5792MHz(44.1kHz*512) >> =A0MPU-401 UART(s) #: 1 >> =A0AC'97 codec: not exist >> =A0ADC #: 4 >> =A0DAC #: 4 >> =A0Multi-track converter type: I2S(96KHz support, 24bit resolution, ID#0= x2) >> =A0S/PDIF(IN/OUT): 1/1 ID# 0x00 >> =A0GPIO(mask/dir/state): 0x04/0xfb/0x7e >> rl0: port 0xcc00-0xccff mem >> 0xdfffbf00-0xdfffbfff irq 18 at device 11.0 on pci0 >> miibus0: on rl0 >> rlphy0: PHY 0 on miibus0 >> rlphy0: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> rl0: Ethernet address: 00:10:dc:82:9b:d2 >> rl0: [ITHREAD] >> atrtc0: port 0x70-0x71 irq 8 on acpi0 >> fdc1: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq >> 6 drq 2 on acpi0 >> fdc1: [FILTER] >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >> uart0: [FILTER] >> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >> uart1: [FILTER] >> ppc0: port 0x378-0x37f irq 7 on acpi0 >> ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode >> ppc0: [ITHREAD] >> ppbus0: on ppc0 >> plip0: on ppbus0 >> plip0: [ITHREAD] >> lpt0: on ppbus0 >> lpt0: [ITHREAD] >> lpt0: Interrupt-driven port >> ppi0: on ppbus0 >> cpu0: on acpi0 >> p4tcc0: on cpu0 >> pmtimer0 on isa0 >> orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd27ff pnpid >> ORM0000 on isa0 >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=3D0x300> >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa= 0 >> atkbdc0: at port 0x60,0x64 on isa0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> fdc0: No FDOUT register! >> Timecounter "TSC" frequency 2000150592 Hz quality 800 >> Timecounters tick every 1.000 msec >> usbus0: 12Mbps Full Speed USB v1.0 >> usbus1: 12Mbps Full Speed USB v1.0 >> usbus2: 12Mbps Full Speed USB v1.0 >> usbus3: 480Mbps High Speed USB v2.0 >> ad0: 57241MB at ata0-master UDMA100 >> 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 >> ad1: 57241MB at ata0-slave UDMA100 >> uhub0: 2 ports with 2 removable, self powered >> uhub1: 2 ports with 2 removable, self powered >> uhub2: 2 ports with 2 removable, self powered >> acd0: DVDROM at ata1-master UDMA33 >> GEOM: ad0: partition 1 does not start on a track boundary. >> GEOM: ad0: partition 1 does not end on a track boundary. >> acd1: CDRW at ata1-slave UDMA33 >> GEOM: ad0s2: geometry does not match label (255h,63s !=3D 16h,255s). >> GEOM: ad1: partition 1 does not start on a track boundary. >> GEOM: ad1: partition 1 does not end on a track boundary. >> uhub3: 6 ports with 6 removable, self powered >> acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 >> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 >> cd0 at ata1 bus 0 target 1 lun 0 >> cd0: Removable CD-ROM SCSI-0 device >> cd0: 33.000MB/s transfers >> cd0: cd present [196100 x 2048 byte records] >> cd1 at ata1 bus 0 target 0 lun 0 >> cd1: Removable CD-ROM SCSI-0 device >> cd1: 33.000MB/s transfers >> cd1: cd present [3510947 x 2048 byte records] >> GEOM_LABEL: Label for provider acd0 is iso9660/DIE_HARD_1. >> GEOM_LABEL: Label for provider ad0s2a is ufsid/47fa91abbef03a13. >> GEOM_LABEL: Label for provider ad0s2d is ufsid/47fa91ad7b28768a. >> GEOM_LABEL: Label for provider ad0s2e is ufsid/47fa91abefc1e226. >> GEOM_LABEL: Label for provider ad0s2f is ufsid/47fa91abfb5c1768. >> GEOM: ad1s2: geometry does not match label (255h,63s !=3D 16h,255s). >> GEOM: ad1s3: geometry does not match label (16h,63s !=3D 16h,255s). >> ugen2.2: at usbus2 >> ums0: on usbus2 >> ums0: 3 buttons and [XYZ] coordinates ID=3D0 >> GEOM_LABEL: Label for provider acd1 is iso9660/CDROM. >> GEOM_LABEL: Label for provider ad1s2a is ufsid/423b25e8c0bf6015. >> GEOM_LABEL: Label for provider ad1s2d is ufsid/423b25e933d9f5b1. >> GEOM_LABEL: Label for provider ad1s2e is ufsid/423b25e88d1a575d. >> GEOM_LABEL: Label for provider ad1s2f is ufsid/423b25e8f04b19a7. >> GEOM_LABEL: Label for provider ad1s3g is ufsid/423de7c40ececa0b. >> GEOM_LABEL: Label for provider ad1s3i is ufsid/423de7c57cc3c44b. >> GEOM_LABEL: Label for provider ad1s3j is ufsid/423de7cf5ab394ca. >> acd1: FAILURE - READ_BIG ILLEGAL REQUEST asc=3D0x64 ascq=3D0x00 >> Trying to mount root from ufs:/dev/ad0s2a >> GEOM_LABEL: Label ufsid/47fa91abbef03a13 removed. >> GEOM_LABEL: Label for provider ad0s2a is ufsid/47fa91abbef03a13. >> GEOM_LABEL: Label ufsid/47fa91abefc1e226 removed. >> GEOM_LABEL: Label for provider ad0s2e is ufsid/47fa91abefc1e226. >> GEOM_LABEL: Label ufsid/47fa91abfb5c1768 removed. >> GEOM_LABEL: Label for provider ad0s2f is ufsid/47fa91abfb5c1768. >> GEOM_LABEL: Label ufsid/47fa91ad7b28768a removed. >> GEOM_LABEL: Label for provider ad0s2d is ufsid/47fa91ad7b28768a. >> GEOM_LABEL: Label ufsid/47fa91abbef03a13 removed. >> GEOM_LABEL: Label ufsid/47fa91abefc1e226 removed. >> GEOM_LABEL: Label ufsid/47fa91abfb5c1768 removed. >> GEOM_LABEL: Label ufsid/47fa91ad7b28768a removed. >> rl0: link state changed to UP >> >>> vmstat -i >> >> interrupt =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0total =A0 = =A0 =A0 rate >> irq1: atkbd0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01823 =A0 =A0= =A0 =A0 =A01 >> irq14: ata0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A010943 =A0 =A0= =A0 =A0 =A07 >> irq15: ata1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4692 =A0 =A0= =A0 =A0 =A03 >> irq18: rl0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 32566 =A0 =A0= =A0 =A0 22 >> irq19: pcm0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A099133 =A0 =A0= =A0 =A0 68 >> irq22: ohci2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 31197 =A0 =A0 = =A0 =A0 21 >> irq23: ehci0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 = =A0 =A0 =A0 =A00 >> cpu0: timer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02872088 =A0 =A0 = =A0 1998 >> Total =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A03052444 =A0= =A0 =A0 2124 >> >>> cat /etc/rc.conf >> >> # -- sysinstall generated deltas -- # Mon Apr =A07 23:50:43 2008 >> # Created: Mon Apr =A07 23:50:43 2008 >> # Enable network daemons for user convenience. >> # Please make all changes to this file, not to /etc/defaults/rc.conf. >> # This file now contains just the overrides from /etc/defaults/rc.conf. >> hostname=3D"djdomics" >> ifconfig_rl0=3D"DHCP" >> keymap=3D"fr.iso.acc" >> sshd_enable=3D"YES" >> gnome_enable=3D"YES" >> >>> cat /etc/X11/xorg.conf >> >> Section "ServerLayout" >> =A0 =A0 =A0 =A0Identifier =A0 =A0 "X.org Configured" >> =A0 =A0 =A0 =A0Screen =A0 =A0 =A00 =A0"Screen0" 0 0 >> =A0 =A0 =A0 =A0InputDevice =A0 =A0"Mouse0" "CorePointer" >> =A0 =A0 =A0 =A0InputDevice =A0 =A0"Keyboard0" "CoreKeyboard" >> =A0 =A0 =A0 =A0Option =A0 =A0 =A0 =A0 "AllowEmptyInput" "off" >> EndSection >> >> Section "Files" >> =A0 =A0 =A0 =A0ModulePath =A0 "/usr/local/lib/xorg/modules" >> =A0 =A0 =A0 =A0FontPath =A0 =A0 "/usr/local/lib/X11/fonts/misc/" >> =A0 =A0 =A0 =A0FontPath =A0 =A0 "/usr/local/lib/X11/fonts/TTF/" >> =A0 =A0 =A0 =A0FontPath =A0 =A0 "/usr/local/lib/X11/fonts/OTF" >> =A0 =A0 =A0 =A0FontPath =A0 =A0 "/usr/local/lib/X11/fonts/Type1/" >> =A0 =A0 =A0 =A0FontPath =A0 =A0 "/usr/local/lib/X11/fonts/100dpi/" >> =A0 =A0 =A0 =A0FontPath =A0 =A0 "/usr/local/lib/X11/fonts/75dpi/" >> EndSection >> >> Section "Module" >> =A0 =A0 =A0 =A0Load =A0"dbe" >> =A0 =A0 =A0 =A0Load =A0"dri" >> =A0 =A0 =A0 =A0Load =A0"extmod" >> =A0 =A0 =A0 =A0Load =A0"glx" >> =A0 =A0 =A0 =A0Load =A0"record" >> =A0 =A0 =A0 =A0Load =A0"xtrap" >> =A0 =A0 =A0 =A0Load =A0"freetype" >> EndSection >> >> Section "InputDevice" >> =A0 =A0 =A0 =A0Identifier =A0"Keyboard0" >> =A0 =A0 =A0 =A0Driver =A0 =A0 =A0"kbd" >> =A0 =A0 =A0 =A0Option =A0 =A0 =A0"XkbLayout" "fr" >> EndSection >> >> Section "InputDevice" >> =A0 =A0 =A0 =A0Identifier =A0"Mouse0" >> =A0 =A0 =A0 =A0Driver =A0 =A0 =A0"mouse" >> =A0 =A0 =A0 =A0Option =A0 =A0 =A0"Protocol" "auto" >> =A0 =A0 =A0 =A0Option =A0 =A0 =A0"Device" "/dev/sysmouse" >> =A0 =A0 =A0 =A0Option =A0 =A0 =A0"ZAxisMapping" "4 5 6 7" >> EndSection >> >> Section "Monitor" >> =A0 =A0 =A0 =A0#DisplaySize =A0 =A0 =A0320 =A0 240 =A0 =A0 # mm >> =A0 =A0 =A0 =A0Identifier =A0 "Monitor0" >> =A0 =A0 =A0 =A0VendorName =A0 "FUS" >> =A0 =A0 =A0 =A0ModelName =A0 =A0"C700" >> =A0 =A0 =A0 =A0HorizSync =A0 =A030.0 - 72.0 >> =A0 =A0 =A0 =A0VertRefresh =A050.0 - 160.0 >> =A0 =A0 =A0 =A0Option =A0 =A0 =A0"DPMS" >> EndSection >> >> Section "Device" >> =A0 =A0 =A0 =A0### Available Driver options are:- >> =A0 =A0 =A0 =A0### Values: : integer, : float, : "True"/"Fal= se", >> =A0 =A0 =A0 =A0### : "String", : " Hz/kHz/MHz" >> =A0 =A0 =A0 =A0### [arg]: arg optional >> =A0 =A0 =A0 =A0#Option =A0 =A0 "SWcursor" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# [] >> =A0 =A0 =A0 =A0#Option =A0 =A0 "HWcursor" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# [] >> =A0 =A0 =A0 =A0#Option =A0 =A0 "NoAccel" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 # [] >> =A0 =A0 =A0 =A0#Option =A0 =A0 "ShadowFB" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# [] >> =A0 =A0 =A0 =A0#Option =A0 =A0 "UseFBDev" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# [] >> =A0 =A0 =A0 =A0#Option =A0 =A0 "Rotate" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# [] >> =A0 =A0 =A0 =A0#Option =A0 =A0 "VideoKey" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# >> =A0 =A0 =A0 =A0#Option =A0 =A0 "FlatPanel" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 # [] >> =A0 =A0 =A0 =A0#Option =A0 =A0 "FPDither" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# [] >> =A0 =A0 =A0 =A0#Option =A0 =A0 "CrtcNumber" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0# >> =A0 =A0 =A0 =A0#Option =A0 =A0 "FPScale" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 # [] >> =A0 =A0 =A0 =A0#Option =A0 =A0 "FPTweak" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 # >> =A0 =A0 =A0 =A0#Option =A0 =A0 "DualHead" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# [] >> =A0 =A0 =A0 =A0Identifier =A0"Card0" >> =A0 =A0 =A0 =A0Driver =A0 =A0 =A0"nv" >> =A0 =A0 =A0 =A0VendorName =A0"nVidia Corporation" >> =A0 =A0 =A0 =A0BoardName =A0 "NV36 [GeForce FX 5700LE]" >> =A0 =A0 =A0 =A0BusID =A0 =A0 =A0 "PCI:1:0:0" >> EndSection >> >> Section "Screen" >> =A0 =A0 =A0 =A0Identifier "Screen0" >> =A0 =A0 =A0 =A0Device =A0 =A0 "Card0" >> =A0 =A0 =A0 =A0Monitor =A0 =A0"Monitor0" >> =A0 =A0 =A0 =A0SubSection "Display" >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Viewport =A0 0 0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Depth =A0 =A0 1 >> =A0 =A0 =A0 =A0EndSubSection >> =A0 =A0 =A0 =A0SubSection "Display" >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Viewport =A0 0 0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Depth =A0 =A0 4 >> =A0 =A0 =A0 =A0EndSubSection >> =A0 =A0 =A0 =A0SubSection "Display" >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Viewport =A0 0 0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Depth =A0 =A0 8 >> =A0 =A0 =A0 =A0EndSubSection >> =A0 =A0 =A0 =A0SubSection "Display" >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Viewport =A0 0 0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Depth =A0 =A0 15 >> =A0 =A0 =A0 =A0EndSubSection >> =A0 =A0 =A0 =A0SubSection "Display" >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Viewport =A0 0 0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Depth =A0 =A0 16 >> =A0 =A0 =A0 =A0EndSubSection >> =A0 =A0 =A0 =A0SubSection "Display" >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Viewport =A0 0 0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Depth =A0 =A0 24 >> =A0 =A0 =A0 =A0EndSubSection >> EndSection >> >> >> > --=20 There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 13:49: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 54B891065670 for ; Mon, 13 Apr 2009 13:49:01 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailhub.cs.uoguelph.ca (mailhub.cs.uoguelph.ca [131.104.94.205]) by mx1.freebsd.org (Postfix) with ESMTP id F015A8FC15 for ; Mon, 13 Apr 2009 13:49:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by mailhub.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n3DDmxDE011009 for ; Mon, 13 Apr 2009 09:48:59 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n3DDtP020759 for ; Mon, 13 Apr 2009 09:55:25 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 13 Apr 2009 09:55:25 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.205 Subject: [HEADSUP] nfsserver module now depends on nfssvc 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: Mon, 13 Apr 2009 13:49:01 -0000 Oops, sorry. I should have sent this out before the commit... The nfsserver modules now depends on another module called nfssvc. You'll need to do a fresh "config ", followed by a build sequence. If you don't "make KERNEL= install" and run the nfsd for a config that doesn't have "options NFSSERVER", you'll need to build/copy both the nfsserver and nfssvc modules. rick From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 13:53: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 AA04B106564A for ; Mon, 13 Apr 2009 13:53:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailhub.cs.uoguelph.ca (mailhub.cs.uoguelph.ca [131.104.94.205]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9088FC1C for ; Mon, 13 Apr 2009 13:53:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by mailhub.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n3DDr102012476; Mon, 13 Apr 2009 09:53:01 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n3DDxR721472; Mon, 13 Apr 2009 09:59:27 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 13 Apr 2009 09:59:27 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Sean Bruno In-Reply-To: <1239599205.24831.3.camel@localhost.localdomain> Message-ID: References: <1239599205.24831.3.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.205 Cc: freebsd-current@freebsd.org Subject: Re: NFS errors on compile of -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 13:53:11 -0000 On Sun, 12 Apr 2009, Sean Bruno wrote: > [sean@bsd64 ~/bsd/head/sys/amd64/compile/SBP_TARG]$ make > linking kernel.debug > nfs_srvsubs.o(.text+0xd0c): In function `nfsrv_modevent': > ../../../nfsserver/nfs_srvsubs.c:560: undefined reference to > `nfsd_call_nfsserver' > nfs_srvsubs.o(.text+0xd42):../../../nfsserver/nfs_srvsubs.c:569: > undefined reference to `nfsd_call_nfsserver' > *** Error code 1 > > Stop in /usr/home/sean/bsd/head/sys/amd64/compile/SBP_TARG. > Yes, sorry. I just sent a HEADSUP, but should have done it before doing the commit. You need to do a fresh "config " and kernel build sequence, so that nfs_nfssvc.c gets built. rick From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 15:27: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 9FC461065673 for ; Mon, 13 Apr 2009 15:27:44 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: from iron2.pdx.net (iron2.pdx.net [69.64.224.71]) by mx1.freebsd.org (Postfix) with ESMTP id 613F78FC1A for ; Mon, 13 Apr 2009 15:27:44 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: (qmail 30675 invoked from network); 13 Apr 2009 08:27:42 -0700 Received: from 069-064-235-060.pdx.net (HELO ?192.168.1.51?) (69.64.235.60) by iron2.pdx.net with SMTP; 13 Apr 2009 08:27:42 -0700 From: Sean Bruno To: Rick Macklem In-Reply-To: References: <1239599205.24831.3.camel@localhost.localdomain> Content-Type: text/plain Date: Mon, 13 Apr 2009 08:27:43 -0700 Message-Id: <1239636463.24831.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: NFS errors on compile of -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 15:27:45 -0000 On Mon, 2009-04-13 at 09:59 -0400, Rick Macklem wrote: > > On Sun, 12 Apr 2009, Sean Bruno wrote: > > > [sean@bsd64 ~/bsd/head/sys/amd64/compile/SBP_TARG]$ make > > linking kernel.debug > > nfs_srvsubs.o(.text+0xd0c): In function `nfsrv_modevent': > > ../../../nfsserver/nfs_srvsubs.c:560: undefined reference to > > `nfsd_call_nfsserver' > > nfs_srvsubs.o(.text+0xd42):../../../nfsserver/nfs_srvsubs.c:569: > > undefined reference to `nfsd_call_nfsserver' > > *** Error code 1 > > > > Stop in /usr/home/sean/bsd/head/sys/amd64/compile/SBP_TARG. > > > Yes, sorry. I just sent a HEADSUP, but should have done it before doing > the commit. You need to do a fresh "config " and kernel build > sequence, so that nfs_nfssvc.c gets built. > > rick > Yup. Thanks! Sean From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 15:34:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F0D510656E2; Mon, 13 Apr 2009 15:34:06 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from ns2.bafirst.com (72-12-2-19.static.networktel.net [72.12.2.19]) by mx1.freebsd.org (Postfix) with ESMTP id 165638FC15; Mon, 13 Apr 2009 15:34:05 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from HOME.encontacto.net ([189.190.9.26]) by ns2.bafirst.com with esmtp; Mon, 13 Apr 2009 09:54:02 -0500 id 000D4CF6.49E3520B.000009E3 Received: from localhost (localhost [127.0.0.1]) (uid 80) by HOME.encontacto.net with local; Mon, 13 Apr 2009 05:45:00 -0500 id 0004AC32.49E317AC.0000049D Received: from local69.local.net.mx (local69.local.net.mx [192.168.1.69]) by econet.encontacto.net (Horde Framework) with HTTP; Mon, 13 Apr 2009 05:45:00 -0500 Message-ID: <20090413054500.1241102uwgs74khc@econet.encontacto.net> Date: Mon, 13 Apr 2009 05:45:00 -0500 From: eculp To: current , freebsd-emulation MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (5.0-cvs) X-Remote-Browser: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.0.8) Gecko/2009040106 Firefox/3.0.4, Ant.com Toolbar 1.3 X-IMP-Server: 189.190.9.26 X-Originating-IP: 192.168.1.69 X-Originating-User: eculp@encontacto.net Cc: Subject: Flash10, with up to date current, not even recoginized with about:plugins. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Apr 2009 15:34:07 -0000 I'm using up to date current # uname -a FreeBSD ed.local.net.mx 8.0-CURRENT FreeBSD 8.0-CURRENT #203: Sun Apr =20 12 15:13:50 CDT 2009 A copy of my about:plugins is at: http://www.encontacto.net/SHARE/About_Plugins.html I have installed all the f8 ports, I think. linux-f8-alsa-lib-1.0.15 linux-f8-aspell-0.60.5 linux-f8-atk-1.20.0 linux-f8-cairo-1.4.14 linux-f8-curl-7.18.2 linux-f8-expat-2.0.1 linux-f8-fontconfig-2.4.2 linux-f8-gtk2-2.12.8 linux-f8-hicolor-icon-theme-0.5 linux-f8-jpeg-6b linux-f8-libidn-0.6.14 linux-f8-libsigc++20-2.0.18 linux-f8-libssh2-0.18 linux-f8-nspr-4.7.3 linux-f8-nss-3.12.2.0 linux-f8-openssl-0.9.8b linux-f8-pango-1.18.4 linux-f8-png-1.2.22 linux-f8-scim-libs-1.4.7 linux-f8-sqlite3-3.4.2 linux-f8-tiff-3.8.2 linux-f8-xorg-libs-7.3_2 linux_base-f8-8_11 linux-flashplugin-10.0r22 nspluginwrapper-1.2.2_2 # nspluginwrapper -v -a -i Auto-install plugins from /usr/local/lib/browser_plugins Looking for plugins in /usr/local/lib/browser_plugins Auto-install plugins from /usr/local/lib/firefox/plugins Looking for plugins in /usr/local/lib/firefox/plugins Auto-install plugins from /usr/local/lib/linux-mozilla/plugins Looking for plugins in /usr/local/lib/linux-mozilla/plugins Install plugin /usr/local/lib/linux-mozilla/plugins/nphelix.so into /usr/local/lib/browser_plugins/npwrapper.nphelix.so Install plugin /usr/local/lib/linux-mozilla/plugins/mplayerplug-in-dvx.so into /usr/local/lib/browser_plugins/npwrapper.mplayerplug-in-dvx.so Install plugin /usr/local/lib/linux-mozilla/plugins/mplayerplug-in-qt.so into /usr/local/lib/browser_plugins/npwrapper.mplayerplug-in-qt.so Install plugin /usr/local/lib/linux-mozilla/plugins/mplayerplug-in-rm.so into /usr/local/lib/browser_plugins/npwrapper.mplayerplug-in-rm.so Install plugin /usr/local/lib/linux-mozilla/plugins/mplayerplug-in-wmp.so into /usr/local/lib/browser_plugins/npwrapper.mplayerplug-in-wmp.so Install plugin /usr/local/lib/linux-mozilla/plugins/mplayerplug-in.so into /usr/local/lib/browser_plugins/npwrapper.mplayerplug-in.so Install plugin /usr/local/lib/linux-mozilla/plugins/libflashplayer.so into /usr/local/lib/browser_plugins/npwrapper.libflashplayer.so Auto-install plugins from /usr/local/lib/npapi/linux-flashplugin Looking for plugins in /usr/local/lib/npapi/linux-flashplugin Install plugin /usr/local/lib/npapi/linux-flashplugin/libflashplayer.so into /usr/local/lib/browser_plugins/npwrapper.libflashplayer.so Auto-install plugins from /root/.mozilla/plugins Looking for plugins in /root/.mozilla/plugins Install plugin /root/.mozilla/plugins/nppdf.so into /root/.mozilla/plugins/npwrapper.nppdf.so From that I would assume that it is working but it isn't and I'm =20 stymied. Over the years I've used flash 7 and later 9 with no major =20 problems. Any suggestions on what I might have missed would be =20 appreciated. ed PS I did notice a userid (0) unknown with a couple of the linux-f8 =20 portw while installing them with portmaster and they installed fine. =20 IIRC gtk2 was one and scim was the other. From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 15:56: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 1765C106564A; Mon, 13 Apr 2009 15:56:33 +0000 (UTC) (envelope-from CQG00620@nifty.ne.jp) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id D62748FC1A; Mon, 13 Apr 2009 15:56:32 +0000 (UTC) (envelope-from CQG00620@nifty.ne.jp) Received: from asahi-net.jp (h205004.dynamic.ppp.asahi-net.or.jp [61.114.205.4]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id 6788170220; Tue, 14 Apr 2009 00:35:47 +0900 (JST) Date: Tue, 14 Apr 2009 00:35:47 +0900 From: WATANABE Kazuhiro To: freebsd-current In-Reply-To: <49DDF942.9040808@FreeBSD.org> References: <49DDF942.9040808@FreeBSD.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20090413153547.6788170220@mail1.asahi-net.or.jp> Cc: Jean-S?bastien P?dron Subject: Re: New ioctl to support Enhanced CD (or Extra CD) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Apr 2009 15:56:33 -0000 Hi. I've tested your patch, and found some problems. (1) Cannot mount a data part. capricorn# cdcontrol info Starting track =3D 1, ending track =3D 12, TOC size =3D 106 bytes track start duration block length type ------------------------------------------------- 1 0:02.00 6:18.00 0 28350 audio 2 6:20.00 6:03.10 28350 27235 audio 3 12:23.10 5:32.37 55585 24937 audio 4 17:55.47 3:35.65 80522 16190 audio 5 21:31.37 5:28.33 96712 24633 audio 6 26:59.70 3:58.15 121345 17865 audio 7 30:58.10 4:57.62 139210 22337 audio 8 35:55.72 4:58.55 161547 22405 audio 9 40:54.52 6:28.68 183952 29168 audio 10 47:23.45 5:01.50 213120 22625 audio 11 52:25.20 6:48.32 235745 30632 audio 12 61:45.52 8:10.74 277777 36824 data 170 69:56.51 - 314601 - - capricorn# mount_cd9660 /dev/acd0 /cdrom mount_cd9660: /dev/acd0: Invalid argument capricorn#=20 (2) When I read the last audio track via /dev/acd0tXX, the output data has wrong length. capricorn# dd if=3D/dev/acd0t10 bs=3D2352 > /dev/null 22625+0 records in 22625+0 records out # correct length 53214000 bytes transferred in 19.750258 secs (2694345 bytes/sec) capricorn# dd if=3D/dev/acd0t11 bs=3D2352 > /dev/null dd: /dev/acd0t11: Input/output error 41883+0 records in 41883+0 records out # wrong length (!=3D 30632) 98508816 bytes transferred in 35.804241 secs (2751317 bytes/sec) capricorn#=20 (3) When I play the last audio track with cdcontrol(1), the "next" command doesn't work (the drive stops playing). capricorn# cdcontrol play 11 capricorn# cdcontrol status Audio status =3D 17, current track =3D 11, current position =3D 0:= 13.68 No media catalog info available Left volume =3D 255, right volume =3D 255 capricorn# cdcontrol next acd0: FAILURE - PLAY_MSF ILLEGAL REQUEST asc=3D0x64 ascq=3D0x00 capricorn# cdcontrol status Audio status =3D 0, current track =3D 11, current position =3D 0:2= 6.57 Media catalog is inactive Left volume =3D 255, right volume =3D 255 capricorn#=20 (These tests are done with Noriyuki Makihara's "Such a Lovely Place" (Sony Records, 1997).) By the way, I have an another patch that solves problems that you have pointed out and described above. http://homepage2.nifty.com/dumb_show/unix/work/ata.releng71.diff http://homepage2.nifty.com/dumb_show/unix/work/cdcontrol.releng71.diff I've tested the patch on FreeBSD 7.1-RELEASE and 8-current. This patch is not my original. The original patch was written by Chiharu Shibata for FreeBSD 4.4-RELEASE. http://www32.ocn.ne.jp/~chi/myprog/FreeBSD/atapi-cd.html One year later he rewrote the patch for FreeBSD 4.7-RELEASE. It also includes some quirks for old CD-ROM drives which are generally used with NEC PC-98 series. http://home.jp.freebsd.org/cgi-bin/showmail/FreeBSD-users-jp/74432 I rewrote the latter patch for FreeBSD 5.x, 6.x, and 7.x. At Thu, 09 Apr 2009 15:33:54 +0200, Jean-S?bastien P?dron wrote: > Hello, >=20 > Enhanced CD (or Extra CA) is an Audio CD with an additionnal data track > at the end. Audio tracks belong to the first session while the data > track belongs to the second session. Therefore the last audio track ends > way before the data track start. >=20 > The first consequence is that the duration of the last audio track isn't > reported correctly. Here is the output of cdcontrol(1) with such a CD[1]: > $ cdcontrol info > ... > 12 46:03.67 9:54.43 207142 44593 audio > 13 55:58.35 6:38.51 251735 29901 data >=20 > The expected output is: > $ cdcontrol info > ... > 12 46:03.67 7:22.43 207142 33193 audio > 13 55:58.35 6:38.51 251735 29901 data >=20 > A more "audible" consequence is that cdparanoia(1) copies 9'54" of data > instead of 7'22". The end of the ripped file is full of garbage. >=20 > I made a patch (attached) that adds a new ioctl to query the start > address of the last session. This new ioctl is named > CDIOREADLASTSESSIONADDR. The patch also includes changes to cdcontrol(1). >=20 > I added a new member at the end of struct acd_softc to store the last > session address. I don't know if this causes ABI breakage. >=20 > Linux' corresponding ioctl is CDROMMULTISESSION. Beside this address, it > returns a flag named "xa_flag". Currently, I don't understand what it is > but it may be useful to add it to our ioctl too if someone knows its > purpose. >=20 > Before I spend some time to teach cdparanoia(1) about this new ioctl, > I'd like some feedback on this patch, especially the name and the struct > ioc_read_last_session_addr. I would appreciate some test reports too! :) >=20 > [1] This was tested with Avishai Cohen's last album, "Aurora". >=20 > -- > Jean-S=E9bastien P=E9dron > http://www.dumbbell.fr/ (snip) --- WATANABE Kazuhiro (CQG00620@nifty.ne.jp) From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 17:55: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 73431106566C for ; Mon, 13 Apr 2009 17:55:10 +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 098408FC1E for ; Mon, 13 Apr 2009 17:55:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6475146B09; Mon, 13 Apr 2009 13:55:07 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 1E9CC8A053; Mon, 13 Apr 2009 13:54:52 -0400 (EDT) From: John Baldwin To: Diego Depaoli Date: Mon, 13 Apr 2009 13:05:12 -0400 User-Agent: KMail/1.9.7 References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904071026.26735.jhb@freebsd.org> <83e5fb980904081237u4e2979b9tad38d62a061d85b8@mail.gmail.com> In-Reply-To: <83e5fb980904081237u4e2979b9tad38d62a061d85b8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904131305.12605.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 13 Apr 2009 13:54:52 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=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: AMD 780G chipset major issues 3/3 (btx) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Apr 2009 17:55:11 -0000 On Wednesday 08 April 2009 3:37:38 pm Diego Depaoli wrote: > On Tue, Apr 7, 2009 at 4:26 PM, John Baldwin wrote: > > On Monday 06 April 2009 5:02:53 pm Diego Depaoli wrote: > >> And finally... > >> if I enable ahci in bios the system won't boot =A0with btx halted. > >> Ctrl+alt+del is the only allowed action. > >> > >> Yes... it's a low cost motherboard, but I'm a bit confused. > > > > What OS release are you running? >=20 > 8.0-CURRENT FreeBSD 8.0-CURRENT #19: Sun Apr 5 02:25:34 CEST 2009 > FreeBSD version 800074 Very odd, can you get a copy of the BTX fault output? =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 17:55: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 5E5B61065673; Mon, 13 Apr 2009 17:55:14 +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 6BD388FC08; Mon, 13 Apr 2009 17:55:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3BC7146B4C; Mon, 13 Apr 2009 13:55:12 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 2D4DB8A052; Mon, 13 Apr 2009 13:54:51 -0400 (EDT) From: John Baldwin To: Norikatsu Shigemura Date: Mon, 13 Apr 2009 13:04:43 -0400 User-Agent: KMail/1.9.7 References: <49BD117B.2080706@163.com> <012d01c9b706$ccace720$6606b560$@Sparrevohn@btinternet.com> <20090409003108.fe768d54.nork@FreeBSD.org> In-Reply-To: <20090409003108.fe768d54.nork@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904131304.43585.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 13 Apr 2009 13:54:51 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Thomas Sparrevohn , freebsd-current@freebsd.org, 'Damian Gerow' Subject: Re: ZFS checksum errors on USB attach (Was: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Apr 2009 17:55:14 -0000 On Wednesday 08 April 2009 11:31:08 am Norikatsu Shigemura wrote: > Hi jhb! > > I got ZFS checksum error issue, too. So I found a way of fixing > this issue. Please back out following change. > > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > revision 1.5 > date: 2009/03/18 16:19:44; author: jhb; state: Exp; lines: +2 -0 > SVN rev 189967 on 2009-03-18 16:19:44Z by jhb > > The zfs_get_xattrdir() function is used to find the extended attribute > directory for a znode. When the directory already exists, it returns a > referenced but unlocked vnode. When a directory does not yet exist, it > calls zfs_make_xattrdir() to create a new one. zfs_make_xattrdir() returns > the vnode both referenced and and locked and zfs_get_xattrdir() was leaking > this vnode lock to its callers. Fix this by dropping the vnode lock if > zfs_make_xattrdir() successfully creates a new extended attribute > directory. > > Reviewed by: pjd > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > [Validation] > 1. I got ZFS checksum error issue > 2. Backup > 3. Restructure ZPool > 4. Restore (But ZFS checksum error) > 5. Restructure ZPool with kern.smp.disabled=1 > (Almost good, but...) > 6. Restore > 7. Backout zfs_dir#1.5 > 8. Good works for me > > I tested many backup&restore:-). I have no idea how this would break what you are seeing. The zfs_get_xattrdir() function is only called from zfs_lookup() when LOOKUP_XATTR is specified, and that only happens from the extended attribute VOP routines. Are you using extended attributes at all? Also, have you tried running with INVARIANTS and DEBUG_VFS_LOCKS to catch missing locks? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 18:01:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 380A41065675 for ; Mon, 13 Apr 2009 18:01:34 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 1123B8FC1C for ; Mon, 13 Apr 2009 18:01:33 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 7A1282C2ACE; Mon, 13 Apr 2009 13:01:33 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vVnSlrSuBZ9r; Mon, 13 Apr 2009 13:01:25 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 6EC472C2A63; Mon, 13 Apr 2009 13:01:25 -0500 (CDT) Message-ID: <49E37DF4.5010301@cs.rice.edu> Date: Mon, 13 Apr 2009 13:01:24 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: Garrett Cooper References: <49E11CE7.5050903@cs.rice.edu> <49E172A3.2000108@samsco.org> <49E174DE.90603@cs.rice.edu> <7d6fde3d0904121506u5ed82765oe6fd73231f4c6b97@mail.gmail.com> In-Reply-To: <7d6fde3d0904121506u5ed82765oe6fd73231f4c6b97@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: [Fwd: svn commit: r190949 - head/sys/vm] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Apr 2009 18:01:34 -0000 Garrett Cooper wrote: > On Sat, Apr 11, 2009 at 9:58 PM, Alan Cox wrote: > >> Scott Long wrote: >> >>> Off the top of my head, I would almost expect this to conflict with >>> Java. Haven't tried it, though, so I can't do anything more than >>> speculate. However, I would encourage testing here. >>> >>> >> It doesn't. I verified that the Sun JVM works. >> > > Has this been verified with Perl / Python yet? > -Garrett > Python, yes. In general, I wouldn't worry about any language implementation that doesn't include a JIT compiler. Alan From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 18:50: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 EF7D0106564A for ; Mon, 13 Apr 2009 18:50: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 AFAEB8FC15 for ; Mon, 13 Apr 2009 18:50:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CE07146B51; Mon, 13 Apr 2009 14:50:50 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 810A88A04D; Mon, 13 Apr 2009 14:50:18 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 13 Apr 2009 14:32:55 -0400 User-Agent: KMail/1.9.7 References: <49E1819B.7000604@jrv.org> In-Reply-To: <49E1819B.7000604@jrv.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904131432.55697.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 13 Apr 2009 14:50:18 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "James R. Van Artsdalen" Subject: Re: can't boot 5.5 TB GPT disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Apr 2009 18:50:57 -0000 On Sunday 12 April 2009 1:52:27 am James R. Van Artsdalen wrote: > FreeBSD bigback.housenet.jrv 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r190917: > Sat Apr 11 19:48:25 CDT 2009 > james@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 > > I can't boot a GPT partitioned 5.5 TB disc, where the UFS root partition > is near the end of the disk. If I put another disk in the system and > mount root from the GPT disk the system runs fine. > > The 5.5 TB disk is partitioned: > > bigback# gpart show > => 34 11718748093 ad6 GPT (5.5T) > 34 6 - free - (3.0K) > 40 409600 1 efi (200M) > 409640 11634190128 2 !6a898cc3-1dd2-11b2-99a6-080020736631 > (5.4T) > 11634599768 128 3 freebsd-boot (64K) > 11634599896 4194304 4 freebsd-ufs (2.0G) > 11638794200 33554432 5 freebsd-swap (16G) > 11672348632 4194304 6 freebsd-ufs (2.0G) > 11676542936 33554432 7 freebsd-ufs (16G) > 11710097368 8388608 8 freebsd-ufs (4.0G) > 11718485976 262151 - free - (128M) > > If I try to boot it (disk1 so pressing F5 here) it fails looking like > this (there is no UART available so this is typed from a pic, with typos): > > F1 FreeBSD > F5 Drive 1 > > Default: F1 > > BTX Loader 1.00 BTX version is 1.02 > Consoles: internal video/keyboard > BIOS drive C: is disk0 > BIOS drive D: is disk1 > BIOS 630kb/3136864kB available memory > > FreeBSD/i386 bootstrap loader, Revision 1.1 > (james@bigback.housenet.jrv, Sat Apr 11 08:19:00 CDT 2009 > \ > can't load 'kernel' > > Type '?' for a list of commands, 'help' for more details > OK > > To get this far suggests to me that PMBR and GPTBOOT worked, and that > the problem is elsewhere. Suggestions? Could there be a 32-bit > truncation lurking in a loader somewhere? > > PS. Note that the "lsdev' command causes the loader to crash while > printing out the info on the big disk, right after the EFI line for ad6p1... I would first try to fix the lsdev crash. You can use forever loops and printfs to narrow down the cause of the crash if needed. The biosdisk.c code should be able to handle 64-bit LBAs. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 19:00: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 7FDA2106566B for ; Mon, 13 Apr 2009 19:00:43 +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 3E1F78FC1C for ; Mon, 13 Apr 2009 19:00:42 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 13 Apr 2009 14:50:13 -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.4-GA) with ESMTP id PSA51732; Mon, 13 Apr 2009 14:50:14 -0400 (EDT) Received: from 209-6-22-188.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.22.188]) by smtp01.lnh.mail.rcn.net with ESMTP; 13 Apr 2009 14:50:13 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18915.35172.938891.672609@jerusalem.litteratus.org> Date: Mon, 13 Apr 2009 14:50:12 -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: changes to kernel config file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Apr 2009 19:00:43 -0000 I'm about to update a -CURRENT box, and came across this in src/UPDATING: GEOM_PART has become the default partition slicer for storage devices, replacing GEOM_MBR, GEOM_BSD, GEOM_PC98 and GEOM_GPT slicers. It introduces some changes: 1) In order for the new system to work, what - if anything - do I need to put in the config file? 2) will adding "options GEOM_PART_GPT" cause problems? With respect to the changes in the USB stack: The old system was built in early February, before the new code went in. The config file has: device uhci device ohci device ehci device usb device ukbd device ums Do I need to change anything? (Pointers for explanations are good.) Do I need ugen? Uhid? Respectfully, Robert Huff From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 19:33:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1060) id BFACF106582B; Mon, 13 Apr 2009 19:33:06 +0000 (UTC) Date: Mon, 13 Apr 2009 19:33:06 +0000 From: Craig Rodrigues To: Rick Macklem Message-ID: <20090413193306.GA31219@crodrigues.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] nfsserver module now depends on nfssvc 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: Mon, 13 Apr 2009 19:33:11 -0000 On Mon, Apr 13, 2009 at 09:55:25AM -0400, Rick Macklem wrote: > Oops, sorry. I should have sent this out before the commit... Why didn't you put this information in /usr/src/UPDATING? -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 21:33:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74017106566C for ; Mon, 13 Apr 2009 21:33:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailhub.cs.uoguelph.ca (mailhub.cs.uoguelph.ca [131.104.94.205]) by mx1.freebsd.org (Postfix) with ESMTP id 19FB98FC0A for ; Mon, 13 Apr 2009 21:33:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by mailhub.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n3DLWwQM016868; Mon, 13 Apr 2009 17:32:58 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n3DLdPr03059; Mon, 13 Apr 2009 17:39:25 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 13 Apr 2009 17:39:25 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Craig Rodrigues In-Reply-To: <20090413193306.GA31219@crodrigues.org> Message-ID: References: <20090413193306.GA31219@crodrigues.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.205 Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] nfsserver module now depends on nfssvc 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: Mon, 13 Apr 2009 21:33:03 -0000 On Mon, 13 Apr 2009, Craig Rodrigues wrote: > On Mon, Apr 13, 2009 at 09:55:25AM -0400, Rick Macklem wrote: >> Oops, sorry. I should have sent this out before the commit... > > Why didn't you put this information in /usr/src/UPDATING? > Because I'm a newbie at this commiting stuff and didn't know, rick (I'll go look and see what UPDATING is.) From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 22:37:11 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 71F7C106564A; Mon, 13 Apr 2009 22:37:10 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 13 Apr 2009 18:36:55 -0400 User-Agent: KMail/1.6.2 References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <83e5fb980904081237u4e2979b9tad38d62a061d85b8@mail.gmail.com> <200904131305.12605.jhb@freebsd.org> In-Reply-To: <200904131305.12605.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <200904131836.57686.jkim@FreeBSD.org> Cc: Diego Depaoli Subject: Re: AMD 780G chipset major issues 3/3 (btx) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Apr 2009 22:37:11 -0000 On Monday 13 April 2009 01:05 pm, John Baldwin wrote: > On Wednesday 08 April 2009 3:37:38 pm Diego Depaoli wrote: > > On Tue, Apr 7, 2009 at 4:26 PM, John Baldwin wrote: > > > On Monday 06 April 2009 5:02:53 pm Diego Depaoli wrote: > > >> And finally... > > >> if I enable ahci in bios the system won't boot  with btx > > >> halted. Ctrl+alt+del is the only allowed action. > > >> > > >> Yes... it's a low cost motherboard, but I'm a bit confused. > > > > > > What OS release are you running? > > > > 8.0-CURRENT FreeBSD 8.0-CURRENT #19: Sun Apr 5 02:25:34 CEST > > 2009 FreeBSD version 800074 > > Very odd, can you get a copy of the BTX fault output? As I said earlier, I have a similar board and this is what I got: int=0000000d err=00000000 efl=00030002 eip=000001b1 eax=00000011 ebx=00000002 ecx=00009d82 edx=0009dbc8 esi=000003f0 edi=00000368 ebp=000003a8 esp=00000362 cs=cf00 ds=0040 es=1400 fs=0000 gs=0000 ss=9d82 cs:eip=2e 0f 01 16 7d 00 0f 20-c0 0c 01 0f 22 c0 eb 00 b8 08 00 8e d8 8e c0 8e-d0 66 2e a1 54 00 66 8b ss:esp=3f 00 c0 96 00 00 11 00-00 00 00 14 40 00 02 2f 46 00 02 00 00 00 f0 03-00 00 a8 03 00 00 94 03 The following is the disassembled code: 0: 2e 0f 01 16 lgdtl %cs:(%esi) 4: 7d 00 jge 0x6 6: 0f 20 c0 mov %cr0,%eax 9: 0c 01 or $0x1,%al b: 0f 22 c0 mov %eax,%cr0 e: eb 00 jmp 0x10 10: b8 08 00 8e d8 mov $0xd88e0008,%eax 15: 8e c0 mov %eax,%es 17: 8e d0 mov %eax,%ss 19: 66 2e a1 54 00 66 8b mov %cs:0x8b660054,%ax Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Apr 13 23:16:54 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 1C5D1106564A; Mon, 13 Apr 2009 23:16:53 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 13 Apr 2009 19:16:39 -0400 User-Agent: KMail/1.6.2 References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904131305.12605.jhb@freebsd.org> <200904131836.57686.jkim@FreeBSD.org> In-Reply-To: <200904131836.57686.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <200904131916.41157.jkim@FreeBSD.org> Cc: Diego Depaoli Subject: Re: AMD 780G chipset major issues 3/3 (btx) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Apr 2009 23:16:54 -0000 On Monday 13 April 2009 06:36 pm, Jung-uk Kim wrote: > On Monday 13 April 2009 01:05 pm, John Baldwin wrote: > > On Wednesday 08 April 2009 3:37:38 pm Diego Depaoli wrote: > > > On Tue, Apr 7, 2009 at 4:26 PM, John Baldwin > > wrote: > > > > On Monday 06 April 2009 5:02:53 pm Diego Depaoli wrote: > > > >> And finally... > > > >> if I enable ahci in bios the system won't boot  with btx > > > >> halted. Ctrl+alt+del is the only allowed action. > > > >> > > > >> Yes... it's a low cost motherboard, but I'm a bit confused. > > > > > > > > What OS release are you running? > > > > > > 8.0-CURRENT FreeBSD 8.0-CURRENT #19: Sun Apr 5 02:25:34 CEST > > > 2009 FreeBSD version 800074 > > > > Very odd, can you get a copy of the BTX fault output? > > As I said earlier, I have a similar board and this is what I got: > > int=0000000d err=00000000 efl=00030002 eip=000001b1 > eax=00000011 ebx=00000002 ecx=00009d82 edx=0009dbc8 > esi=000003f0 edi=00000368 ebp=000003a8 esp=00000362 > cs=cf00 ds=0040 es=1400 fs=0000 gs=0000 ss=9d82 > cs:eip=2e 0f 01 16 7d 00 0f 20-c0 0c 01 0f 22 c0 eb 00 > b8 08 00 8e d8 8e c0 8e-d0 66 2e a1 54 00 66 8b > ss:esp=3f 00 c0 96 00 00 11 00-00 00 00 14 40 00 02 2f > 46 00 02 00 00 00 f0 03-00 00 a8 03 00 00 94 03 > > The following is the disassembled code: > > 0: 2e 0f 01 16 lgdtl %cs:(%esi) > 4: 7d 00 jge 0x6 > 6: 0f 20 c0 mov %cr0,%eax > 9: 0c 01 or $0x1,%al > b: 0f 22 c0 mov %eax,%cr0 > e: eb 00 jmp 0x10 > 10: b8 08 00 8e d8 mov $0xd88e0008,%eax > 15: 8e c0 mov %eax,%es > 17: 8e d0 mov %eax,%ss > 19: 66 2e a1 54 00 66 8b mov %cs:0x8b660054,%ax Ouch, the following should be more likely disassembly: 0: 2e 0f 01 16 7d 00 lgdtl %cs:0x7d 6: 0f 20 c0 mov %cr0,%ax 9: 0c 01 or $0x1,%al b: 0f 22 c0 mov %ax,%cr0 e: eb 00 jmp 0x10 10: b8 08 00 mov $0x08,%ax 13: 8e d8 mov %ax,%ds 15: 8e c0 mov %ax,%es 17: 8e d0 mov %ax,%ss 19: 66 2e a1 54 00 mov %cs:0x54,%ax Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 00:03: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 94C81106566B for ; Tue, 14 Apr 2009 00:03:31 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 018838FC19 for ; Tue, 14 Apr 2009 00:03:30 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by ewy19 with SMTP id 19so2221549ewy.43 for ; Mon, 13 Apr 2009 17:03:30 -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=7pnYCfue1mWRwmaJGQzYXAnmWeyso4iREcJXmUaOAAw=; b=EnuBnTGfvSbqIKDSp1ILgmXUo+bWN/rGqs/rgnPKA+KXMMtyNytm19Z2AzIqNW04gf rq0d/16Vo4NUnKAXD8WZ09BCZw8R+qlJ8UNKiKARWYNXEQgprw2rUxgOrsZ9VOfbXU0Y tNSVmVc6f7VDtKDileG4zA8yEt8EkdgoR3118= 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=CTR6eVPnUqan2jKA07UOpXA/1zUCJnABZi/9CkuPeHOS3Dx+UCwYS0lb749kjadBvJ IgGamkwFxQDT+jUOwQ2UHZjWr7U5//1rR3XO9Zcr7dk/Sb3yUDNgbxXxJyq+71CrH5Yw vTdhGf8/f4FhHQ4nIdqHpfNvmsceo0XVb0v1A= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.211.168.5 with SMTP id v5mr5702693ebo.74.1239665782654; Mon, 13 Apr 2009 16:36:22 -0700 (PDT) In-Reply-To: References: <49C2CFF6.8070608@egr.msu.edu> Date: Mon, 13 Apr 2009 16:36:22 -0700 X-Google-Sender-Auth: e64b87325edab5ae Message-ID: From: Artem Belevich To: Ben Kelly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 00:03:31 -0000 Tried your patch that used PRIBIO+{1,2} for priorities with -current r191008 and the kernel died with "spinlock held too long" panic. Actually, there apparently were two instances of panic on different cores.. Here's output of "alltrace" and "ps" after the crash: http://pastebin.com/f140f4596 I've reverted the change and kernel booted just fine. The box is quad-core with two ZFS pools -- one single-disk and another one is a two-disk mirror. Freebsd is installed on UFS partitions, ZFS is used for user stuff only. --Artem On Thu, Mar 19, 2009 at 5:19 PM, Ben Kelly wrote: > On Mar 19, 2009, at 7:06 PM, Adam McDougall wrote: >> >> I was really impressed with your diagnosis but didn't try your patch unt= il >> this afternoon. =A0I had not seen processes spin, but I have had zfs get= stuck >> roughly every 2 days on a somewhat busy ftp/rsync server until I turned = off >> zil again, then it was up for over 13 days when I decided to try this pa= tch. >> =A0This system boots from a ufs / and turns around to try mounting a zfs= root >> over top, but the first time it stalled for a few minutes at the root mo= unt >> and "gave up" with a spinlock held too long, second time same thing but = I >> didn't wait long enough for the spinlock error. Then I tried a power cyc= le >> just because, and the next two tries I got a page fault kernel panic. = =A0I'd >> try to give more details but right now im trying to get the server back = up >> with a livecd because I goofed and don't have an old kernel to fall back= on. >> =A0Just wanted to let you know, and thanks for getting as far as you did= ! > > Ouch! =A0Sorry you ran into that. > > I haven't seen these problems, but I keep my root partition on UFS and on= ly > use zfs for /usr, /var, etc. =A0Perhaps that explains the difference in > behavior. > > You could try changing the patch to use lower priorities. =A0To do this c= hange > compat/opensolaris/sys/proc.h so that it reads: > > =A0#define =A0 =A0 =A0 =A0minclsyspri =A0 =A0 PRI_MAX_REALTIME > =A0#define =A0 =A0 =A0 =A0maxclsyspri =A0 =A0(PRI_MAX_REALTIME - 4) > > This compiles and runs on my machine. =A0The theory here is that other ke= rnel > threads will be able to run as they used to, but the zfs threads will sti= ll > be fixed relative to one another. =A0Its really just a stab in the dark, > though. =A0I don't have any experience with the "zfs mounted on top of uf= s > root" configuration. =A0If this works we should try to see if we can repl= ace > PRI_MAX_REALTIME with PRI_MAX_KERN so that the zfs kernel threads run in = the > kernel priority range. > > If you could get a stack trace of the kernel panic that would be helpful. > =A0Also, if you have console access, can you break to debugger during the= boot > spinlock hang and get a backtrace of the blocked process? > > If you want to compare other aspects of your environment to mine I upload= ed > a bunch of info here: > > =A0http://www.wanderview.com/svn/public/misc/zfs_livelock > > Finally, I'm CC'ing the list and some other people so they are aware that > the patch runs the risk of a panic. > > I hope that helps. > > - Ben > _______________________________________________ > 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 Apr 14 02:05: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 8D8981065670 for ; Tue, 14 Apr 2009 02:05:49 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 5D92E8FC08 for ; Tue, 14 Apr 2009 02:05:49 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id DF68031B7E6; Mon, 13 Apr 2009 22:05:48 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 13 Apr 2009 22:05:48 -0400 X-Sasl-enc: DxfJ5TC+7R2Hh6Z2pXvxSIFDt5LX+WmBtEmE+YEeShFt 1239674748 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 2D3EA29EDD; Mon, 13 Apr 2009 22:05:48 -0400 (EDT) Message-ID: <49E3EF7A.1020107@incunabulum.net> Date: Tue, 14 Apr 2009 03:05:46 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: eculp References: <20090413054500.1241102uwgs74khc@econet.encontacto.net> In-Reply-To: <20090413054500.1241102uwgs74khc@econet.encontacto.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-emulation , current Subject: Re: Flash10, with up to date current, not even recoginized with about:plugins. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 02:05:49 -0000 eculp wrote: > > PS I did notice a userid (0) unknown with a couple of the linux-f8 > portw while installing them with portmaster and they installed fine. > IIRC gtk2 was one and scim was the other. JFYI: I found I had to use f9 for Flash 9 to run on 7.2-PRERELEASE. It still isn't 100% happy, in particular, plugin wrapper leaves processes lying around, and subsequent invocations can have problems doing anything at all; e.g. the first invocation running a YouTube video will work, but after that, it hangs. Firefox continues to run, but Flash does not work. From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 05:08: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 18606106566C for ; Tue, 14 Apr 2009 05:08:01 +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 CCAB38FC0C for ; Tue, 14 Apr 2009 05:08:00 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [195.93.241.27] (port=9642 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtasI-0005PF-No for freebsd-current@freebsd.org; Tue, 14 Apr 2009 09:07:58 +0400 Message-ID: <49E41A2F.9080105@lissyara.su> Date: Tue, 14 Apr 2009 09:07:59 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.21) Gecko/20090406 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: freebsd-current@freebsd.org 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: NMI ISA 2c, EISA ff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 05:08:01 -0000 I try install FreBSD; boot from USB hard drive on HP 2133 (laptop) Boot not success: agp0: on host0 agp0: aperture size is 128M NMI ISA 2c, EISA ff NMI ... going to debugger [thread pid0 tid 100000 ] Stopped at pmap_remove+0x158: testl %eax,%eax db> If I do not unplug hard drive - reboot with 2-3 seconds If unplug - not reboot, but, 'db>' go to down - kind of press enter (~10-20 seconds period) System - i386, GENERIC, from yesterday sources From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 06:17: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 CF5DE1065670 for ; Tue, 14 Apr 2009 06:17:49 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 962068FC12 for ; Tue, 14 Apr 2009 06:17:49 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id n3E6IXHp038522 for ; Tue, 14 Apr 2009 02:18:33 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: current Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-36vNX9ydDqAEkfhsNEe0" Organization: FreeBSD, Inc. Date: Tue, 14 Apr 2009 02:17:48 -0400 Message-Id: <1239689868.1304.209.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE, NO_RELAYS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: Subject: Panic in vfs_cache on i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 06:17:50 -0000 --=-36vNX9ydDqAEkfhsNEe0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm seeing this panic on my -CURRENT i386 Tinderbox machine (using looped back NFS). The backtrace does not point to a line number in vfs_cache.c, and I can't figure out how atomic_cmpset_int is being called, so I'm confused as to exactly what is causing this. Any clues? FreeBSD fugu.marcuscom.com 8.0-CURRENT FreeBSD 8.0-CURRENT #20: Mon Apr 13 = 17:21:39 EDT 2009 gnome@fugu.marcuscom.com:/space/obj/usr/src/sys/FUGU = i386 Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address =3D 0x84 fault code =3D supervisor write, page not present instruction pointer =3D 0x20:0x80670cf0 stack pointer =3D 0x28:0xb9d59974 frame pointer =3D 0x28:0xb9d599a0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 82240 (sh) panic: from debugger cpuid =3D 1 #0 doadump () at pcpu.h:246 #1 0x804958c9 in db_fncall (dummy1=3D1, dummy2=3D0, dummy3=3D-2137255936, = dummy4=3D0xb9d59708 "\200=EF=BF=BD=EF=BF=BD\204") at /usr/src/sys/ddb/db_co= mmand.c:548 #2 0x80495cc1 in db_command (last_cmdp=3D0x8094251c, cmd_table=3D0x0, dopa= ger=3D1) at /usr/src/sys/ddb/db_command.c:445 #3 0x80495e1a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0x80497c5d in db_trap (type=3D12, code=3D0) at /usr/src/sys/ddb/db_main= .c:229 #5 0x80629ef6 in kdb_trap (type=3D12, code=3D0, tf=3D0xb9d59934) at /usr/s= rc/sys/kern/subr_kdb.c:534 #6 0x808666ef in trap_fatal (frame=3D0xb9d59934, eva=3D132) at /usr/src/sy= s/i386/i386/trap.c:917 #7 0x80866990 in trap_pfault (frame=3D0xb9d59934, usermode=3D0, eva=3D132)= at /usr/src/sys/i386/i386/trap.c:839 #8 0x80867362 in trap (frame=3D0xb9d59934) at /usr/src/sys/i386/i386/trap.= c:521 #9 0x8084b93b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #10 0x80670cf0 in cache_lookup (dvp=3D0x8a55a10c, vpp=3D0xb9d59b78, cnp=3D0= xb9d59b8c) at atomic.h:153 #11 0x80670f93 in vfs_cache_lookup (ap=3D0xb9d59a40) at /usr/src/sys/kern/v= fs_cache.c:869 #12 0x808736e6 in VOP_LOOKUP_APV (vop=3D0x8092a680, a=3D0xb9d59a40) at vnod= e_if.c:123 #13 0x80678351 in lookup (ndp=3D0xb9d59b60) at vnode_if.h:54 #14 0x806792ab in namei (ndp=3D0xb9d59b60) at /usr/src/sys/kern/vfs_lookup.= c:256 #15 0x8068893b in kern_statat_vnhook (td=3D0x86085000, flag=3D0, fd=3D-100,= path=3D0x33f02400
, pathseg=3DUIO_USERSP= ACE, sbp=3D0xb9d59c18, hook=3D0) at /usr/src/sys/kern/vfs_syscalls.c:2356 #16 0x80688aac in kern_statat (td=3D0x86085000, flag=3D0, fd=3D-100, path= =3D0x33f02400
, pathseg=3DUIO_USERSPACE, = sbp=3D0xb9d59c18) at /usr/src/sys/kern/vfs_syscalls.c:2337 #17 0x80688bf6 in kern_stat (td=3D0x86085000, path=3D0x33f02400
, pathseg=3DUIO_USERSPACE, sbp=3D0xb9d59c18) at /usr= /src/sys/kern/vfs_syscalls.c:2329 #18 0x80688c9f in stat (td=3D0x86085000, uap=3D0xb9d59cf8) at /usr/src/sys/= kern/vfs_syscalls.c:2298 #19 0x80866cd5 in syscall (frame=3D0xb9d59d38) at /usr/src/sys/i386/i386/tr= ap.c:1066 #20 0x8084b9a0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s= :261 #21 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) print *dvp $6 =3D {v_type =3D VDIR, v_tag =3D 0x808c518a "ufs", v_op =3D 0x8092a160,=20 v_data =3D 0x8a1f707c, v_mount =3D 0x8531b500, v_nmntvnodes =3D { tqe_next =3D 0x8a554754, tqe_prev =3D 0x8a55a65c}, v_un =3D {vu_mount = =3D 0x0,=20 vu_socket =3D 0x0, vu_cdev =3D 0x0, vu_fifoinfo =3D 0x0, vu_yield =3D 0= },=20 v_hashlist =3D {le_next =3D 0x8600d324, le_prev =3D 0x8503b170},=20 v_hash =3D 10739825, v_cache_src =3D {lh_first =3D 0x0}, v_cache_dst =3D = { tqh_first =3D 0x0, tqh_last =3D 0x8a55a13c}, v_cache_dd =3D 0x86770120,= =20 v_cstart =3D 0, v_lasta =3D 0, v_lastw =3D 0, v_clen =3D 0, v_lock =3D {l= ock_object =3D { lo_name =3D 0x808c518a "ufs", lo_flags =3D 91947009, lo_data =3D 0,=20 lo_witness =3D 0x0}, lk_lock =3D 1, lk_timo =3D 51, lk_pri =3D 80},=20 v_interlock =3D {lock_object =3D {lo_name =3D 0x808d15c1 "vnode interlock= ",=20 lo_flags =3D 16973824, lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock = =3D 4},=20 v_vnlock =3D 0x8a55a164, v_holdcnt =3D 3, v_usecount =3D 3, v_iflag =3D 0= ,=20 v_vflag =3D 0, v_writecount =3D 0, v_freelist =3D {tqe_next =3D 0x0,=20 tqe_prev =3D 0x0}, v_bufobj =3D {bo_mtx =3D {lock_object =3D { lo_name =3D 0x808d15d1 "bufobj interlock", lo_flags =3D 16973824,=20 lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 4}, bo_clean =3D {= bv_hd =3D { tqh_first =3D 0x0, tqh_last =3D 0x8a55a1c8}, bv_root =3D 0x0, bv_cn= t =3D 0},=20 bo_dirty =3D {bv_hd =3D {tqh_first =3D 0x0, tqh_last =3D 0x8a55a1d8},=20 bv_root =3D 0x0, bv_cnt =3D 0}, bo_numoutput =3D 0, bo_flag =3D 0,=20 bo_ops =3D 0x8091ab80, bo_bsize =3D 16384, bo_object =3D 0x8a6c245c,=20 bo_synclist =3D {le_next =3D 0x0, le_prev =3D 0x0}, bo_private =3D 0x8a= 55a10c,=20 __bo_vnode =3D 0x8a55a10c}, v_pollinfo =3D 0x0, v_label =3D 0x0, v_lock= f =3D 0x0} print *vpp $7 =3D (struct vnode *) 0x0 print *cnp $9 =3D {cn_nameiop =3D 0, cn_flags =3D 83943748, cn_thread =3D 0x86085000,=20 cn_cred =3D 0x85ad4d00, cn_lkflags =3D 2097152, cn_pnbuf =3D 0x8acf6400 "= ..",=20 cn_nameptr =3D 0x8acf6400 "..", cn_namelen =3D 2, cn_consume =3D 0} Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-36vNX9ydDqAEkfhsNEe0 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) iEYEABECAAYFAknkKosACgkQb2iPiv4Uz4dDDACfeH9fIxGOlLGE5bUUel7Tu9kb 358AoK/9/9jEzKCrkFeYfJgiliS1XSkE =5hLk -----END PGP SIGNATURE----- --=-36vNX9ydDqAEkfhsNEe0-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 10:16: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 1EDD31065670 for ; Tue, 14 Apr 2009 10:16:48 +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 6A36A8FC1A for ; Tue, 14 Apr 2009 10:16:47 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 21178 invoked from network); 14 Apr 2009 10:16:46 -0000 Received: from unknown (HELO ale.andxor.it) (192.168.2.5) by andxor.it with SMTP; 14 Apr 2009 10:16:46 -0000 Message-ID: <49E4628D.7060208@FreeBSD.org> Date: Tue, 14 Apr 2009 12:16:45 +0200 From: Alex Dupre User-Agent: Thunderbird 2.0.0.21 (X11/20090408) MIME-Version: 1.0 To: Tim Kientzle References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> <49DC5066.1010607@FreeBSD.org> <1239176118.1954.11.camel@balrog.2hip.net> <49DF49AD.30701@FreeBSD.org> <49DFBAEF.1080904@freebsd.org> In-Reply-To: <49DFBAEF.1080904@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Robert Noland Subject: Re: xorg loops X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 10:16:49 -0000 Tim Kientzle ha scritto: >> Nope :-( I have the same symptoms without using kdm and without >> launching it from /etc/ttys. Actually the mouse doesn't work even if I >> kill moused. The only way to make it working is setting >> AllowEmptyInput to off, nothing else works. > > Are you running hald? Of course (even if I don't use it for anything): %ps ax | grep hal 1031 ?? Ss 0:00,44 /usr/local/sbin/hald 1035 ?? I 0:00,05 hald-runner 1039 ?? S 0:00,08 hald-addon-storage: no polling on /dev/fd0 because it is explicitly disabled (hald-addon-storage) 1041 ?? S 0:00,11 hald-addon-storage: /dev/cd0 (hald-addon-storage) 1418 p0 S+ 0:00,00 grep hal %ps ax | grep dbus 917 ?? Is 0:00,01 /usr/local/bin/dbus-daemon --system 1420 p0 RL+ 0:00,00 grep dbus > On my system: > > AllowEmptyInput hald Result > off enabled Mouse/keyboard delays/jerkiness > off disabled Works > on (default) enabled Works > on (default) disabled No mouse/keyboard On my system: AllowEmptyInput hald Result off enabled Works off disabled Works on (default) enabled No mouse on (default) disabled No mouse As said, KDM or simple X session doesn't care, /etc/ttys or command line doesn't care. I still haven't received an answer on the following doubt: is it normal that lshal / hal-device doesn't show any mouse? -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 10:58: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 52142106566B for ; Tue, 14 Apr 2009 10:58:52 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0758FC08 for ; Tue, 14 Apr 2009 10:58:49 +0000 (UTC) (envelope-from avg@icyb.net.ua) 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 NAA09386; Tue, 14 Apr 2009 13:58:31 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <49E46C57.7030306@icyb.net.ua> Date: Tue, 14 Apr 2009 13:58:31 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Alex Keda References: <49E41A2F.9080105@lissyara.su> In-Reply-To: <49E41A2F.9080105@lissyara.su> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: NMI ISA 2c, EISA ff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 10:58:52 -0000 on 14/04/2009 08:07 Alex Keda said the following: > I try install FreBSD; boot from USB hard drive on HP 2133 (laptop) > Boot not success: > > agp0: on host0 > agp0: aperture size is 128M > NMI ISA 2c, EISA ff I am not an expert here, but I had the above message on flaky hardware. But, again, the same symptoms do not mean the same cause. > NMI ... going to debugger > [thread pid0 tid 100000 ] > Stopped at pmap_remove+0x158: testl %eax,%eax > db> > > If I do not unplug hard drive - reboot with 2-3 seconds > If unplug - not reboot, but, 'db>' go to down - kind of press enter > (~10-20 seconds period) > System - i386, GENERIC, from yesterday sources -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 15:50: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 13EA31065670 for ; Tue, 14 Apr 2009 15:50:29 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id A7B688FC1E for ; Tue, 14 Apr 2009 15:50:28 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n3EFoIsN002477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Apr 2009 15:50:19 GMT (envelope-from ben@wanderview.com) Message-Id: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> From: Ben Kelly To: Artem Belevich 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 v930.3) Date: Tue, 14 Apr 2009 11:50:18 -0400 References: <49C2CFF6.8070608@egr.msu.edu> X-Mailer: Apple Mail (2.930.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: freebsd-current@freebsd.org Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 15:50:29 -0000 On Apr 13, 2009, at 7:36 PM, Artem Belevich wrote: > Tried your patch that used PRIBIO+{1,2} for priorities with -current > r191008 and the kernel died with "spinlock held too long" panic. > Actually, there apparently were two instances of panic on different > cores.. > > Here's output of "alltrace" and "ps" after the crash: > http://pastebin.com/f140f4596 > > I've reverted the change and kernel booted just fine. > > The box is quad-core with two ZFS pools -- one single-disk and another > one is a two-disk mirror. Freebsd is installed on UFS partitions, ZFS > is used for user stuff only. Thanks for the report! I don't have a lot of time to look at this today, but it appears that there is a race condition on SMP machines when setting the priority immediately after the kproc is spawned. As a quick hack I tried adding a pause between the kproc_create() and the sched_prio(). Can you try this patch? http://www.wanderview.com/svn/public/misc/zfs_livelock/zfs_thread_priority.diff I'll try to take a closer look at this later in the week. Thanks! - Ben From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 16: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 4123A106564A; Tue, 14 Apr 2009 16:00:29 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [80.67.29.8]) by mx1.freebsd.org (Postfix) with ESMTP id BF58F8FC18; Tue, 14 Apr 2009 16:00:28 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [62.143.131.114] (helo=localhost) by smtprelay08.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Ltl3j-0005SW-5n; Tue, 14 Apr 2009 18:00:27 +0200 Date: Tue, 14 Apr 2009 18:00:20 +0200 From: Fabian Keil To: Maksim Yevmenkin Message-ID: <20090414180020.34b97378@fabiankeil.de> In-Reply-To: References: <200904082052.n38KqU9p075633@svn.freebsd.org> <20090412170335.5a8a3169@fabiankeil.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/pL.vY=1MxGzk3ySTJajbGIj"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Df-Sender: 775067 Cc: freebsd-current@freebsd.org Subject: Re: svn commit: r190857 - head/sys/dev/kbdmux X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 16:00:29 -0000 --Sig_/pL.vY=1MxGzk3ySTJajbGIj Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Maksim Yevmenkin wrote: > On Sun, Apr 12, 2009 at 8:03 AM, Fabian Keil > wrote: > > Maksim Yevmenkin wrote: > > > >> Author: emax > >> Date: Wed Apr =A08 20:52:30 2009 > >> New Revision: 190857 > >> URL: http://svn.freebsd.org/changeset/base/190857 > >> > >> Log: > >> =A0 Undo SVN rev 183283 > >> > >> =A0 Do not use Giant for kbdmux(4) locking. This is wrong and apparent= ly > >> =A0 causing more problems than it solves. This will re-open the issue > >> =A0 where interrupt handlers may race with kbdmux(4) in polling mode. > >> =A0 Typical symptoms include (but not limited to) duplicated and/or > >> =A0 missing characters when low level console functions (such as gets) > >> =A0 are used while interrupts are enabled (for example geli password > >> =A0 prompt, mountroot prompt etc.) > >> > >> =A0 MFC after: =A03 days > >> > >> Modified: > >> =A0 head/sys/dev/kbdmux/kbdmux.c [...] > > Not even enabling the "visible characters" option helps > > because obviously backspace is broken too. >=20 > if you do not need kbdmix(4) you might just want to disable it on your > system. i think it should help with your particular problem. Removing kbdmux from the kernel does indeed work around the problem. > > Before theses locks were introduces I worked around the problem > > with this gets() hack (which forced me to reduce the key entropy): > > http://www.fabiankeil.de/sourcecode/freebsd/gets-no-duplicates.diff > > and now I will simply revert your commit locally, but I assume I'm > > not the only geli user who prefers to be able to boot the system > > without local patches. >=20 > if your primary keyboard is atkbd(4), you might want to try the > following patch. it is completely untested (i did not even compile > it), so be warned ... >=20 > Index: atkbd.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 > --- atkbd.c (revision 190905) > +++ atkbd.c (working copy) > @@ -476,7 +476,7 @@ > static int > atkbd_intr(keyboard_t *kbd, void *arg) > { > - atkbd_state_t *state; > + atkbd_state_t *state =3D (atkbd_state_t *)kbd->kb_data; > int delay[2]; > int c; >=20 > @@ -485,7 +485,6 @@ > * The keyboard was not detected before; > * it must have been reconnected! > */ > - state =3D (atkbd_state_t *)kbd->kb_data; > init_keyboard(state->kbdc, &kbd->kb_type, > kbd->kb_config); > KBD_FOUND_DEVICE(kbd); > @@ -497,6 +496,9 @@ > } >=20 > if (KBD_IS_ACTIVE(kbd) && KBD_IS_BUSY(kbd)) { > + if (state->ks_polling) > + return 0; > + > /* let the callback function to process the input */ > (*kbd->kb_callback.kc_func)(kbd, KBDIO_KEYINPUT, > kbd->kb_callback.kc_arg); >=20 It compiles alright but once the system is running the keyboard no longer works at all. I tested the patch with kbdmux already disabled, but I assume it doesn't make a difference. Anyway, I don't need kbdmux, so having to remove it is no problem. Thanks a lot. Fabian --Sig_/pL.vY=1MxGzk3ySTJajbGIj Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknksxoACgkQBYqIVf93VJ30rQCgxRiQdlHRmD/kzVSgNkua7Y8a 9OMAoIesdVWcFymsf+1L+wyHOXyBerhE =7Uvq -----END PGP SIGNATURE----- --Sig_/pL.vY=1MxGzk3ySTJajbGIj-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 16: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 E09121065AC8; Tue, 14 Apr 2009 16:13:04 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 86CFC8FC26; Tue, 14 Apr 2009 16:13:04 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id n3EGDlwp044637; Tue, 14 Apr 2009 12:13:47 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Alex Dupre In-Reply-To: <49E4628D.7060208@FreeBSD.org> References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> <49DC5066.1010607@FreeBSD.org> <1239176118.1954.11.camel@balrog.2hip.net> <49DF49AD.30701@FreeBSD.org> <49DFBAEF.1080904@freebsd.org> <49E4628D.7060208@FreeBSD.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-S/rFlq02h0b86s80/pNx" Organization: MarcusCom, Inc. Date: Tue, 14 Apr 2009 12:13:03 -0400 Message-Id: <1239725583.1304.213.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE, NO_RELAYS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: Tim Kientzle , Robert Noland , freebsd-current@freebsd.org Subject: Re: xorg loops X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 16:13:07 -0000 --=-S/rFlq02h0b86s80/pNx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-04-14 at 12:16 +0200, Alex Dupre wrote: > Tim Kientzle ha scritto: > >> Nope :-( I have the same symptoms without using kdm and without=20 > >> launching it from /etc/ttys. Actually the mouse doesn't work even if I= =20 > >> kill moused. The only way to make it working is setting=20 > >> AllowEmptyInput to off, nothing else works. > >=20 > > Are you running hald? >=20 > Of course (even if I don't use it for anything): >=20 > %ps ax | grep hal > 1031 ?? Ss 0:00,44 /usr/local/sbin/hald > 1035 ?? I 0:00,05 hald-runner > 1039 ?? S 0:00,08 hald-addon-storage: no polling on /dev/fd0=20 > because it is explicitly disabled (hald-addon-storage) > 1041 ?? S 0:00,11 hald-addon-storage: /dev/cd0 (hald-addon-stora= ge) > 1418 p0 S+ 0:00,00 grep hal > %ps ax | grep dbus > 917 ?? Is 0:00,01 /usr/local/bin/dbus-daemon --system > 1420 p0 RL+ 0:00,00 grep dbus >=20 > > On my system: > >=20 > > AllowEmptyInput hald Result > > off enabled Mouse/keyboard delays/jerkiness > > off disabled Works > > on (default) enabled Works > > on (default) disabled No mouse/keyboard >=20 > On my system: >=20 > AllowEmptyInput hald Result > off enabled Works > off disabled Works > on (default) enabled No mouse > on (default) disabled No mouse >=20 > As said, KDM or simple X session doesn't care, /etc/ttys or command line=20 > doesn't care. >=20 > I still haven't received an answer on the following doubt: is it normal=20 > that lshal / hal-device doesn't show any mouse? No, this is not normal. Hal should always show a mouse, for example: udi =3D '/org/freedesktop/Hal/devices/psm_0' freebsd.device_file =3D '/dev/psm0' (string) freebsd.driver =3D 'psm' (string) freebsd.unit =3D 0 (0x0) (int) info.addons =3D {'hald-addon-mouse-sysmouse'} (string list) info.capabilities =3D {'input', 'input.mouse'} (string list) info.category =3D 'input.mouse' (string) info.parent =3D '/org/freedesktop/Hal/devices/atkbdc_0' (string) info.product =3D 'PS/2 Mouse' (string) info.subsystem =3D 'platform' (string) info.udi =3D '/org/freedesktop/Hal/devices/psm_0' (string) input.device =3D '/dev/sysmouse' (string) input.x11_driver =3D 'mouse' (string) platform.id =3D 'psm.0' (string) Joe >=20 --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-S/rFlq02h0b86s80/pNx 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) iEYEABECAAYFAknktg0ACgkQb2iPiv4Uz4fZhwCfWSR88uAX9jTla63DsLpAuKYL vJAAn0+O+kiMdmNo5a7RPbCOv+fs8I5B =sLJp -----END PGP SIGNATURE----- --=-S/rFlq02h0b86s80/pNx-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 17:18:38 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C1501065680; Tue, 14 Apr 2009 17:18:38 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from ns2.bafirst.com (72-12-2-19.static.networktel.net [72.12.2.19]) by mx1.freebsd.org (Postfix) with ESMTP id 02B478FC15; Tue, 14 Apr 2009 17:18:37 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from HOME.encontacto.net ([189.190.9.26]) by ns2.bafirst.com with esmtp; Tue, 14 Apr 2009 12:18:35 -0500 id 000D50BB.49E4C56B.00007C8F Received: from localhost (localhost [127.0.0.1]) (uid 80) by HOME.encontacto.net with local; Tue, 14 Apr 2009 12:18:34 -0500 id 0004AC15.49E4C56A.00011DFA Received: from 172.16.0.42 (172.16.0.42 [172.16.0.42]) by econet.encontacto.net (Horde Framework) with HTTP; Tue, 14 Apr 2009 12:18:34 -0500 Message-ID: <20090414121834.16493y1mb7iqhegw@econet.encontacto.net> Date: Tue, 14 Apr 2009 12:18:34 -0500 From: eculp To: Bruce Simpson References: <20090413054500.1241102uwgs74khc@econet.encontacto.net> <49E3EF7A.1020107@incunabulum.net> In-Reply-To: <49E3EF7A.1020107@incunabulum.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (5.0-cvs) X-Remote-Browser: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.0.8) Gecko/2009040106 Firefox/3.0.4, Ant.com Toolbar 1.3 X-IMP-Server: 189.190.9.26 X-Originating-IP: 201.155.7.3 X-Originating-User: eculp@encontacto.net Cc: freebsd-emulation , current Subject: Re: Flash10, with up to date current, not even recoginized with about:plugins. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 17:18:39 -0000 Quoting Bruce Simpson : > eculp wrote: >> >> PS I did notice a userid (0) unknown with a couple of the linux-f8 >> portw while installing them with portmaster and they installed >> fine. IIRC gtk2 was one and scim was the other. > > JFYI: > I found I had to use f9 for Flash 9 to run on 7.2-PRERELEASE. Hi Bruce, Would this be Flash 10 you are refering to? Flash 9 was working fine for me before updating to the *-f8-* ports and moving to flash 10. I am going to give f9 a try with falsh10 and see if I can at least get it recoginized and maybe work as you have. Thanks, ed > > It still isn't 100% happy, in particular, plugin wrapper leaves > processes lying around, and subsequent invocations can have problems > doing anything at all; e.g. the first invocation running a YouTube > video will work, but after that, it hangs. Firefox continues to run, > but Flash does not work. > From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 17:20:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FEA4106566C; Tue, 14 Apr 2009 17:20:57 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id BA2AC8FC17; Tue, 14 Apr 2009 17:20:56 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id D77F79CB054; Tue, 14 Apr 2009 19:00:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHqz3I0LsggD; Tue, 14 Apr 2009 19:00:43 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 295CA9CB10F; Tue, 14 Apr 2009 19:00:43 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n3EH0hQb052539; Tue, 14 Apr 2009 19:00:43 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 14 Apr 2009 19:00:43 +0200 From: Roman Divacky To: current@freebsd.org Message-ID: <20090414170043.GA51803@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: attilio@freebsd.org Subject: IO related interactivity regression in recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 17:20:57 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi in recent weeks I am observing sudden drop of interactivity which is related to IO. thats is - when one process does IO and another tries to issue some IO as well the second one is terribly starved. nice testcase is: long running compilation in 1 window pkg_version -vl "<" in another window the pkg_version takes A LONG time to finish example: (on idle system) witten ~# time pkg_version -vl "<" .... 21.336u 13.078s 0:32.88 104.6% 320+582k 0+0io 0pf+0w (on gmake -j2 compilation of llvm) witten ~# time pkg_version -vl "<" .... 23.275u 10.937s 3:20.62 17.0% 288+506k 186+0io 121pf+0w ie. it takes 7times takes that long to finish. can someone shed some light on this? confirm this? thnx roman --DocE+STaALJfprDB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknkwToACgkQLVEj6D3CBEyEPgCdFH/bfioLwxcxdm1Gr0bRKEqC xWAAnRShdi/avWl2QsPU5du0C2x78XVf =w36G -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 17:59: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 B4A3C106566C for ; Tue, 14 Apr 2009 17:59:02 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 6ACBC8FC12 for ; Tue, 14 Apr 2009 17:59:01 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n3EHwlaX093544 for ; Tue, 14 Apr 2009 12:58:47 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=R42nzeUb0T6k5t3LL3gSWEifBFbwRl7+musBEH2htQbM9NamayYC05v4I4IPM3yEq 89mt8iwTPwKQdBjtokvz38xkAYSSIW8jb/4lABp8b2mJBrGoNe/smAtRL7U/Kt2YDWp d4kS5bZ7FlwDoFBS+Zup+UBCDenqnQGjUuJr1ak= Message-ID: <49E4CED7.2040206@jrv.org> Date: Tue, 14 Apr 2009 12:58:47 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: ata FLUSHCACHE timeout errors? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 17:59:03 -0000 FreeBSD bigback.housenet.jrv 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r190917: Sat Apr 11 19:48:25 CDT 2009 james@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 I am getting many FLUSHCACHE timeout errors during "zfs recv" operations. kernel: ata3: reiniting channel .. kernel: ata3: channel HW reset time=0ms kernel: ata3: SATA connect time=0ms status=00000113 kernel: ata3: siiprb_issue_cmd time=504ms status=00050000 kernel: ata3: SIGNATURE=00000101 kernel: ata3: siiprb_reset devices=00000001 kernel: ata3: reinit done .. kernel: ad6: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) The "disk" is a SATA hardware RAID with 256 MB of write-back cache. Looking at the ATA code is appears that the timeout for a FLUSHCACHE operation is five seconds (unless the disk is known to be spun down). Five seconds seems much too short in any case - I think the ATA spec allows the device to take 30 seconds. Has anyone seen this or looked into ATA timeouts? From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 13:49: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 356FC106566C; Tue, 14 Apr 2009 13:49:43 +0000 (UTC) (envelope-from matti.k@bigpond.net.au) Received: from nschwqsrv01p.mx.bigpond.com (nschwqsrv01p.mx.bigpond.com [61.9.189.231]) by mx1.freebsd.org (Postfix) with ESMTP id 897448FC1C; Tue, 14 Apr 2009 13:49:41 +0000 (UTC) (envelope-from matti.k@bigpond.net.au) Received: from nschwotgx03p.mx.bigpond.com ([121.210.38.110]) by nschwmtas01p.mx.bigpond.com with ESMTP id <20090414093640.KFA5250.nschwmtas01p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com>; Tue, 14 Apr 2009 09:36:40 +0000 Received: from platypus.freebsd.home ([121.210.38.110]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20090414093639.CVHP13025.nschwotgx03p.mx.bigpond.com@platypus.freebsd.home>; Tue, 14 Apr 2009 09:36:39 +0000 Date: Tue, 14 Apr 2009 20:33:01 +1000 From: matti k To: eculp Message-ID: <20090414203301.57209d43@platypus.freebsd.home> In-Reply-To: <20090413054500.1241102uwgs74khc@econet.encontacto.net> References: <20090413054500.1241102uwgs74khc@econet.encontacto.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.49E45927.00FD,ss=1,fgs=0 X-SIH-MSG-ID: ohExFcT+XAr1xW57im/mMg1zlwbnpWEq454MWdJktxkQUkfCudG6Bp+zAuMD0Y/ixD5FPBmDNGUgc67kXYbr X-Mailman-Approved-At: Tue, 14 Apr 2009 19:11:14 +0000 Cc: freebsd-emulation , current Subject: Re: Flash10, with up to date current, not even recoginized with about:plugins. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 13:49:44 -0000 On Mon, 13 Apr 2009 05:45:00 -0500 eculp wrote: > I'm using up to date current > # uname -a > FreeBSD ed.local.net.mx 8.0-CURRENT FreeBSD 8.0-CURRENT #203: Sun > Apr 12 15:13:50 CDT 2009 > > Auto-install plugins from /root/.mozilla/plugins Looking for plugins > in /root/.mozilla/plugins Install > plugin /root/.mozilla/plugins/nppdf.so > into /root/.mozilla/plugins/npwrapper.nppdf.so > Try running nspluginwrapper as normal user. Cheers, Matti From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 18:44: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 0A6C0106564A; Tue, 14 Apr 2009 18:44:59 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id C78E88FC08; Tue, 14 Apr 2009 18:44:58 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so2379601wfg.7 for ; Tue, 14 Apr 2009 11:44:58 -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=A731POsLGFyJDL6ZjauIqrvGeYUNbNF+pUbUHDNQACk=; b=M6HFri1ZxDx9v2j9w7ZLF+emCf/V6yRMffxMiT76EVl1DO67s1cJEjobB2wHoK9P/h gRsOT9tDlxO7geF9F2QRCA7Twi9Z0/CLl90A5umFKENaqqo/jXrKsxilzXgFNu4BsojM rbTzIDxxLA7jLMHRzZzfJfP9hSD5jO+s4pfeQ= 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=joTk0ts+z5goGd9+THEYl9CAf3/SiwddCqefbKg6lbV96ykV0zCSJciWKcPhfelL5q +cIZ+DYNudQCy714OhxwjmYDslsSpJbUfYpVzx13Bv6tEB2t9Lu9A3McJ7n6xeuXTU1u JQU20kzPtFcZIKA0OW1gqaTzA8eLTW7YDeLFI= MIME-Version: 1.0 Sender: bahamasfranks@gmail.com Received: by 10.142.234.16 with SMTP id g16mr3377234wfh.264.1239733480379; Tue, 14 Apr 2009 11:24:40 -0700 (PDT) In-Reply-To: References: <49A701DF.5070109@lissyara.su> <3c1674c90902261300x6dd5f21bja58ecf214bcfb644@mail.gmail.com> <49A70508.20100@lissyara.su> Date: Tue, 14 Apr 2009 11:24:40 -0700 X-Google-Sender-Auth: b16926b96e471a7e Message-ID: <539c60b90904141124j839dd20qb20e3e14b05e6f97@mail.gmail.com> From: Steve Franks To: Sepherosa Ziehau Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: Alex Keda , freebsd-current@freebsd.org, Kip Macy Subject: Re: About bwi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 18:44:59 -0000 2009/2/26 Sepherosa Ziehau : > On Fri, Feb 27, 2009 at 5:09 AM, Alex Keda wrote: >> Kip Macy =D0=C9=DB=C5=D4: >>> >>> Someone needs to be there to maintain it. To the best of my knowledge >>> no one appropriate has stepped forward. >>> >> >> And what exactly should be supported? >> He finished - nothing more to do. > > I actually didn't finish it (the finished part works well enough for > me on dfly for all of the 8 bcm cards I have) and I do not have enough > time to keep working on it. =9ASeveral folks mailed me about what to do > next, I pointed them to the spec on the web, however, I didn't hear > from any of them after that. > >> >> no way to develop a driver. >> the new cards have to write a new driver. > > I based on following URL when I worked on the "old" driver: > http://bcm-specs.sipsolutions.net/ > > For newer parts you will need following one: > http://bcm-v4.sipsolutions.net/ > > Hope this will be useful to you. > > Best Regards, > sephe > > -- > Live Free or Die > _______________________________________________ > 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= " > If someone could give me a hand on where to stick the tgz into /usr/src and get started, I'll have a go...I've written alot of drivers for 8051-style toys, I'm not sure if I'm man enough for this, but I'd rather try and fail, then skip the attempt. If nothing else, a working bwi in ports would answer an awful lot of ndisgen emails... I've seen a number of posts around the web. Was this for stable or current? I really don't have a functional current box at the moment, but several stable boxes where ndis0 won't find my AP's... Just to add to the fun, my latest system is brand-new, so it's a mini-pci-express bwi; I assume if that works, it's going to incorporate alot of other new cards... Steve From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 18:49: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 14BAA106566B; Tue, 14 Apr 2009 18:49:23 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6B58FC22; Tue, 14 Apr 2009 18:49:21 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from wolfram.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n3EISY4P057352; Tue, 14 Apr 2009 20:28:34 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <49E4D5D1.2090504@fgznet.ch> Date: Tue, 14 Apr 2009 20:28:33 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Joe Marcus Clarke , current References: <1239689868.1304.209.camel@shumai.marcuscom.com> In-Reply-To: <1239689868.1304.209.camel@shumai.marcuscom.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: Subject: Re: Panic in vfs_cache on i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 18:49:23 -0000 Joe Marcus Clarke wrote: > I'm seeing this panic on my -CURRENT i386 Tinderbox machine (using > looped back NFS). The backtrace does not point to a line number in > vfs_cache.c, and I can't figure out how atomic_cmpset_int is being > called, so I'm confused as to exactly what is causing this. Any clues? > > FreeBSD fugu.marcuscom.com 8.0-CURRENT FreeBSD 8.0-CURRENT #20: Mon Apr 13 17:21:39 EDT 2009 gnome@fugu.marcuscom.com:/space/obj/usr/src/sys/FUGU i386 > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x84 > fault code = supervisor write, page not present > instruction pointer = 0x20:0x80670cf0 > stack pointer = 0x28:0xb9d59974 > frame pointer = 0x28:0xb9d599a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 82240 (sh) > panic: from debugger > cpuid = 1 > > > #0 doadump () at pcpu.h:246 > #1 0x804958c9 in db_fncall (dummy1=1, dummy2=0, dummy3=-2137255936, dummy4=0xb9d59708 "\200��\204") at /usr/src/sys/ddb/db_command.c:548 > #2 0x80495cc1 in db_command (last_cmdp=0x8094251c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 > #3 0x80495e1a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #4 0x80497c5d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 > #5 0x80629ef6 in kdb_trap (type=12, code=0, tf=0xb9d59934) at /usr/src/sys/kern/subr_kdb.c:534 > #6 0x808666ef in trap_fatal (frame=0xb9d59934, eva=132) at /usr/src/sys/i386/i386/trap.c:917 > #7 0x80866990 in trap_pfault (frame=0xb9d59934, usermode=0, eva=132) at /usr/src/sys/i386/i386/trap.c:839 > #8 0x80867362 in trap (frame=0xb9d59934) at /usr/src/sys/i386/i386/trap.c:521 > #9 0x8084b93b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > #10 0x80670cf0 in cache_lookup (dvp=0x8a55a10c, vpp=0xb9d59b78, cnp=0xb9d59b8c) at atomic.h:153 > #11 0x80670f93 in vfs_cache_lookup (ap=0xb9d59a40) at /usr/src/sys/kern/vfs_cache.c:869 > #12 0x808736e6 in VOP_LOOKUP_APV (vop=0x8092a680, a=0xb9d59a40) at vnode_if.c:123 > #13 0x80678351 in lookup (ndp=0xb9d59b60) at vnode_if.h:54 > #14 0x806792ab in namei (ndp=0xb9d59b60) at /usr/src/sys/kern/vfs_lookup.c:256 > #15 0x8068893b in kern_statat_vnhook (td=0x86085000, flag=0, fd=-100, path=0x33f02400
, pathseg=UIO_USERSPACE, sbp=0xb9d59c18, hook=0) at /usr/src/sys/kern/vfs_syscalls.c:2356 > #16 0x80688aac in kern_statat (td=0x86085000, flag=0, fd=-100, path=0x33f02400
, pathseg=UIO_USERSPACE, sbp=0xb9d59c18) at /usr/src/sys/kern/vfs_syscalls.c:2337 > #17 0x80688bf6 in kern_stat (td=0x86085000, path=0x33f02400
, pathseg=UIO_USERSPACE, sbp=0xb9d59c18) at /usr/src/sys/kern/vfs_syscalls.c:2329 > #18 0x80688c9f in stat (td=0x86085000, uap=0xb9d59cf8) at /usr/src/sys/kern/vfs_syscalls.c:2298 > #19 0x80866cd5 in syscall (frame=0xb9d59d38) at /usr/src/sys/i386/i386/trap.c:1066 > #20 0x8084b9a0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 > #21 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > print *dvp > $6 = {v_type = VDIR, v_tag = 0x808c518a "ufs", v_op = 0x8092a160, > v_data = 0x8a1f707c, v_mount = 0x8531b500, v_nmntvnodes = { > tqe_next = 0x8a554754, tqe_prev = 0x8a55a65c}, v_un = {vu_mount = 0x0, > vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, > v_hashlist = {le_next = 0x8600d324, le_prev = 0x8503b170}, > v_hash = 10739825, v_cache_src = {lh_first = 0x0}, v_cache_dst = { > tqh_first = 0x0, tqh_last = 0x8a55a13c}, v_cache_dd = 0x86770120, > v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = { > lo_name = 0x808c518a "ufs", lo_flags = 91947009, lo_data = 0, > lo_witness = 0x0}, lk_lock = 1, lk_timo = 51, lk_pri = 80}, > v_interlock = {lock_object = {lo_name = 0x808d15c1 "vnode interlock", > lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, > v_vnlock = 0x8a55a164, v_holdcnt = 3, v_usecount = 3, v_iflag = 0, > v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0x0, > tqe_prev = 0x0}, v_bufobj = {bo_mtx = {lock_object = { > lo_name = 0x808d15d1 "bufobj interlock", lo_flags = 16973824, > lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, bo_clean = {bv_hd = { > tqh_first = 0x0, tqh_last = 0x8a55a1c8}, bv_root = 0x0, bv_cnt = 0}, > bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0x8a55a1d8}, > bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, > bo_ops = 0x8091ab80, bo_bsize = 16384, bo_object = 0x8a6c245c, > bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0x8a55a10c, > __bo_vnode = 0x8a55a10c}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0} > > print *vpp > $7 = (struct vnode *) 0x0 > > print *cnp > $9 = {cn_nameiop = 0, cn_flags = 83943748, cn_thread = 0x86085000, > cn_cred = 0x85ad4d00, cn_lkflags = 2097152, cn_pnbuf = 0x8acf6400 "..", > cn_nameptr = 0x8acf6400 "..", cn_namelen = 2, cn_consume = 0} I see something similar on an amd64 box. I can reproduce it while make -j4 buildworld. Andreas FreeBSD deuterium_fbsd.andreas.nets 8.0-CURRENT FreeBSD 8.0-CURRENT #1 r191065M: Tue Apr 14 19:55:16 CEST 2009 andreast@deuterium_fbsd.andreas.nets:/export/devel/obj/export/devel/src/sys/ANDREAST_amd64 amd64 Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xd8 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff805d96f6 stack pointer = 0x28:0xfffffffe7e8aa6b0 frame pointer = 0x28:0xfffffffe7e8aa730 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 = 12576 (sh) panic: from debugger cpuid = 0 Uptime: 2m23s Physical memory: 2034 MB Dumping 187 MB: 172 156 140 124 108 92 76 60 44 28 12 #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 0xffffffff80563209 in boot (howto=260) at /export/devel/src/sys/kern/kern_shutdown.c:420 #2 0xffffffff8056365c in panic (fmt=Variable "fmt" is not available. ) at /export/devel/src/sys/kern/kern_shutdown.c:576 #3 0xffffffff801cce47 in db_panic (addr=Variable "addr" is not available. ) at /export/devel/src/sys/ddb/db_command.c:478 #4 0xffffffff801cd251 in db_command (last_cmdp=0xffffffff80b97520, cmd_table=Variable "cmd_table" is not available. ) at /export/devel/src/sys/ddb/db_command.c:445 #5 0xffffffff801cd4a0 in db_command_loop () at /export/devel/src/sys/ddb/db_command.c:498 #6 0xffffffff801cf429 in db_trap (type=Variable "type" is not available. ) at /export/devel/src/sys/ddb/db_main.c:229 #7 0xffffffff80593265 in kdb_trap (type=12, code=0, tf=0xfffffffe7e8aa600) at /export/devel/src/sys/kern/subr_kdb.c:534 #8 0xffffffff80839e2d in trap_fatal (frame=0xfffffffe7e8aa600, eva=Variable "eva" is not available. ) at /export/devel/src/sys/amd64/amd64/trap.c:840 #9 0xffffffff8083a204 in trap_pfault (frame=0xfffffffe7e8aa600, usermode=0) at /export/devel/src/sys/amd64/amd64/trap.c:761 #10 0xffffffff8083ab18 in trap (frame=0xfffffffe7e8aa600) at /export/devel/src/sys/amd64/amd64/trap.c:487 #11 0xffffffff80815973 in calltrap () at /export/devel/src/sys/amd64/amd64/exception.S:223 ---Type to continue, or q to quit--- #12 0xffffffff805d96f6 in cache_lookup (dvp=0x0, vpp=0xfffffffe7e8aa970, cnp=0xfffffffe7e8aa998) at atomic.h:147 #13 0xffffffff805d9ac0 in vfs_cache_lookup (ap=Variable "ap" is not available. ) at /export/devel/src/sys/kern/vfs_cache.c:869 #14 0xffffffff80881640 in VOP_LOOKUP_APV (vop=0xffffffff80b6d180, a=0xfffffffe7e8aa810) at vnode_if.c:123 #15 0xffffffff805e0b2b in lookup (ndp=0xfffffffe7e8aa940) at vnode_if.h:54 #16 0xffffffff805e1b41 in namei (ndp=0xfffffffe7e8aa940) at /export/devel/src/sys/kern/vfs_lookup.c:256 #17 0xffffffff805f0adf in kern_statat_vnhook (td=0xffffff0032352a80, flag=Variable "flag" is not available. ) at /export/devel/src/sys/kern/vfs_syscalls.c:2356 #18 0xffffffff805f0ca5 in kern_statat (td=Variable "td" is not available. ) at /export/devel/src/sys/kern/vfs_syscalls.c:2337 #19 0xffffffff805f0e4a in stat (td=Variable "td" is not available. ) at /export/devel/src/sys/kern/vfs_syscalls.c:2298 #20 0xffffffff8083a476 in syscall (frame=0xfffffffe7e8aac90) at /export/devel/src/sys/amd64/amd64/trap.c:977 #21 0xffffffff80815c00 in Xfast_syscall () at /export/devel/src/sys/amd64/amd64/exception.S:364 #22 0x000000080099fcfc in ?? () Previous frame inner to this frame (corrupt stack?) From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 19:02: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 9E327106566B for ; Tue, 14 Apr 2009 19:02:20 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 4F35F8FC15 for ; Tue, 14 Apr 2009 19:02:20 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1607530yxm.13 for ; Tue, 14 Apr 2009 12:02:19 -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=0WDKdl6L06Vi48CU8e1TgStYz7AnDMmWfo6/0odypzQ=; b=gwW/aanknDmzo0sb/fQmIrdvO5bPV9BV4doqI+oZFckhgqqaFe4zxfXqf1fRi7JqON mP45r8HM/xxVFHJJmjvpvTCPqVWzzV2B02KBM1wceE0nMCtYfkEBkQQHmqDHzds+cRAe wEBr8yVUlG9SYPMZlYCfI++m+A9Sc23H5gSFA= 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=pTa+o2RdsbjVFYSiqXnTqZL0pCRTdtPZwHCt3N2PDPrPom8HjWoko5I9KpMM+NHmf9 6rjDVXsiI2tWZpo4A0bMpMC7upYDUzC8ClpZXAs3kQYaXvypw34KseAgVtaRNWyEovsL hdKcMsYOBGGnd3yDXGSNlkYUaZxzMvn2FRmZI= MIME-Version: 1.0 Sender: maksim.yevmenkin@gmail.com Received: by 10.90.84.2 with SMTP id h2mr10117103agb.72.1239735738717; Tue, 14 Apr 2009 12:02:18 -0700 (PDT) In-Reply-To: <20090414180020.34b97378@fabiankeil.de> References: <200904082052.n38KqU9p075633@svn.freebsd.org> <20090412170335.5a8a3169@fabiankeil.de> <20090414180020.34b97378@fabiankeil.de> Date: Tue, 14 Apr 2009 12:02:18 -0700 X-Google-Sender-Auth: fb2d0742ae798941 Message-ID: From: Maksim Yevmenkin To: Fabian Keil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: svn commit: r190857 - head/sys/dev/kbdmux X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 19:02:21 -0000 On Tue, Apr 14, 2009 at 9:00 AM, Fabian Keil wrote: > Maksim Yevmenkin wrote: > >> On Sun, Apr 12, 2009 at 8:03 AM, Fabian Keil >> wrote: >> > Maksim Yevmenkin wrote: >> > >> >> Author: emax >> >> Date: Wed Apr 8 20:52:30 2009 >> >> New Revision: 190857 >> >> URL: http://svn.freebsd.org/changeset/base/190857 >> >> >> >> Log: >> >> Undo SVN rev 183283 >> >> >> >> Do not use Giant for kbdmux(4) locking. This is wrong and apparently >> >> causing more problems than it solves. This will re-open the issue >> >> where interrupt handlers may race with kbdmux(4) in polling mode. >> >> Typical symptoms include (but not limited to) duplicated and/or >> >> missing characters when low level console functions (such as gets) >> >> are used while interrupts are enabled (for example geli password >> >> prompt, mountroot prompt etc.) >> >> >> >> MFC after: 3 days >> >> >> >> Modified: >> >> head/sys/dev/kbdmux/kbdmux.c > > [...] > >> > Not even enabling the "visible characters" option helps >> > because obviously backspace is broken too. >> >> if you do not need kbdmix(4) you might just want to disable it on your >> system. i think it should help with your particular problem. > > Removing kbdmux from the kernel does indeed work around the problem. > >> > Before theses locks were introduces I worked around the problem >> > with this gets() hack (which forced me to reduce the key entropy): >> > http://www.fabiankeil.de/sourcecode/freebsd/gets-no-duplicates.diff >> > and now I will simply revert your commit locally, but I assume I'm >> > not the only geli user who prefers to be able to boot the system >> > without local patches. >> >> if your primary keyboard is atkbd(4), you might want to try the >> following patch. it is completely untested (i did not even compile >> it), so be warned ... > > It compiles alright but once the system is running the keyboard > no longer works at all. I tested the patch with kbdmux already > disabled, but I assume it doesn't make a difference. hmmm, interesting, i do not see this. atkbd(4) is working just fine with and without kbdmux(4) for me in sinlge user, ddb and multiuser. > Anyway, I don't need kbdmux, so having to remove it is no problem. > Thanks a lot. ok thanks max From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 19:11: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 B2A30106564A for ; Tue, 14 Apr 2009 19:11:31 +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 6AEF68FC15 for ; Tue, 14 Apr 2009 19:11:30 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.146.160] (port=27168 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lto2b-000Att-Bs; Tue, 14 Apr 2009 23:11:29 +0400 Message-ID: <49E4DFF7.4040008@lissyara.su> Date: Tue, 14 Apr 2009 23:11:51 +0400 From: Alex Keda User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Andriy Gapon References: <49E41A2F.9080105@lissyara.su> <49E46C57.7030306@icyb.net.ua> In-Reply-To: <49E46C57.7030306@icyb.net.ua> 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: freebsd-current@freebsd.org Subject: Re: NMI ISA 2c, EISA ff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 19:11:31 -0000 Andriy Gapon пишет: > on 14/04/2009 08:07 Alex Keda said the following: >> I try install FreBSD; boot from USB hard drive on HP 2133 (laptop) >> Boot not success: >> >> agp0: on host0 >> agp0: aperture size is 128M >> NMI ISA 2c, EISA ff > > I am not an expert here, but I had the above message on flaky hardware. > But, again, the same symptoms do not mean the same cause. I boot from flash drive with custom kernel (7.1 based) and copy CURRENT to hard drive It not boot with same error > >> NMI ... going to debugger >> [thread pid0 tid 100000 ] >> Stopped at pmap_remove+0x158: testl %eax,%eax >> db> >> >> If I do not unplug hard drive - reboot with 2-3 seconds >> If unplug - not reboot, but, 'db>' go to down - kind of press enter >> (~10-20 seconds period) >> System - i386, GENERIC, from yesterday sources > > From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 16:08: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 2DFBC10656BD; Tue, 14 Apr 2009 16:08:54 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id DAC4B8FC27; Tue, 14 Apr 2009 16:08:53 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1LtlBs-0006NC-VB>; Tue, 14 Apr 2009 18:08:52 +0200 Received: from e178041238.adsl.alicedsl.de ([85.178.41.238] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1LtlBs-0000dq-S7>; Tue, 14 Apr 2009 18:08:52 +0200 Message-ID: <49E4B516.2080901@mail.zedat.fu-berlin.de> Date: Tue, 14 Apr 2009 18:08:54 +0200 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.21 (X11/20090410) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org, freebsd-questions@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.41.238 X-Mailman-Approved-At: Tue, 14 Apr 2009 19:27:46 +0000 Cc: Subject: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 16:08:57 -0000 On two boxes running FreeBSD 8.0-CURRENT/amd64 (both PCIe-basis) I utilise AMD/ATi RV770LE and RV730 based graphicsadapter. Both machines run the most recent FreeBSD 8.0-CURRENT and most recent X11 from ports (with all the subsequent packages). The box with the most powerful graphicsadapter is the lowest powerful box, equipted with a UP kernel, single core CPU, PCIe 1.1. The GPU is a RV770LE mounted on a MSI R4830T2D512, This box does only work properly with driver 'radeon', using driver 'radeonhd' results in a missing display adapter - means, driver connot find a valid graphics card. On my lab's box, a 4-core SMP box with a more modern P35 chipset I utilise a MSI R4760 graphics card, this uses a AMD/ATi RV730 chip as GPU. This box does only run with 'radeonhd' in a propper manner, using 'radeon' craches the box when shutting down/resetting (kill -1) Xorg (server) when rebooting or leaving windowmaker. Although 'radeonhd' works and 'radeon' not, using 'radeonhd' renders X unusable. Window movement is like a slideshow, firefox seems to sleep randomly, scrolling is a game for patient people. VESA driver is much faster than 'radeonhd' on this fast chipset! Well, xf86-video-radeonhd is at revision 1.2.5 and this one is, when believing what the Wiki says, under development and advisory of AMD itself. Why is it so bumpy and unwilling to recognize an RV770LE chipset? Does anyone has a hint or tip? It feels like a mess having two ATI drivers each one following different ways of development. What 'radeon' is capable of is missing in 'radeonhd' and vice versa. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 19:22: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 93FCA10656DB for ; Tue, 14 Apr 2009 19:22:40 +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 42E188FC12 for ; Tue, 14 Apr 2009 19:22:40 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.146.160] (port=54497 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtoDN-000DGU-HK; Tue, 14 Apr 2009 23:22:37 +0400 Message-ID: <49E4E293.7000302@lissyara.su> Date: Tue, 14 Apr 2009 23:22:59 +0400 From: Alex Keda User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Steve Franks References: <49A701DF.5070109@lissyara.su> <3c1674c90902261300x6dd5f21bja58ecf214bcfb644@mail.gmail.com> <49A70508.20100@lissyara.su> <539c60b90904141124j839dd20qb20e3e14b05e6f97@mail.gmail.com> In-Reply-To: <539c60b90904141124j839dd20qb20e3e14b05e6f97@mail.gmail.com> 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: Sepherosa Ziehau , freebsd-current@freebsd.org, Kip Macy Subject: Re: About bwi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 19:22:42 -0000 Steve Franks ÐÉÛÅÔ: > 2009/2/26 Sepherosa Ziehau : >> On Fri, Feb 27, 2009 at 5:09 AM, Alex Keda wrote: >>> Kip Macy ÐÉÛÅÔ: >>>> Someone needs to be there to maintain it. To the best of my knowledge >>>> no one appropriate has stepped forward. >>>> >>> And what exactly should be supported? >>> He finished - nothing more to do. >> I actually didn't finish it (the finished part works well enough for >> me on dfly for all of the 8 bcm cards I have) and I do not have enough >> time to keep working on it. Several folks mailed me about what to do >> next, I pointed them to the spec on the web, however, I didn't hear >> from any of them after that. >> >>> no way to develop a driver. >>> the new cards have to write a new driver. >> I based on following URL when I worked on the "old" driver: >> http://bcm-specs.sipsolutions.net/ >> >> For newer parts you will need following one: >> http://bcm-v4.sipsolutions.net/ >> >> Hope this will be useful to you. >> >> Best Regards, >> sephe >> >> -- >> Live Free or Die >> _______________________________________________ >> 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" >> > > If someone could give me a hand on where to stick the tgz into > /usr/src and get started, I'll have a go...I've written alot of > drivers for 8051-style toys, I'm not sure if I'm man enough for this, > but I'd rather try and fail, then skip the attempt. If nothing else, > a working bwi in ports would answer an awful lot of ndisgen emails... http://paradox.lissyara.su/bwi.02.tar.bz2 - 7.x http://paradox.lissyara.su/bwi.02e.tar.bz2 - current but - it only for PCI (PCMCI) new card - need new driver. see http://paradox.lissyara.su/bwi.03e.tar.bz2 It not work (only detecting correct). need write code > > I've seen a number of posts around the web. Was this for stable or > current? I really don't have a functional current box at the moment, > but several stable boxes where ndis0 won't find my AP's... > > Just to add to the fun, my latest system is brand-new, so it's a > mini-pci-express bwi; I assume if that works, it's going to > incorporate alot of other new cards... > > Steve > From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 19:30: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 583561065756; Tue, 14 Apr 2009 19:30: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 5ACF98FC15; Tue, 14 Apr 2009 19:30:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2EAFE46B8D; Tue, 14 Apr 2009 15:30:52 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 927DA8A04E; Tue, 14 Apr 2009 15:30:50 -0400 (EDT) From: John Baldwin To: Jung-uk Kim Date: Tue, 14 Apr 2009 10:15:39 -0400 User-Agent: KMail/1.9.7 References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904131305.12605.jhb@freebsd.org> <200904131836.57686.jkim@FreeBSD.org> In-Reply-To: <200904131836.57686.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904141015.40280.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 14 Apr 2009 15:30:50 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=1.5 required=4.2 tests=DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Diego Depaoli , freebsd-current@freebsd.org Subject: Re: AMD 780G chipset major issues 3/3 (btx) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 19:30:56 -0000 On Monday 13 April 2009 6:36:55 pm Jung-uk Kim wrote: > On Monday 13 April 2009 01:05 pm, John Baldwin wrote: > > On Wednesday 08 April 2009 3:37:38 pm Diego Depaoli wrote: > > > On Tue, Apr 7, 2009 at 4:26 PM, John Baldwin =20 > wrote: > > > > On Monday 06 April 2009 5:02:53 pm Diego Depaoli wrote: > > > >> And finally... > > > >> if I enable ahci in bios the system won't boot =A0with btx > > > >> halted. Ctrl+alt+del is the only allowed action. > > > >> > > > >> Yes... it's a low cost motherboard, but I'm a bit confused. > > > > > > > > What OS release are you running? > > > > > > 8.0-CURRENT FreeBSD 8.0-CURRENT #19: Sun Apr 5 02:25:34 CEST > > > 2009 FreeBSD version 800074 > > > > Very odd, can you get a copy of the BTX fault output? >=20 > As I said earlier, I have a similar board and this is what I got: >=20 > int=3D0000000d err=3D00000000 efl=3D00030002 eip=3D000001b1 > eax=3D00000011 ebx=3D00000002 ecx=3D00009d82 edx=3D0009dbc8 > esi=3D000003f0 edi=3D00000368 ebp=3D000003a8 esp=3D00000362 > cs=3Dcf00 ds=3D0040 es=3D1400 fs=3D0000 gs=3D0000 ss=3D9d82 > cs:eip=3D2e 0f 01 16 7d 00 0f 20-c0 0c 01 0f 22 c0 eb 00 > b8 08 00 8e d8 8e c0 8e-d0 66 2e a1 54 00 66 8b > ss:esp=3D3f 00 c0 96 00 00 11 00-00 00 00 14 40 00 02 2f > 46 00 02 00 00 00 f0 03-00 00 a8 03 00 00 94 03 >=20 > The following is the disassembled code: >=20 > 0: 2e 0f 01 16 lgdtl %cs:(%esi) Are you sure you are using the real mode BTX? This trap has PSL_VM set in= =20 eflags: #define PSL_VM 0x00020000 /* virtual 8086 mode bit */ which would indicate that you are still using the old boot code. (Perhaps = you=20 have a new loader but have not installed new boot blocks using bsdlabel?) =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Apr 14 21:18: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 7A80B106566C for ; Tue, 14 Apr 2009 21:18:40 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate02.web.de (fmmailgate02.web.de [217.72.192.227]) by mx1.freebsd.org (Postfix) with ESMTP id D9EC98FC16 for ; Tue, 14 Apr 2009 21:18:39 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate02.web.de (Postfix) with ESMTP id 30E55FCFFBBC; Tue, 14 Apr 2009 23:18:38 +0200 (CEST) Received: from [217.236.2.206] (helo=zelda.local) by smtp08.web.de with asmtp (TLSv1:AES128-SHA:128) (WEB.DE 4.110 #277) id 1Ltq1d-0005kq-00; Tue, 14 Apr 2009 23:18:37 +0200 Date: Tue, 14 Apr 2009 23:18:39 +0200 From: Martin To: "O. Hartmann" Message-ID: <20090414231839.46d634f2@zelda.local> In-Reply-To: <49E4B516.2080901@mail.zedat.fu-berlin.de> References: <49E4B516.2080901@mail.zedat.fu-berlin.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX18HhQZYdldbga7QkREoHe5Nigbne9aEqCZtUHfC Ml+JbHlhev0BfOb1r5Cr+4aho2vn9SAF/onaAGJpYvfqqY1jOF egL5hXA1Y= Cc: freebsd-current@freebsd.org Subject: Re: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Apr 2009 21:18:40 -0000 Am Tue, 14 Apr 2009 18:08:54 +0200 schrieb "O. Hartmann" : > [...] Hi, if you have problems with the radeonhd driver, you should tell the guys who work at it. They are really nice and try to help everywhere. Subscribe there: http://lists.opensuse.org/radeonhd/ I am only using radeonhd, because it works for me on all cards I have. I noticed that window movement may get choppy, when you compile a new kernel (DRM) and don't recompile a fresh radeonhd driver. This happens especially when DRI is enabled for your xorg server. -- Martin From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 00:19: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 621951065670; Wed, 15 Apr 2009 00:19:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailhub.cs.uoguelph.ca (mailhub.cs.uoguelph.ca [131.104.94.205]) by mx1.freebsd.org (Postfix) with ESMTP id C66708FC15; Wed, 15 Apr 2009 00:19:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by mailhub.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n3ENrlDJ004931; Tue, 14 Apr 2009 19:53:48 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n3F00HO04218; Tue, 14 Apr 2009 20:00:17 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 14 Apr 2009 20:00:17 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Joe Marcus Clarke In-Reply-To: <1239689868.1304.209.camel@shumai.marcuscom.com> Message-ID: References: <1239689868.1304.209.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.205 Cc: current Subject: Re: Panic in vfs_cache on i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 00:19:03 -0000 On Tue, 14 Apr 2009, Joe Marcus Clarke wrote: > I'm seeing this panic on my -CURRENT i386 Tinderbox machine (using > looped back NFS). The backtrace does not point to a line number in > vfs_cache.c, and I can't figure out how atomic_cmpset_int is being > called, so I'm confused as to exactly what is causing this. Any clues? > Only a clue. but I'd guess it's one of the SDT_PROBE()s. I think they us sx_xlock() and that uses atomic_cmpset_int(). I don't know anything about SDT_PROBE(), but I did notice that this one uses cn_nameptr, which I don't think is always null terminated. You could try commenting out the SDT_PROBE()s in cache_lookup() and see if it helps? rick - around line #440 in vfs_cache.c /* We failed to find an entry */ if (ncp == NULL) { ---> SDT_PROBE(vfs, namecache, lookup, miss, dvp, cnp->cn_nameptr, NULL, 0, 0); if ((cnp->cn_flags & MAKEENTRY) == 0) { nummisszap++; } else { nummiss++; } nchstats.ncs_miss++; goto unlock; } From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 00:23:34 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 79CF710656E9; Wed, 15 Apr 2009 00:23:34 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: John Baldwin Date: Tue, 14 Apr 2009 20:23:25 -0400 User-Agent: KMail/1.6.2 References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904131836.57686.jkim@FreeBSD.org> <200904141015.40280.jhb@freebsd.org> In-Reply-To: <200904141015.40280.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200904142023.26679.jkim@FreeBSD.org> Cc: Diego Depaoli , freebsd-current@freebsd.org Subject: Re: AMD 780G chipset major issues 3/3 (btx) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 00:23:35 -0000 On Tuesday 14 April 2009 10:15 am, John Baldwin wrote: > Are you sure you are using the real mode BTX? This trap has PSL_VM > set in eflags: > > #define PSL_VM 0x00020000 /* virtual 8086 mode bit */ > > which would indicate that you are still using the old boot code. > (Perhaps you have a new loader but have not installed new boot > blocks using bsdlabel?) That is embarrassing... I thought I had the realmode boot block but I was wrong. I had a screwed-up bsdlabel from sysinstall at some point. When I did 'bsdlabel -B', it failed to install the boot block at all but I ignored the error message, I guess. :-( The bright side of this embarrassment is now I have warning-free bsdlabels on all partitions. ;-) Sorry for the noise. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 00:41: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 450D7106564A for ; Wed, 15 Apr 2009 00:41:41 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 12E658FC08 for ; Wed, 15 Apr 2009 00:41:40 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from pd2ml2so-ssvc.prod.shaw.ca ([10.0.141.134]) by pd3mo1so-svcs.prod.shaw.ca with ESMTP; 14 Apr 2009 18:13:09 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=6I5d2MoRAAAA:8 a=8m31e5TbdlaXrby25PkA:9 a=lmOeJrDESIZ-yPpa299U_swEascA:4 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=wAGQQ9Az6v0A:10 Received: from s01060002b31a8191.gv.shawcable.net (HELO spqr.komquats.com) ([24.68.166.226]) by pd2ml2so-dmz.prod.shaw.ca with ESMTP; 14 Apr 2009 18:13:09 -0600 Received: from cwsys.cwsent.com (cwsys [10.1.1.1]) by spqr.komquats.com (Postfix) with ESMTP id EE6A2410FA for ; Tue, 14 Apr 2009 17:13:07 -0700 (PDT) Received: from cwsys (localhost [127.0.0.1]) by cwsys.cwsent.com (8.14.3/8.14.3) with ESMTP id n3F0D7XW004721 for ; Tue, 14 Apr 2009 17:13:07 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <200904150013.n3F0D7XW004721@cwsys.cwsent.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Apr 2009 17:13:07 -0700 Sender: Cy.Schubert@komquats.com Cc: Subject: GDM Hanging Machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 00:41:41 -0000 I thought to post this here before spending a lot of time on this. I have a laptop which normally boots 7.2-PRERELEASE however I do have CURRENT on a USB drive where I'm working on some USB floppy drive code. When GDM starts the whole system hangs. Before digging into this too deeply myself, has anyone seen this before and is there a quick fix? The ports collection on that drive was built on a 7.2 system and copied to the CURRENT system. This may in fact be the root cause and if so the fix is a no brainer. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org e**(i*pi)+1=0 From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 00:55: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 B2902106564A; Wed, 15 Apr 2009 00:55:03 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id BF71F8FC17; Wed, 15 Apr 2009 00:55:02 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: by fxm11 with SMTP id 11so2724338fxm.43 for ; Tue, 14 Apr 2009 17:55:01 -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=CO0FhMI17cWC5LBulZxX/F0JTHg0RK6EDs5XkAxBNjc=; b=BiQlomhX7BbqNjosuOj/R6ogVS7loofF6UJYP2ON33oOxIXAYBoHNwudROPR5zlXO9 d8XAflUwwcm8DgOYXN1nhHuD/V+SIcKK53QUyoactxNtEDVyIwVbr91py5iSTbJn6rS6 HiMWfP4/iuR5hBitW5kwEjEU9XGh6r9A4brT8= 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=Nzlj7ARWMltOqhOLGHQlJZSh/JeAxNhBDxI1XFE72M+FJRnbMzt+lNIj92CdpWP5je 45dvlZ2yGAmo1CCm2H5bcjW6fJRRA2Z9g4SuuU0JEJjaAqOHjrdSFm4kdiZoMgnmq9E+ JZoS5qaX3Ko78erCeEqYcYFgQ0Fl/3SRrgbno= MIME-Version: 1.0 Received: by 10.223.127.8 with SMTP id e8mr2207780fas.81.1239756901867; Tue, 14 Apr 2009 17:55:01 -0700 (PDT) In-Reply-To: <200904142023.26679.jkim@FreeBSD.org> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904131836.57686.jkim@FreeBSD.org> <200904141015.40280.jhb@freebsd.org> <200904142023.26679.jkim@FreeBSD.org> Date: Wed, 15 Apr 2009 02:55:01 +0200 Message-ID: <83e5fb980904141755l3cf99fbdy75c2cdece4b25904@mail.gmail.com> From: Diego Depaoli To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: AMD 780G chipset major issues 3/3 (btx) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 00:55:04 -0000 On Wed, Apr 15, 2009 at 2:23 AM, Jung-uk Kim wrote: > > That is embarrassing... =A0I thought I had the realmode boot block but I > was wrong. =A0I had a screwed-up bsdlabel from sysinstall at some > point. =A0When I did 'bsdlabel -B', it failed to install the boot block > at all but I ignored the error message, I guess. :-( Unfortunately that doesn't solve for me. I have a drive (ad4, ad6) - ad4s1 -> windows - ad4s2 -> linux swap - ad4s3 -> linux - ad4s4 -> FreeBSD bootloader is managed through EasyBCD Not being an expert I gave bsdlabel -B ad4s4 (is the right command?) but after that I get the same result int=3D0000000d err=3D00000000 efl=3D00030002 eip=3D000001e8 eax=3D00000010 ebx=3D00000002 ecx=3D00009e42 edx=3D0009e7c8 esi=3D000003f0 edi=3D0000036e ebp=3D000003a8 esp=3D00000368 cs=3Dcf00 ds=3D0040 es=3D1400 fs=3D0000 gs=3D0000 ss=3D9e42 cs:eip=3D0f 22 c0 2e 0f 01 16 85-00 0f 20 c0 0c 01 0f 22 c0 eb 00 b8 08 00 8e d8-8e c0 8e d0 66 2e a1 5c ss:esp=3D3f 00 c0 96 00 00 00 14-40 00 46 00 02 00 00 00 f0 03 00 00 a8 03 00 00-94 03 00 00 00 00 00 00 Where I'm wrong? Best regards --=20 Diego Depaoli From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 02:32:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AECCD1065679 for ; Wed, 15 Apr 2009 02:32:34 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0AB138FC12 for ; Wed, 15 Apr 2009 02:32:33 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n3F2WPw8002462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Apr 2009 02:32:26 GMT (envelope-from ben@wanderview.com) Message-Id: From: Ben Kelly To: Artem Belevich In-Reply-To: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 22:32:25 -0400 References: <49C2CFF6.8070608@egr.msu.edu> <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> X-Mailer: Apple Mail (2.930.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: freebsd-current@freebsd.org Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 02:32:35 -0000 On Apr 14, 2009, at 11:50 AM, Ben Kelly wrote: > On Apr 13, 2009, at 7:36 PM, Artem Belevich wrote: >> Tried your patch that used PRIBIO+{1,2} for priorities with -current >> r191008 and the kernel died with "spinlock held too long" panic. >> Actually, there apparently were two instances of panic on different >> cores.. >> >> Here's output of "alltrace" and "ps" after the crash: >> http://pastebin.com/f140f4596 >> >> I've reverted the change and kernel booted just fine. >> >> The box is quad-core with two ZFS pools -- one single-disk and >> another >> one is a two-disk mirror. Freebsd is installed on UFS partitions, ZFS >> is used for user stuff only. > > Thanks for the report! > > I don't have a lot of time to look at this today, but it appears > that there is a race condition on SMP machines when setting the > priority immediately after the kproc is spawned. As a quick hack I > tried adding a pause between the kproc_create() and the > sched_prio(). Can you try this patch? > > http://www.wanderview.com/svn/public/misc/zfs_livelock/zfs_thread_priority.diff > > I'll try to take a closer look at this later in the week. Sorry for replying to my own e-mail, but I've updated the patch again with a less hackish approach. (At the same URL above.) I added a new kproc_create_priority() function to set the priority of the new thread before its first scheduled. This should avoid any SMP races with setting the priority from an external thread. If you would be willing to try the test again with this new patch I would appreciate it. Thanks! - Ben From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 04:35: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 6AB2B106566B for ; Wed, 15 Apr 2009 04:35:12 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id BEFB38FC08 for ; Wed, 15 Apr 2009 04:35:11 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by ewy19 with SMTP id 19so2857590ewy.43 for ; Tue, 14 Apr 2009 21:35:10 -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=dS+frVOQo9zQdwASbfvloVa9jGTkyUHJi+nYKND5yh0=; b=rHBtPdEzFm8Da91Knfe0Krthd5L0mWjZAD3ktQhhjDHBkuX/tOK68L+GnwmwwfKhEt Fbmz9Zo9G4TxMHTBjNsbnxaovJf3QsoOch+JatevbBLlJj9I/q/z3t6HZHkUo+Uc5ksV g714RTFs0mQwwE4yHyInrZ7VhgatxBIe0rs1o= 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=iuxTfkFWaqJ/dTmlWdVghoYxDJA9wNScaCyTdjfEifyYEz8z+Pc1bYZGzNxnW3Aerx oz/Lx0e0TrmFrQNBWp49sJsfT48QqKPbTbE2PeJpAlRSEq0KtWEr+QoErk+C8+UNRoqD GYkO2sxQeBuAGJP7NBFwjtWGHUFxvt4QceGSo= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.210.66.13 with SMTP id o13mr3665072eba.96.1239770110492; Tue, 14 Apr 2009 21:35:10 -0700 (PDT) In-Reply-To: References: <49C2CFF6.8070608@egr.msu.edu> <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> Date: Tue, 14 Apr 2009 21:35:10 -0700 X-Google-Sender-Auth: 295a3e47273c6058 Message-ID: From: Artem Belevich To: Ben Kelly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 04:35:12 -0000 I'll give it a try in a few days. I'll let you know how it went. BTW, now that you're tinkering with ZFS threads and priorities, whould you by any chance have any idea why zfs scrub is so painfully slow on -current? When I start scrub on my -stable box, it pretty much runs full speed -- I can see disks under load all the time. However on -current scrub seems to run in small bursts. Disks get busy for a second or so and then things get quiet for about five seconds or so and this pattern repeats over and over. --Artem On Tue, Apr 14, 2009 at 7:32 PM, Ben Kelly wrote: > On Apr 14, 2009, at 11:50 AM, Ben Kelly wrote: >> >> On Apr 13, 2009, at 7:36 PM, Artem Belevich wrote: >>> >>> Tried your patch that used PRIBIO+{1,2} for priorities with -current >>> r191008 and the kernel died with "spinlock held too long" panic. >>> Actually, there apparently were two instances of panic on different >>> cores.. >>> >>> Here's output of "alltrace" and "ps" after the crash: >>> http://pastebin.com/f140f4596 >>> >>> I've reverted the change and kernel booted just fine. >>> >>> The box is quad-core with two ZFS pools -- one single-disk and another >>> one is a two-disk mirror. Freebsd is installed on UFS partitions, ZFS >>> is used for user stuff only. >> >> Thanks for the report! >> >> I don't have a lot of time to look at this today, but it appears that >> there is a race condition on SMP machines when setting the priority >> immediately after the kproc is spawned. =A0As a quick hack I tried addin= g a >> pause between the kproc_create() and the sched_prio(). =A0Can you try th= is >> patch? >> >> >> =A0http://www.wanderview.com/svn/public/misc/zfs_livelock/zfs_thread_pri= ority.diff >> >> I'll try to take a closer look at this later in the week. > > Sorry for replying to my own e-mail, but I've updated the patch again wit= h a > less hackish approach. =A0(At the same URL above.) =A0I added a new > kproc_create_priority() function to set the priority of the new thread > before its first scheduled. =A0This should avoid any SMP races with setti= ng > the priority from an external thread. > > If you would be willing to try the test again with this new patch I would > appreciate it. > > Thanks! > > - Ben > From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 06:57: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 BC350106566C for ; Wed, 15 Apr 2009 06:57:11 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 764AA8FC12 for ; Wed, 15 Apr 2009 06:57:11 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Ltz3W-0001Gc-H1>; Wed, 15 Apr 2009 08:57:10 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Ltz3W-0002iX-F2>; Wed, 15 Apr 2009 08:57:10 +0200 Message-ID: <49E584F0.5030702@zedat.fu-berlin.de> Date: Wed, 15 Apr 2009 06:55:44 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Martin References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090414231839.46d634f2@zelda.local> In-Reply-To: <20090414231839.46d634f2@zelda.local> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: "O. Hartmann" , freebsd-current@freebsd.org Subject: Re: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 06:57:12 -0000 Martin wrote: > Am Tue, 14 Apr 2009 18:08:54 +0200 > schrieb "O. Hartmann" : > >> [...] > > Hi, > > if you have problems with the radeonhd driver, you should tell the guys > who work at it. They are really nice and try to help everywhere. > > Subscribe there: > http://lists.opensuse.org/radeonhd/ > > I am only using radeonhd, because it works for me on all cards I have. > > I noticed that window movement may get choppy, when you compile a new > kernel (DRM) and don't recompile a fresh radeonhd driver. This happens > especially when DRI is enabled for your xorg server. > > -- > Martin As far as I know, radeonhd from ports doesn't work with DRI enabled on FreeBSD - so it doesn't work on my box either. I guess you're following the recommendations using the development brnach directly from GIT. Thank's for the hint with DRM. I recompiled kernel/world stuff recently but I also recompiled all video driver also. I will do this and check whether it woul help enabling/disabling drm.ko/radeon.ko (which are both loaded when booing the kernel). Regards, Oliver Hartmann From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 09:38: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 C646D1065679 for ; Wed, 15 Apr 2009 09:38:31 +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 5FBA28FC13 for ; Wed, 15 Apr 2009 09:38:31 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.16] (helo=6.mx.freenet.de) by mout4.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #91) id 1Lu1Zd-0003La-MI; Wed, 15 Apr 2009 11:38:29 +0200 Received: from tdba1.t.pppool.de ([89.55.219.161]:55099 helo=ernst.jennejohn.org) by 6.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1Lu1Zd-0002zI-FC; Wed, 15 Apr 2009 11:38:29 +0200 Date: Wed, 15 Apr 2009 11:38:28 +0200 From: Gary Jennejohn To: "O. Hartmann" Message-ID: <20090415113828.46075cdc@ernst.jennejohn.org> In-Reply-To: <49E584F0.5030702@zedat.fu-berlin.de> References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090414231839.46d634f2@zelda.local> <49E584F0.5030702@zedat.fu-berlin.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Martin Subject: Re: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! 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, 15 Apr 2009 09:38:32 -0000 On Wed, 15 Apr 2009 06:55:44 +0000 "O. Hartmann" wrote: > Martin wrote: > > Am Tue, 14 Apr 2009 18:08:54 +0200 > > schrieb "O. Hartmann" : > > > >> [...] > > > > Hi, > > > > if you have problems with the radeonhd driver, you should tell the guys > > who work at it. They are really nice and try to help everywhere. > > > > Subscribe there: > > http://lists.opensuse.org/radeonhd/ > > > > I am only using radeonhd, because it works for me on all cards I have. > > > > I noticed that window movement may get choppy, when you compile a new > > kernel (DRM) and don't recompile a fresh radeonhd driver. This happens > > especially when DRI is enabled for your xorg server. > > > > -- > > Martin > > As far as I know, radeonhd from ports doesn't work with DRI enabled on > FreeBSD - so it doesn't work on my box either. I guess you're following > the recommendations using the development brnach directly from GIT. > Works for me on amd64 8-current. garyj:ernst:~:-bash:4> grep DRI /var/log/Xorg.0.log (II) Loading extension XFree86-DRI (II) Loading extension DRI2 (**) RADEONHD(0): Option "DRI" (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x024B4000 (size = 0x00B13000) (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x02FC7000 (size = 0x00B13000) (II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x03ADA000 (size = 0x0C400000) (II) RADEONHD(0): [DRI] installation complete (II) GLX: Initialized DRISWRAST GL provider for screen 0 garyj:ernst:~:-bash:5> ls -d /var/db/pkg/*radeon* drwxr-xr-x 2 root wheel 512 Apr 14 11:32 /var/db/pkg/xf86-video-radeonhd-devel-1.2.5.20090412 --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 09:44: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 15C231065670 for ; Wed, 15 Apr 2009 09:44:23 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 961F28FC12 for ; Wed, 15 Apr 2009 09:44:22 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Lu1fJ-0003cu-Ss>; Wed, 15 Apr 2009 11:44:21 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Lu1fJ-0004jg-Ra>; Wed, 15 Apr 2009 11:44:21 +0200 Message-ID: <49E5AC1F.1040808@zedat.fu-berlin.de> Date: Wed, 15 Apr 2009 09:42:55 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090414231839.46d634f2@zelda.local> <49E584F0.5030702@zedat.fu-berlin.de> <20090415113828.46075cdc@ernst.jennejohn.org> In-Reply-To: <20090415113828.46075cdc@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-current@freebsd.org, Martin Subject: Re: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 09:44:23 -0000 Gary Jennejohn wrote: > On Wed, 15 Apr 2009 06:55:44 +0000 > "O. Hartmann" wrote: > >> Martin wrote: >>> Am Tue, 14 Apr 2009 18:08:54 +0200 >>> schrieb "O. Hartmann" : >>> >>>> [...] >>> Hi, >>> >>> if you have problems with the radeonhd driver, you should tell the guys >>> who work at it. They are really nice and try to help everywhere. >>> >>> Subscribe there: >>> http://lists.opensuse.org/radeonhd/ >>> >>> I am only using radeonhd, because it works for me on all cards I have. >>> >>> I noticed that window movement may get choppy, when you compile a new >>> kernel (DRM) and don't recompile a fresh radeonhd driver. This happens >>> especially when DRI is enabled for your xorg server. >>> >>> -- >>> Martin >> As far as I know, radeonhd from ports doesn't work with DRI enabled on >> FreeBSD - so it doesn't work on my box either. I guess you're following >> the recommendations using the development brnach directly from GIT. >> > > Works for me on amd64 8-current. > > garyj:ernst:~:-bash:4> grep DRI /var/log/Xorg.0.log > (II) Loading extension XFree86-DRI > (II) Loading extension DRI2 > (**) RADEONHD(0): Option "DRI" > (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x024B4000 (size = 0x00B13000) > (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x02FC7000 (size = 0x00B13000) > (II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x03ADA000 (size = 0x0C400000) > (II) RADEONHD(0): [DRI] installation complete > (II) GLX: Initialized DRISWRAST GL provider for screen 0 > garyj:ernst:~:-bash:5> ls -d /var/db/pkg/*radeon* > drwxr-xr-x 2 root wheel 512 Apr 14 11:32 /var/db/pkg/xf86-video-radeonhd-devel-1.2.5.20090412 > > --- > Gary Jennejohn As I mentioned (but not very clear), I do not use the development radeonhd driver. So I will test this. Thanks. Oliver From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 10:09: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 ED74D106564A for ; Wed, 15 Apr 2009 10:09:26 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 7A1698FC08 for ; Wed, 15 Apr 2009 10:09:26 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Lu23Z-0000fR-Jy>; Wed, 15 Apr 2009 12:09:25 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Lu23Z-0006VG-IU>; Wed, 15 Apr 2009 12:09:25 +0200 Message-ID: <49E5B1FF.8090606@zedat.fu-berlin.de> Date: Wed, 15 Apr 2009 10:07:59 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090414231839.46d634f2@zelda.local> <49E584F0.5030702@zedat.fu-berlin.de> <20090415113828.46075cdc@ernst.jennejohn.org> In-Reply-To: <20090415113828.46075cdc@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-current@freebsd.org, Martin Subject: Re: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 10:09:27 -0000 Gary Jennejohn wrote: > On Wed, 15 Apr 2009 06:55:44 +0000 > "O. Hartmann" wrote: > >> Martin wrote: >>> Am Tue, 14 Apr 2009 18:08:54 +0200 >>> schrieb "O. Hartmann" : >>> >>>> [...] >>> Hi, >>> >>> if you have problems with the radeonhd driver, you should tell the guys >>> who work at it. They are really nice and try to help everywhere. >>> >>> Subscribe there: >>> http://lists.opensuse.org/radeonhd/ >>> >>> I am only using radeonhd, because it works for me on all cards I have. >>> >>> I noticed that window movement may get choppy, when you compile a new >>> kernel (DRM) and don't recompile a fresh radeonhd driver. This happens >>> especially when DRI is enabled for your xorg server. >>> >>> -- >>> Martin >> As far as I know, radeonhd from ports doesn't work with DRI enabled on >> FreeBSD - so it doesn't work on my box either. I guess you're following >> the recommendations using the development brnach directly from GIT. >> > > Works for me on amd64 8-current. > > garyj:ernst:~:-bash:4> grep DRI /var/log/Xorg.0.log > (II) Loading extension XFree86-DRI > (II) Loading extension DRI2 > (**) RADEONHD(0): Option "DRI" > (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x024B4000 (size = 0x00B13000) > (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x02FC7000 (size = 0x00B13000) > (II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x03ADA000 (size = 0x0C400000) > (II) RADEONHD(0): [DRI] installation complete > (II) GLX: Initialized DRISWRAST GL provider for screen 0 > garyj:ernst:~:-bash:5> ls -d /var/db/pkg/*radeon* > drwxr-xr-x 2 root wheel 512 Apr 14 11:32 /var/db/pkg/xf86-video-radeonhd-devel-1.2.5.20090412 > > Tried radeonhd-devel and failed also! When enabling DRI in config file, I see the XDM login box and the box crashes and freezes immediately. Without DRI radeonhd-devel is horrible slow when moving windows around - inacceptable. It doesn't matter whether EXA is enabled or not and the phenomenon ist the same as with the regular radeonhd-driver from xorg-drivers. I'm back with the VESA driver. From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 12:38: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 778F6106566C; Wed, 15 Apr 2009 12:38:52 +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 4741E8FC18; Wed, 15 Apr 2009 12:38:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id F29A146B96; Wed, 15 Apr 2009 08:38:51 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id AEA428A050; Wed, 15 Apr 2009 08:38:50 -0400 (EDT) From: John Baldwin To: Diego Depaoli Date: Wed, 15 Apr 2009 08:38:24 -0400 User-Agent: KMail/1.9.7 References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904142023.26679.jkim@FreeBSD.org> <83e5fb980904141755l3cf99fbdy75c2cdece4b25904@mail.gmail.com> In-Reply-To: <83e5fb980904141755l3cf99fbdy75c2cdece4b25904@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904150838.25099.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 15 Apr 2009 08:38:50 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=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, Jung-uk Kim Subject: Re: AMD 780G chipset major issues 3/3 (btx) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 12:38:52 -0000 On Tuesday 14 April 2009 8:55:01 pm Diego Depaoli wrote: > On Wed, Apr 15, 2009 at 2:23 AM, Jung-uk Kim wrote: > > > > That is embarrassing... =A0I thought I had the realmode boot block but I > > was wrong. =A0I had a screwed-up bsdlabel from sysinstall at some > > point. =A0When I did 'bsdlabel -B', it failed to install the boot block > > at all but I ignored the error message, I guess. :-( >=20 > Unfortunately that doesn't solve for me. > I have a drive (ad4, ad6) > - ad4s1 -> windows > - ad4s2 -> linux swap > - ad4s3 -> linux > - ad4s4 -> FreeBSD > bootloader is managed through EasyBCD > Not being an expert I gave > bsdlabel -B ad4s4 > (is the right command?) > but after that I get the same result >=20 > int=3D0000000d err=3D00000000 efl=3D00030002 eip=3D000001e8 > eax=3D00000010 ebx=3D00000002 ecx=3D00009e42 edx=3D0009e7c8 > esi=3D000003f0 edi=3D0000036e ebp=3D000003a8 esp=3D00000368 > cs=3Dcf00 ds=3D0040 es=3D1400 fs=3D0000 gs=3D0000 ss=3D9e42 > cs:eip=3D0f 22 c0 2e 0f 01 16 85-00 0f 20 c0 0c 01 0f 22 > c0 eb 00 b8 08 00 8e d8-8e c0 8e d0 66 2e a1 5c > ss:esp=3D3f 00 c0 96 00 00 00 14-40 00 46 00 02 00 00 00 > f0 03 00 00 a8 03 00 00-94 03 00 00 00 00 00 00 This fault is with the old boot blocks still. 'bsdlabel -B ad4s4' should=20 update the boot blocks correctly. I'm not sure why you are still getting t= he=20 old code. Perhaps /boot/boot has not been updated? =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 14:03: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 D2DA71065686 for ; Wed, 15 Apr 2009 14:03:13 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by mx1.freebsd.org (Postfix) with ESMTP id 686558FC21 for ; Wed, 15 Apr 2009 14:03:13 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.18] (helo=8.mx.freenet.de) by mout0.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #88) id 1Lu5ho-0003Ig-Op; Wed, 15 Apr 2009 16:03:12 +0200 Received: from tdba1.t.pppool.de ([89.55.219.161]:58765 helo=ernst.jennejohn.org) by 8.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1Lu5ho-0004R9-GF; Wed, 15 Apr 2009 16:03:12 +0200 Date: Wed, 15 Apr 2009 16:03:11 +0200 From: Gary Jennejohn To: "O. Hartmann" Message-ID: <20090415160311.2e898844@ernst.jennejohn.org> In-Reply-To: <49E5B1FF.8090606@zedat.fu-berlin.de> References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090414231839.46d634f2@zelda.local> <49E584F0.5030702@zedat.fu-berlin.de> <20090415113828.46075cdc@ernst.jennejohn.org> <49E5B1FF.8090606@zedat.fu-berlin.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Martin Subject: Re: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! 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, 15 Apr 2009 14:03:14 -0000 On Wed, 15 Apr 2009 10:07:59 +0000 "O. Hartmann" wrote: > Gary Jennejohn wrote: > > On Wed, 15 Apr 2009 06:55:44 +0000 > > "O. Hartmann" wrote: > > > >> Martin wrote: > >>> Am Tue, 14 Apr 2009 18:08:54 +0200 > >>> schrieb "O. Hartmann" : > >>> > >>>> [...] > >>> Hi, > >>> > >>> if you have problems with the radeonhd driver, you should tell the guys > >>> who work at it. They are really nice and try to help everywhere. > >>> > >>> Subscribe there: > >>> http://lists.opensuse.org/radeonhd/ > >>> > >>> I am only using radeonhd, because it works for me on all cards I have. > >>> > >>> I noticed that window movement may get choppy, when you compile a new > >>> kernel (DRM) and don't recompile a fresh radeonhd driver. This happens > >>> especially when DRI is enabled for your xorg server. > >>> > >>> -- > >>> Martin > >> As far as I know, radeonhd from ports doesn't work with DRI enabled on > >> FreeBSD - so it doesn't work on my box either. I guess you're following > >> the recommendations using the development brnach directly from GIT. > >> > > > > Works for me on amd64 8-current. > > > > garyj:ernst:~:-bash:4> grep DRI /var/log/Xorg.0.log > > (II) Loading extension XFree86-DRI > > (II) Loading extension DRI2 > > (**) RADEONHD(0): Option "DRI" > > (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x024B4000 (size = 0x00B13000) > > (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x02FC7000 (size = 0x00B13000) > > (II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x03ADA000 (size = 0x0C400000) > > (II) RADEONHD(0): [DRI] installation complete > > (II) GLX: Initialized DRISWRAST GL provider for screen 0 > > garyj:ernst:~:-bash:5> ls -d /var/db/pkg/*radeon* > > drwxr-xr-x 2 root wheel 512 Apr 14 11:32 /var/db/pkg/xf86-video-radeonhd-devel-1.2.5.20090412 > > > > > > Tried radeonhd-devel and failed also! > > When enabling DRI in config file, I see the XDM login box and the box > crashes and freezes immediately. Without DRI radeonhd-devel is horrible > slow when moving windows around - inacceptable. It doesn't matter > whether EXA is enabled or not and the phenomenon ist the same as with > the regular radeonhd-driver from xorg-drivers. > > I'm back with the VESA driver. Hmm. Are the drm and radeondrm in your kernel up-to-date? Your posting was chopped by the first replier and I can't remember. Can't think of anything else. I personally don't use xdm/gdm/kdm. I just use startx. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 14:25: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 EA0D91065697 for ; Wed, 15 Apr 2009 14:25:31 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 532CB8FC15 for ; Wed, 15 Apr 2009 14:25:31 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Lu63O-00050R-Ih>; Wed, 15 Apr 2009 16:25:30 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Lu63O-0005ru-G5>; Wed, 15 Apr 2009 16:25:30 +0200 Message-ID: <49E5EE04.1050208@zedat.fu-berlin.de> Date: Wed, 15 Apr 2009 14:24:04 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090414231839.46d634f2@zelda.local> <49E584F0.5030702@zedat.fu-berlin.de> <20090415113828.46075cdc@ernst.jennejohn.org> <49E5B1FF.8090606@zedat.fu-berlin.de> <20090415160311.2e898844@ernst.jennejohn.org> In-Reply-To: <20090415160311.2e898844@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-current@freebsd.org, Martin Subject: Re: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 14:25:34 -0000 Gary Jennejohn wrote: > On Wed, 15 Apr 2009 10:07:59 +0000 > "O. Hartmann" wrote: > >> Gary Jennejohn wrote: >>> On Wed, 15 Apr 2009 06:55:44 +0000 >>> "O. Hartmann" wrote: >>> >>>> Martin wrote: >>>>> Am Tue, 14 Apr 2009 18:08:54 +0200 >>>>> schrieb "O. Hartmann" : >>>>> >>>>>> [...] >>>>> Hi, >>>>> >>>>> if you have problems with the radeonhd driver, you should tell the guys >>>>> who work at it. They are really nice and try to help everywhere. >>>>> >>>>> Subscribe there: >>>>> http://lists.opensuse.org/radeonhd/ >>>>> >>>>> I am only using radeonhd, because it works for me on all cards I have. >>>>> >>>>> I noticed that window movement may get choppy, when you compile a new >>>>> kernel (DRM) and don't recompile a fresh radeonhd driver. This happens >>>>> especially when DRI is enabled for your xorg server. >>>>> >>>>> -- >>>>> Martin >>>> As far as I know, radeonhd from ports doesn't work with DRI enabled on >>>> FreeBSD - so it doesn't work on my box either. I guess you're following >>>> the recommendations using the development brnach directly from GIT. >>>> >>> Works for me on amd64 8-current. >>> >>> garyj:ernst:~:-bash:4> grep DRI /var/log/Xorg.0.log >>> (II) Loading extension XFree86-DRI >>> (II) Loading extension DRI2 >>> (**) RADEONHD(0): Option "DRI" >>> (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x024B4000 (size = 0x00B13000) >>> (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x02FC7000 (size = 0x00B13000) >>> (II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x03ADA000 (size = 0x0C400000) >>> (II) RADEONHD(0): [DRI] installation complete >>> (II) GLX: Initialized DRISWRAST GL provider for screen 0 >>> garyj:ernst:~:-bash:5> ls -d /var/db/pkg/*radeon* >>> drwxr-xr-x 2 root wheel 512 Apr 14 11:32 /var/db/pkg/xf86-video-radeonhd-devel-1.2.5.20090412 >>> >>> >> Tried radeonhd-devel and failed also! >> >> When enabling DRI in config file, I see the XDM login box and the box >> crashes and freezes immediately. Without DRI radeonhd-devel is horrible >> slow when moving windows around - inacceptable. It doesn't matter >> whether EXA is enabled or not and the phenomenon ist the same as with >> the regular radeonhd-driver from xorg-drivers. >> >> I'm back with the VESA driver. > > Hmm. Are the drm and radeondrm in your kernel up-to-date? Your posting > was chopped by the first replier and I can't remember. > > Can't think of anything else. > > I personally don't use xdm/gdm/kdm. I just use startx. > > --- > Gary Jennejohn The kernel modules 'radeon' and 'drm' are loaded via /boot/loader.conf when booting and they are up to date (I do a buildworld on a regular basis these days and it takes ~30 minutes for a quad core box). Even when not starting X via xdm, the box crashes immediately, freezes and is only 'revivable' by cold resetting. This happens with driver radeonhd and enabled DRI. Without DRI the radeonhd driver works, but moving a window looks like on Windooze when using standard VGA driver without acceleration (this is bot with EXA on or off) - scrolling and moving objects is really choppy. 'radeon' doesn't even show up anything, freezes the box as well as 'radeonhd', but no matter whether DRI enabled or not. At home I will test radeonhd-devel with the RV770LE chipset (here I have only RV730). The RV770LE seems not to be recognized by 'radeonhd', but works fine with 'radeon'. But in both cases, DRI enabled crashes the box. From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 16:02:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA9481065670 for ; Wed, 15 Apr 2009 16:02:11 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 06FE28FC17 for ; Wed, 15 Apr 2009 16:02:10 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by ewy19 with SMTP id 19so3162961ewy.43 for ; Wed, 15 Apr 2009 09:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KxtbDSbToybYHvafdtuv/6MpAUJTGqzOFhsV2ae8efI=; b=gGdm7+2lL/+XtoIesciwWzyPv0r2QW4m9Ru3vAF+7zXIiM8fhAR+/HEzDroesaxDfd nWSCB6rVI6/RWJh4IwyPpoMHxw+bB2g7vSXoCLXN//GKq/ceWxkv4NB2UYW/pSosJCq3 hqh2zL/oDbhTevmJYVTyAkS+z0KKnpXvQwt+s= 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=wV5zPZ75gPRI6MOfnKEBbp/c5tF3rQqG1h4j4ZMYL0eyQXoyeFusvasV7bw+jI8m/o zy2My1y1WfdRMNCVo7t0+k0B4+cWmvK1eQVVHm/KOf3DfvNEG3eJrd0EMp2247SytyEw 52I0L6tFIYdw7Tqs+Zc0p/fBu7/3sIjs7dcOk= MIME-Version: 1.0 Received: by 10.210.128.10 with SMTP id a10mr425421ebd.15.1239810112400; Wed, 15 Apr 2009 08:41:52 -0700 (PDT) In-Reply-To: <49E5EE04.1050208@zedat.fu-berlin.de> References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090414231839.46d634f2@zelda.local> <49E584F0.5030702@zedat.fu-berlin.de> <20090415113828.46075cdc@ernst.jennejohn.org> <49E5B1FF.8090606@zedat.fu-berlin.de> <20090415160311.2e898844@ernst.jennejohn.org> <49E5EE04.1050208@zedat.fu-berlin.de> Date: Wed, 15 Apr 2009 11:41:52 -0400 Message-ID: <5f67a8c40904150841h3398e86tafe7b8b442bffafd@mail.gmail.com> From: Zaphod Beeblebrox To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Martin Subject: Re: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 16:02:12 -0000 2009/4/15 O. Hartmann > > The kernel modules 'radeon' and 'drm' are loaded via /boot/loader.conf when > booting and they are up to date (I do a buildworld on a regular basis these > days and it takes ~30 minutes for a quad core box). > > Even when not starting X via xdm, the box crashes immediately, freezes and > is only 'revivable' by cold resetting. This happens with driver radeonhd and > enabled DRI. Without DRI the radeonhd driver works, but moving a window > looks like on Windooze when using standard VGA driver without acceleration > (this is bot with EXA on or off) - scrolling and moving objects is really > choppy. > > 'radeon' doesn't even show up anything, freezes the box as well as > 'radeonhd', but no matter whether DRI enabled or not. > > At home I will test radeonhd-devel with the RV770LE chipset (here I have > only RV730). The RV770LE seems not to be recognized by 'radeonhd', but works > fine with 'radeon'. But in both cases, DRI enabled crashes the box. Here, I have radeonhd loaded (the -devel doesn't seem to be that different a version). I have the radeon and drm kernel modules loaded. My only problem was that I had no input devices (which seems a really dumb default). My card is a Saphire 4870 --- which I believe is a RV770 based card. From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 18:46: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 4E299106564A for ; Wed, 15 Apr 2009 18:46:44 +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 161A68FC16 for ; Wed, 15 Apr 2009 18:46:44 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-210-55.bna.bellsouth.net [65.1.210.55]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3FIkblq014129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 14:46:38 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Cy Schubert In-Reply-To: <200904150013.n3F0D7XW004721@cwsys.cwsent.com> References: <200904150013.n3F0D7XW004721@cwsys.cwsent.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-VMAOYuZAE4VelOpL8ZLv" Organization: FreeBSD Date: Wed, 15 Apr 2009 13:45:35 -0500 Message-Id: <1239821135.2194.6.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@FreeBSD.org Subject: Re: GDM Hanging Machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 18:46:44 -0000 --=-VMAOYuZAE4VelOpL8ZLv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-04-14 at 17:13 -0700, Cy Schubert wrote: > I thought to post this here before spending a lot of time on this. I have= a=20 > laptop which normally boots 7.2-PRERELEASE however I do have CURRENT on a= =20 > USB drive where I'm working on some USB floppy drive code. When GDM start= s=20 > the whole system hangs. Before digging into this too deeply myself, has=20 > anyone seen this before and is there a quick fix? The ports collection on= =20 > that drive was built on a 7.2 system and copied to the CURRENT system. Th= is=20 > may in fact be the root cause and if so the fix is a no brainer. Does it hang after you attempt to login? If so, rebuild/reinstall fusefs-kmod. Marcus and I were both having an issue with that. robert. --=20 Robert Noland FreeBSD --=-VMAOYuZAE4VelOpL8ZLv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknmK08ACgkQM4TrQ4qfROPfHwCfQdaWN2+/xQqxbkSPAaueGK3l jtIAn0grqp6YxcRWAZI+zvZPag0e1uyk =Pw4o -----END PGP SIGNATURE----- --=-VMAOYuZAE4VelOpL8ZLv-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 19:55:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 362421065703 for ; Wed, 15 Apr 2009 19:55:42 +0000 (UTC) (envelope-from marcus@freebsd.org) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by mx1.freebsd.org (Postfix) with ESMTP id EF6548FC21 for ; Wed, 15 Apr 2009 19:55:41 +0000 (UTC) (envelope-from marcus@freebsd.org) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n3FJYmWB010655; Wed, 15 Apr 2009 15:34:48 -0400 (EDT) Received: from [64.102.220.171] (dhcp-64-102-220-171.cisco.com [64.102.220.171]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n3FJYmCw024736; Wed, 15 Apr 2009 15:34:48 -0400 (EDT) Message-ID: <49E636DA.7050304@freebsd.org> Date: Wed, 15 Apr 2009 15:34:50 -0400 From: Joe Marcus Clarke Organization: FreeBSD, Inc. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Cy Schubert References: <200904150013.n3F0D7XW004721@cwsys.cwsent.com> In-Reply-To: <200904150013.n3F0D7XW004721@cwsys.cwsent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: GDM Hanging Machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 19:55:44 -0000 Cy Schubert wrote: > I thought to post this here before spending a lot of time on this. I have a > laptop which normally boots 7.2-PRERELEASE however I do have CURRENT on a > USB drive where I'm working on some USB floppy drive code. When GDM starts > the whole system hangs. Before digging into this too deeply myself, has > anyone seen this before and is there a quick fix? The ports collection on > that drive was built on a 7.2 system and copied to the CURRENT system. This > may in fact be the root cause and if so the fix is a no brainer. I believe this is the case. A hal built in 7.X will not work properly in 8.X. It is very kernel-specific. Joe > > -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 19:57: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 ADB9C10656BE; Wed, 15 Apr 2009 19:57:46 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id D03568FC16; Wed, 15 Apr 2009 19:57:45 +0000 (UTC) (envelope-from mister.olli@googlemail.com) Received: by bwz8 with SMTP id 8so58957bwz.43 for ; Wed, 15 Apr 2009 12:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:reply-to:to:cc :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=fHmx6bbH0srwZ0EpDxbDjTWIbVJVeMZguGmS8SqF5Xw=; b=JX/fHMSBFItq3V0SCaWTAr8fZfJxRgN8ZmaFZbQU2cJJnwlGnPo44/c20VA7gEkNdW dqmsbXz5F5zwfhjiZrfmuAzWEPiKE8m9J4do6Y6+oKy9ybUWd2Ac+FY3NTaz33ePskYi qHR9ouaHyxmizRVxXNAb0oHkAhqMC8iZikpFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:reply-to:to:cc:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; b=q6OiPL73zupvAUOF+n2A9QMgV4RnXn+mQAo/g0BdYEVzbFyZZnr7z/ZVYuAHgvXjaw rjg5tPShhOO9e66H8wGqQZkwZmaOHAmAmgsMGuQxztSsfpx61hiUcw1PhHuy35xu1Z60 5+9tCARovW8oYcIqfgbSkWGVzLlJdfWFaaF1A= Received: by 10.103.227.13 with SMTP id e13mr361209mur.20.1239825464633; Wed, 15 Apr 2009 12:57:44 -0700 (PDT) Received: from ?78.92.244.96? (dsl4E5CF460.pool.t-online.hu [78.92.244.96]) by mx.google.com with ESMTPS id 23sm381142mun.0.2009.04.15.12.57.42 (version=SSLv3 cipher=RC4-MD5); Wed, 15 Apr 2009 12:57:44 -0700 (PDT) From: Mister Olli To: freebsd-current@FreeBSD.org Content-Type: text/plain Date: Wed, 15 Apr 2009 19:57:38 +0000 Message-Id: <1239825458.23277.13.camel@phoenix.blechhirn.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 Content-Transfer-Encoding: 7bit Cc: freebsd-xen@freebsd.org Subject: Page fault with r191077 as xen PV X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mister.olli@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 19:57:47 -0000 hi. I just build a XEN pv kernel, based on svn revision 191077. When booting the kernel stops with a page-fault. ===================================================== virt-001 template_8-CURRENT # xm create -c 00_template_8-CURRENT.XENconfig Using config file "./00_template_8-CURRENT.XENconfig". Started domain template_8-CURRENT WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #2 r191077M: Wed Apr 15 21:46:50 CEST 2009 root@template-8_CURRENT.blechhirn.net:/usr/obj/usr/src/sys/freebsd8_WITHOUT_WITNESS WARNING: WITNESS option enabled, expect reduced performance. Xen reported: 1600.059 MHz processor. Timecounter "ixen" frequency 1000000000 Hz quality 0 CPU: AMD Athlon(tm) MP 1900+ (1600.06-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc0480800 real memory = 536870912 (512 MB) avail memory = 517857280 (493 MB) cpu=0 irq=0 vector=0 cpu=0 irq=0 vector=1 kbd0 at kbdmux0 xenbus0: on motherboard xc0: on motherboard Timecounters tick every 100.000 msec Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x21:0x0 stack pointer = 0x29:0xc21a9cdc frame pointer = 0x29:0xc21a9cf8 code segment = base 0x0, limit 0xf67ff, type 0x1b = DPL 1, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 14 (xenwatch) [thread pid 14 tid 100017 ] Stopped at 0: *** error reading from address 0 *** db> xccncheckc:155 bxccncheckc:155 txccncheckc:155 Tracing pid 14 tid 100017 td 0xc22d9230 _end(0,c21a9d38,c0254672,32d,c23272a4,...) at 0xc2346a00 fork_exit(c01fccd0,0,c21a9d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc21a9d70, ebp = 0 --- db> ========================= The output of 'bt' from the debugger is included. Regards, Olli From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 22:04: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 E1122106566C for ; Wed, 15 Apr 2009 22:04:48 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 920848FC14 for ; Wed, 15 Apr 2009 22:04:48 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LuDDq-0005t6-2Q for freebsd-current@freebsd.org; Wed, 15 Apr 2009 22:04:46 +0000 Received: from 78-1-130-68.adsl.net.t-com.hr ([78.1.130.68]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Apr 2009 22:04:46 +0000 Received: from ivoras by 78-1-130-68.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Apr 2009 22:04:46 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 16 Apr 2009 00:03:42 +0200 Lines: 32 Message-ID: References: <49E41A2F.9080105@lissyara.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA9C373DCE6EB9DB2A2377A19" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-130-68.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <49E41A2F.9080105@lissyara.su> X-Enigmail-Version: 0.95.7 Sender: news Subject: Re: NMI ISA 2c, EISA ff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 22:04:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA9C373DCE6EB9DB2A2377A19 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alex Keda wrote: > I try install FreBSD; boot from USB hard drive on HP 2133 (laptop) > Boot not success: >=20 > agp0: on host0 > agp0: aperture size is 128M > NMI ISA 2c, EISA ff NMIs are most commonly caused by memory errors (but could be other types of hardware errors). --------------enigA9C373DCE6EB9DB2A2377A19 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 iEYEARECAAYFAknmWb4ACgkQldnAQVacBciJTwCgsROVx5NbjS9D0cWxey4h7vJR GNMAn2SwBl9Rqal+PAYKNTpOL1zZyVAD =0YjI -----END PGP SIGNATURE----- --------------enigA9C373DCE6EB9DB2A2377A19-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 23:27:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5A96106564A; Wed, 15 Apr 2009 23:27:53 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id D05128FC08; Wed, 15 Apr 2009 23:27:52 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: by bwz8 with SMTP id 8so130834bwz.43 for ; Wed, 15 Apr 2009 16:27:51 -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=upOLNT1jczxA29MOLW0JJPsf36R8bVvnsc+M77ktGcE=; b=bYe8yd5N/zkNOzSUImAUzWlUrR+v49P5zUlnOO64UsVmnLLuIBh13tlxDR5qj7q6z9 iQl7Eyyqc2xDTcxHkpgvxl1Rn8AzGxpWG/rtJ2p+fCSukPnCJuWy3kIJhKHlcC8+dgpG o0U1R2GhG+bdS9BIu28fMLlqIySwN8FOR/MYw= 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=b/S4fC4ZrClcoL7btldeB8vvpa2g14WafZtYUbWHdof1B4UiZBjtBLc8qguDt1tq4C kcutmI73guEaBxi4tyXC5HiGgzvEJ664lQQSxvCj897ORsLsrFE7sXsSH90OHd1HM4ZY QfG6Yq2IQhCm9BuniVkl5op+4KJbpA6mLOHhU= MIME-Version: 1.0 Received: by 10.223.115.12 with SMTP id g12mr232569faq.92.1239838071540; Wed, 15 Apr 2009 16:27:51 -0700 (PDT) In-Reply-To: <200904150838.25099.jhb@freebsd.org> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904142023.26679.jkim@FreeBSD.org> <83e5fb980904141755l3cf99fbdy75c2cdece4b25904@mail.gmail.com> <200904150838.25099.jhb@freebsd.org> Date: Thu, 16 Apr 2009 01:27:51 +0200 Message-ID: <83e5fb980904151627k726294deoe8feba8c0b7d5167@mail.gmail.com> From: Diego Depaoli To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: AMD 780G chipset major issues 3/3 (btx) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 23:27:54 -0000 On Wed, Apr 15, 2009 at 2:38 PM, John Baldwin wrote: > > This fault is with the old boot blocks still. 'bsdlabel -B ad4s4' should > update the boot blocks correctly. I'm not sure why you are still getting the > old code. Perhaps /boot/boot has not been updated? I remaked world/kernel. Almost all files in /boot have same date/time. That's the output of bsdlabel -B ad4s4 partition a: offset past end of unit partition a: partition extends past end of unit partition b: offset past end of unit partition b: partition extends past end of unit partition c: offset past end of unit partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition d: offset past end of unit partition d: partition extends past end of unit partition e: offset past end of unit partition e: partition extends past end of unit partition f: offset past end of unit partition f: partition extends past end of unit After reboot I get BTX halted. Perhaps bsdlabel -B works only upon a slice with 0X80 flag set? Otherwise I don't know... Cheers -- Diego Depaoli From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 23:43:59 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 0A609106566B; Wed, 15 Apr 2009 23:43:59 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Diego Depaoli Date: Wed, 15 Apr 2009 19:43:47 -0400 User-Agent: KMail/1.6.2 References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904150838.25099.jhb@freebsd.org> <83e5fb980904151627k726294deoe8feba8c0b7d5167@mail.gmail.com> In-Reply-To: <83e5fb980904151627k726294deoe8feba8c0b7d5167@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200904151943.51066.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: AMD 780G chipset major issues 3/3 (btx) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 23:43:59 -0000 On Wednesday 15 April 2009 07:27 pm, Diego Depaoli wrote: > On Wed, Apr 15, 2009 at 2:38 PM, John Baldwin wrote: > > This fault is with the old boot blocks still. 'bsdlabel -B > > ad4s4' should update the boot blocks correctly. I'm not sure why > > you are still getting the old code. Perhaps /boot/boot has not > > been updated? > > I remaked world/kernel. Almost all files in /boot have same > date/time. That's the output of bsdlabel -B ad4s4 > partition a: offset past end of unit > partition a: partition extends past end of unit > partition b: offset past end of unit > partition b: partition extends past end of unit > partition c: offset past end of unit > partition c: partition extends past end of unit > bsdlabel: partition c doesn't start at 0! > bsdlabel: An incorrect partition c may cause problems for standard > system utilities > partition d: offset past end of unit > partition d: partition extends past end of unit > partition e: offset past end of unit > partition e: partition extends past end of unit > partition f: offset past end of unit > partition f: partition extends past end of unit > > After reboot I get BTX halted. > Perhaps bsdlabel -B works only upon a slice with 0X80 flag set? > Otherwise I don't know... It only works when there is no error. ;-) It seems you have to fix the label first. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Apr 15 23:48:27 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 7FBDA106567A; Wed, 15 Apr 2009 23:48:26 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Diego Depaoli Date: Wed, 15 Apr 2009 19:48:13 -0400 User-Agent: KMail/1.6.2 References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <83e5fb980904151627k726294deoe8feba8c0b7d5167@mail.gmail.com> <200904151943.51066.jkim@FreeBSD.org> In-Reply-To: <200904151943.51066.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200904151948.18083.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: AMD 780G chipset major issues 3/3 (btx) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Apr 2009 23:48:27 -0000 On Wednesday 15 April 2009 07:43 pm, Jung-uk Kim wrote: > On Wednesday 15 April 2009 07:27 pm, Diego Depaoli wrote: > > On Wed, Apr 15, 2009 at 2:38 PM, John Baldwin > > wrote: > > > This fault is with the old boot blocks still. 'bsdlabel -B > > > ad4s4' should update the boot blocks correctly. I'm not sure > > > why you are still getting the old code. Perhaps /boot/boot has > > > not been updated? > > > > I remaked world/kernel. Almost all files in /boot have same > > date/time. That's the output of bsdlabel -B ad4s4 > > partition a: offset past end of unit > > partition a: partition extends past end of unit > > partition b: offset past end of unit > > partition b: partition extends past end of unit > > partition c: offset past end of unit > > partition c: partition extends past end of unit > > bsdlabel: partition c doesn't start at 0! > > bsdlabel: An incorrect partition c may cause problems for > > standard system utilities > > partition d: offset past end of unit > > partition d: partition extends past end of unit > > partition e: offset past end of unit > > partition e: partition extends past end of unit > > partition f: offset past end of unit > > partition f: partition extends past end of unit > > > > After reboot I get BTX halted. > > Perhaps bsdlabel -B works only upon a slice with 0X80 flag set? > > Otherwise I don't know... > > It only works when there is no error. ;-) It seems you have to fix > the label first. Probably MBR, too. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 00:17: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 2F4D1106566B for ; Thu, 16 Apr 2009 00:17:21 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.217.172]) by mx1.freebsd.org (Postfix) with ESMTP id DDDA58FC14 for ; Thu, 16 Apr 2009 00:17:20 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk20 with SMTP id 20so543731gxk.19 for ; Wed, 15 Apr 2009 17:17:20 -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=mU+24KxbSHh43Tv3csgWhAGvMiTaHtxRfbB9Hpt5Owg=; b=sm/4uQNS3YOufTflmJjTe1HM0crTlipoxNdXTM2+/wrO0UrXPgDcRsRlTjHn9pmcGR IdH1bo72eY7O/xvDyIocY+ZMfZRErLjZGUj8GHqAj0jBktugcZrMmiRok8bq+WcLfhlf FWa0XF79i351M1dUnQsshaEU35RfspuICIekM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TKNHLZBVn2cO/V8g6Hopq1lPxGMNrpuINsapRMImfx/dsmzthNnaq+29YaWhaJNWr7 oncFblvJo+Lk9AkDUW6C7Krx/urnJqm8ETifPdeOMMNTsvK7qwlTxPPLbbs/CyRyQajb it9sbe7Q62X4F7FwakR1e0V902fIKjG2WvW8I= MIME-Version: 1.0 Received: by 10.90.105.17 with SMTP id d17mr916633agc.68.1239841040346; Wed, 15 Apr 2009 17:17:20 -0700 (PDT) Date: Wed, 15 Apr 2009 17:17:20 -0700 Message-ID: From: Maksim Yevmenkin To: FreeBSD Current Content-Type: multipart/mixed; boundary=0016e64f4a68c9b04f0467a0fcf0 Subject: [patch] prevent atkbd(4) from calling callback in polled 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: Thu, 16 Apr 2009 00:17:21 -0000 --0016e64f4a68c9b04f0467a0fcf0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hello, would anyone object to the small attached atkbd(4) patch? the idea is to basically prevent atkbd(4) interrupt handler from calling keyboard callback function when polled mode is enabled. i would really like to hear from people who is using kbdmux(4) on smp systems and having problems with duplicated/missing characters while using keyboard at mountroot, geli, etc. prompts. basically, when low level console input functions (cngetc(), gets(), etc.) are used _and_ interrupts are enabled. thanks, max --0016e64f4a68c9b04f0467a0fcf0 Content-Type: text/plain; charset=US-ASCII; name="atkbd.c.diff.txt" Content-Disposition: attachment; filename="atkbd.c.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ftkp63940 SW5kZXg6IGF0a2JkLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gYXRrYmQuYwkocmV2aXNpb24gMTkxMDEyKQor KysgYXRrYmQuYwkod29ya2luZyBjb3B5KQpAQCAtNDc2LDcgKzQ3Niw3IEBACiBzdGF0aWMgaW50 CiBhdGtiZF9pbnRyKGtleWJvYXJkX3QgKmtiZCwgdm9pZCAqYXJnKQogewotCWF0a2JkX3N0YXRl X3QgKnN0YXRlOworCWF0a2JkX3N0YXRlX3QgKnN0YXRlID0gKGF0a2JkX3N0YXRlX3QgKilrYmQt PmtiX2RhdGE7CiAJaW50IGRlbGF5WzJdOwogCWludCBjOwogCkBAIC00ODUsNyArNDg1LDYgQEAK IAkJICogVGhlIGtleWJvYXJkIHdhcyBub3QgZGV0ZWN0ZWQgYmVmb3JlOwogCQkgKiBpdCBtdXN0 IGhhdmUgYmVlbiByZWNvbm5lY3RlZCEKIAkJICovCi0JCXN0YXRlID0gKGF0a2JkX3N0YXRlX3Qg KilrYmQtPmtiX2RhdGE7CiAJCWluaXRfa2V5Ym9hcmQoc3RhdGUtPmtiZGMsICZrYmQtPmtiX3R5 cGUsCiAJCQkgICAgICBrYmQtPmtiX2NvbmZpZyk7CiAJCUtCRF9GT1VORF9ERVZJQ0Uoa2JkKTsK QEAgLTQ5Niw2ICs0OTUsOSBAQAogCQlhdGtiZF9pb2N0bChrYmQsIEtEU0VUUkVQRUFULCAoY2Fk ZHJfdClkZWxheSk7CiAJfQogCisJaWYgKHN0YXRlLT5rc19wb2xsaW5nKQorCQlyZXR1cm4gMDsK KwogCWlmIChLQkRfSVNfQUNUSVZFKGtiZCkgJiYgS0JEX0lTX0JVU1koa2JkKSkgewogCQkvKiBs ZXQgdGhlIGNhbGxiYWNrIGZ1bmN0aW9uIHRvIHByb2Nlc3MgdGhlIGlucHV0ICovCiAJCSgqa2Jk LT5rYl9jYWxsYmFjay5rY19mdW5jKShrYmQsIEtCRElPX0tFWUlOUFVULAo= --0016e64f4a68c9b04f0467a0fcf0-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 00:22: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 BCE3B1065672; Thu, 16 Apr 2009 00:22:06 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id E87038FC0A; Thu, 16 Apr 2009 00:22:05 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: by bwz8 with SMTP id 8so143752bwz.43 for ; Wed, 15 Apr 2009 17:22: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 :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hZ8IpXgGiRqL9FkVvKEmX/8Lzmf2KaccY6Z9k0PRMek=; b=RkyDGcV5X8HHLatveMQDtHvkwInpbKGXJNHWcB1uUmeT85SebaWJdTGpsoTId7EWZJ fTBPi2gqb7AYaw9FLYFvG6DdPQDIB77S2iGRLtC1nzsO/x/1jEHotAwrfbHU/zOGYjp3 GXXPG5AKUgdNLwDCHrRQEezCUH4VqN/2qaTqI= 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=lYDJVLmu6rfSs5V8dN6RKBGTwnAKIHIJF1UeQsTkIKfihresAkZhR9RUbkcpa7KFuK 9GNrBJAdfTYBT6J+9ZWKgx6SK3X4WbE0ygsYONhisOTs2qTx2mLI+0WM2nmRNV9IlK9b 3n/txsgvbhUhc6St5f5a1xOl5TKjVFPZhUXiA= MIME-Version: 1.0 Received: by 10.223.111.134 with SMTP id s6mr249652fap.37.1239841324878; Wed, 15 Apr 2009 17:22:04 -0700 (PDT) In-Reply-To: <200904151943.51066.jkim@FreeBSD.org> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904150838.25099.jhb@freebsd.org> <83e5fb980904151627k726294deoe8feba8c0b7d5167@mail.gmail.com> <200904151943.51066.jkim@FreeBSD.org> Date: Thu, 16 Apr 2009 02:22:04 +0200 Message-ID: <83e5fb980904151722p17d4210dqeca1c137683eebb0@mail.gmail.com> From: Diego Depaoli To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: AMD 780G chipset major issues 3/3 (btx) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 00:22:07 -0000 On Thu, Apr 16, 2009 at 1:43 AM, Jung-uk Kim wrote: >> After reboot I get BTX halted. >> Perhaps bsdlabel -B works only upon a slice with 0X80 flag set? >> Otherwise I don't know... > > It only works when there is no error. ;-) It seems you have to fix the > label first. Starting from this... can be done without loosing data? -- Diego Depaoli From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 01:40:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EFC21065677; Thu, 16 Apr 2009 01:40:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED378FC13; Thu, 16 Apr 2009 01:40:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3G1e47c064319; Wed, 15 Apr 2009 21:40:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3G1e4AZ066250; Wed, 15 Apr 2009 21:40:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 51FBC7302F; Wed, 15 Apr 2009 21:40:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090416014004.51FBC7302F@freebsd-current.sentex.ca> Date: Wed, 15 Apr 2009 21:40:04 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on 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, 16 Apr 2009 01:40:09 -0000 TB --- 2009-04-16 00:15:47 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-16 00:15:47 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-04-16 00:15:47 - cleaning the object tree TB --- 2009-04-16 00:16:09 - cvsupping the source tree TB --- 2009-04-16 00:16:09 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-04-16 00:16:20 - building world TB --- 2009-04-16 00:16:20 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-16 00:16:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-16 00:16:20 - TARGET=sun4v TB --- 2009-04-16 00:16:20 - TARGET_ARCH=sparc64 TB --- 2009-04-16 00:16:20 - TZ=UTC TB --- 2009-04-16 00:16:20 - __MAKE_CONF=/dev/null TB --- 2009-04-16 00:16:20 - cd /src TB --- 2009-04-16 00:16:20 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 16 00:16:21 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 Apr 16 01:31:14 UTC 2009 TB --- 2009-04-16 01:31:14 - generating LINT kernel config TB --- 2009-04-16 01:31:14 - cd /src/sys/sun4v/conf TB --- 2009-04-16 01:31:14 - /usr/bin/make -B LINT TB --- 2009-04-16 01:31:14 - building LINT kernel TB --- 2009-04-16 01:31:14 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-16 01:31:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-16 01:31:14 - TARGET=sun4v TB --- 2009-04-16 01:31:14 - TARGET_ARCH=sparc64 TB --- 2009-04-16 01:31:14 - TZ=UTC TB --- 2009-04-16 01:31:14 - __MAKE_CONF=/dev/null TB --- 2009-04-16 01:31:14 - cd /src TB --- 2009-04-16 01:31:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 16 01:31:14 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/geom/part/g_part.c awk -f /src/sys/tools/makeobjops.awk /src/sys/geom/part/g_part_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 g_part_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/geom/part/g_part_apm.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/geom/part/g_part_bsd.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/geom/part/g_part_ebr.c cc1: warnings being treated as errors /src/sys/geom/part/g_part_ebr.c: In function 'g_part_ebr_fullname': /src/sys/geom/part/g_part_ebr.c:327: warning: field precision should have type 'int', but argument 3 has type 'size_t' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-16 01:40:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-16 01:40:04 - ERROR: failed to build lint kernel TB --- 2009-04-16 01:40:04 - 4284.61 user 412.72 system 5056.77 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 02:54: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 B4F50106564A for ; Thu, 16 Apr 2009 02:54:37 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 714DB8FC08 for ; Thu, 16 Apr 2009 02:54:37 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n3G2sN1M044379 for ; Wed, 15 Apr 2009 21:54:23 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=CPudSU6KGg7mxAUETP38U9taE7PX/BIA/9ePgXEfagHO+gx/nhBjhyd7iCuIXaoLS OyFSE+Nb/3bdheYcir1EF/xdmPq+3sEfmPMYCxEkvdM179sbH/jpgKJUsS1x4ra5zLj BWjXOg4nHBSC8h9QzMMHUbTzYNPP1pr9ZlafsJM= Message-ID: <49E69DDF.3080104@jrv.org> Date: Wed, 15 Apr 2009 21:54:23 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <49E1819B.7000604@jrv.org> In-Reply-To: <49E1819B.7000604@jrv.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: can't boot 5.5 TB GPT disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 02:54:38 -0000 James R. Van Artsdalen wrote: > I can't boot a GPT partitioned 5.5 TB disc, where the UFS root partition > is near the end of the disk. For the record this fixes the bug. PR to be filed. Index: sys/boot/i386/libi386/biosdisk.c =================================================================== --- sys/boot/i386/libi386/biosdisk.c (revision 190917) +++ sys/boot/i386/libi386/biosdisk.c (working copy) @@ -83,7 +83,7 @@ int od_cyl; /* BIOS geometry */ int od_hds; int od_sec; - int od_boff; /* block offset from beginning of BIOS disk */ + daddr_t od_boff; /* block offset from beginning of BIOS disk */ int od_flags; #define BD_MODEINT13 0x0000 #define BD_MODEEDD1 0x0001 From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 03:01: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 87307106568F for ; Thu, 16 Apr 2009 03:01:30 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 37CAE8FC33 for ; Thu, 16 Apr 2009 03:01:29 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n3G31GKa044450 for ; Wed, 15 Apr 2009 22:01:16 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=v17W8r090OCrQYbeUVVzhVoNtEErw3/OrF/ZqIyDeQ6sklA/5s1TZc7lMcB3O1vmj /HEKiWF9kXCFA0dgrupVRggG6MDyx3TDL5XqnIbGndIbtnSoIhoClO3uyMGl4vGz3TV EZvlQ3qlFkfxQVmcKlKfgbOJaxtoidcI5e6xQwQ= Message-ID: <49E69F7C.9020402@jrv.org> Date: Wed, 15 Apr 2009 22:01:16 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <49E4CED7.2040206@jrv.org> In-Reply-To: <49E4CED7.2040206@jrv.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: ata FLUSHCACHE timeout errors? [patch] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 03:01:30 -0000 James R. Van Artsdalen wrote: > I am getting many FLUSHCACHE timeout errors during "zfs recv" operations. This patch fixes this. PR to be filed. In addition this causes any ata request that times out to print the timeout, since it's going to be the timeout itself that's likely wrong. A five-second timeout is used in the ATA code unless the disk is known to be spun down. This is almost certainly wrong as the ATA spec allows devices to take up to 30 seconds. Nonetheless I only changed the FLUSHCACHE case that was failing. Index: sys/dev/ata/ata-queue.c =================================================================== --- sys/dev/ata/ata-queue.c (revision 190917) +++ sys/dev/ata/ata-queue.c (working copy) @@ -134,6 +134,8 @@ device_printf(dev, "request while spun down, starting.\n"); atadev->spindown_state = 0; request->timeout = 31; + } else if (command == ATA_FLUSHCACHE || command == ATA_FLUSHCACHE48) { + request->timeout = 31; } else { request->timeout = 5; } @@ -295,9 +297,9 @@ (request->retries-- > 0)) { if (!(request->flags & ATA_R_QUIET)) { device_printf(request->dev, - "TIMEOUT - %s retrying (%d retr%s left)", + "TIMEOUT - %s retrying (%d retr%s left) timeout %d", ata_cmd2str(request), request->retries, - request->retries == 1 ? "y" : "ies"); + request->retries == 1 ? "y" : "ies", request->timeout); if (!(request->flags & (ATA_R_ATAPI | ATA_R_CONTROL))) printf(" LBA=%ju", request->u.ata.lba); printf("\n"); Index: sys/dev/ata/ata-disk.c =================================================================== --- sys/dev/ata/ata-disk.c (revision 190917) +++ sys/dev/ata/ata-disk.c (working copy) @@ -263,8 +263,9 @@ device_printf(dev, "request while spun down, starting.\n"); atadev->spindown_state = 0; request->timeout = 31; - } - else { + } else if (bp->bio_cmd == BIO_FLUSH) { + request->timeout = 31; + } else { request->timeout = 5; } request->retries = 2; From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 03:11: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 75FA51065673 for ; Thu, 16 Apr 2009 03:11:32 +0000 (UTC) (envelope-from grosser@fim.uni-passau.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by mx1.freebsd.org (Postfix) with ESMTP id 3667C8FC14 for ; Thu, 16 Apr 2009 03:11:32 +0000 (UTC) (envelope-from grosser@fim.uni-passau.de) Received: from [84.56.32.153] (helo=[192.168.178.29]) by smtprelay04.ispgateway.de with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1LuHpX-0005hX-6p; Thu, 16 Apr 2009 04:59:59 +0200 From: Tobias Grosser To: Maksim Yevmenkin In-Reply-To: References: Content-Type: text/plain Date: Thu, 16 Apr 2009 04:59:55 +0200 Message-Id: <1239850795.1222.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Df-Sender: 023415 X-Mailman-Approved-At: Thu, 16 Apr 2009 04:09:22 +0000 Cc: FreeBSD Current Subject: Re: [patch] prevent atkbd(4) from calling callback in polled 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: Thu, 16 Apr 2009 03:11:32 -0000 On Wed, 2009-04-15 at 17:17 -0700, Maksim Yevmenkin wrote: > hello, > > would anyone object to the small attached atkbd(4) patch? the idea is > to basically prevent atkbd(4) interrupt handler from calling keyboard > callback function when polled mode is enabled. > > i would really like to hear from people who is using kbdmux(4) on smp > systems and having problems with duplicated/missing characters while > using keyboard at mountroot, geli, etc. prompts. basically, when low > level console input functions (cngetc(), gets(), etc.) are used _and_ > interrupts are enabled. Hey, thanks a lot. This makes geli work with kbdmux loaded on my dual core system. Before, I had to remove kbdmux to be able to mount my discs during boot, as there where a lot of duplicate characters. Tobi From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 04:13:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7F4C1065676; Thu, 16 Apr 2009 04:13:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8078C8FC08; Thu, 16 Apr 2009 04:13:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3G4DSHg072600; Thu, 16 Apr 2009 00:13:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3G4DSHl071487; Thu, 16 Apr 2009 00:13:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4CFE37302F; Thu, 16 Apr 2009 00:13:28 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090416041328.4CFE37302F@freebsd-current.sentex.ca> Date: Thu, 16 Apr 2009 00:13:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on 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, 16 Apr 2009 04:13:32 -0000 TB --- 2009-04-16 02:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-16 02:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-04-16 02:00:00 - cleaning the object tree TB --- 2009-04-16 02:01:11 - cvsupping the source tree TB --- 2009-04-16 02:01:11 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-04-16 02:01:19 - building world TB --- 2009-04-16 02:01:19 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-16 02:01:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-16 02:01:19 - TARGET=amd64 TB --- 2009-04-16 02:01:19 - TARGET_ARCH=amd64 TB --- 2009-04-16 02:01:19 - TZ=UTC TB --- 2009-04-16 02:01:19 - __MAKE_CONF=/dev/null TB --- 2009-04-16 02:01:19 - cd /src TB --- 2009-04-16 02:01:19 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 16 02:01:21 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 Apr 16 04:01:48 UTC 2009 TB --- 2009-04-16 04:01:48 - generating LINT kernel config TB --- 2009-04-16 04:01:48 - cd /src/sys/amd64/conf TB --- 2009-04-16 04:01:48 - /usr/bin/make -B LINT TB --- 2009-04-16 04:01:48 - building LINT kernel TB --- 2009-04-16 04:01:48 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-16 04:01:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-16 04:01:48 - TARGET=amd64 TB --- 2009-04-16 04:01:48 - TARGET_ARCH=amd64 TB --- 2009-04-16 04:01:48 - TZ=UTC TB --- 2009-04-16 04:01:48 - __MAKE_CONF=/dev/null TB --- 2009-04-16 04:01:48 - cd /src TB --- 2009-04-16 04:01:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 16 04:01:49 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] 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/geom/part/g_part.c awk -f /src/sys/tools/makeobjops.awk /src/sys/geom/part/g_part_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 g_part_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/geom/part/g_part_apm.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/geom/part/g_part_bsd.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/geom/part/g_part_ebr.c cc1: warnings being treated as errors /src/sys/geom/part/g_part_ebr.c: In function 'g_part_ebr_fullname': /src/sys/geom/part/g_part_ebr.c:327: warning: field precision should have type 'int', but argument 3 has type 'size_t' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-16 04:13:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-16 04:13:28 - ERROR: failed to build lint kernel TB --- 2009-04-16 04:13:28 - 6184.82 user 645.54 system 8007.77 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 04: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 8667A106564A for ; Thu, 16 Apr 2009 04:50:45 +0000 (UTC) (envelope-from vehemens@verizon.net) Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) by mx1.freebsd.org (Postfix) with ESMTP id 6278C8FC0C for ; Thu, 16 Apr 2009 04:50:45 +0000 (UTC) (envelope-from vehemens@verizon.net) Received: from sam ([71.107.29.97]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KI600GFWDC3H3BK@vms173007.mailsrvcs.net> for freebsd-current@freebsd.org; Wed, 15 Apr 2009 22:50:28 -0500 (CDT) From: vehemens To: freebsd-current@freebsd.org Date: Wed, 15 Apr 2009 20:53:55 -0700 User-Agent: KMail/1.9.10 References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090415160311.2e898844@ernst.jennejohn.org> <49E5EE04.1050208@zedat.fu-berlin.de> In-reply-to: <49E5EE04.1050208@zedat.fu-berlin.de> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-15 Content-transfer-encoding: 7bit Content-disposition: inline Message-id: <200904152053.56058.vehemens@verizon.net> Cc: "O. Hartmann" , Martin Subject: Re: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 04:50:45 -0000 On Wednesday 15 April 2009 07:24:04 am O. Hartmann wrote: > Gary Jennejohn wrote: > > On Wed, 15 Apr 2009 10:07:59 +0000 > > > > "O. Hartmann" wrote: > >> Gary Jennejohn wrote: > >>> On Wed, 15 Apr 2009 06:55:44 +0000 > >>> > >>> "O. Hartmann" wrote: > >>>> Martin wrote: > >>>>> Am Tue, 14 Apr 2009 18:08:54 +0200 > >>>>> > >>>>> schrieb "O. Hartmann" : > >>>>>> [...] > >>>>> > >>>>> Hi, > >>>>> > >>>>> if you have problems with the radeonhd driver, you should tell the > >>>>> guys who work at it. They are really nice and try to help everywhere. > >>>>> > >>>>> Subscribe there: > >>>>> http://lists.opensuse.org/radeonhd/ > >>>>> > >>>>> I am only using radeonhd, because it works for me on all cards I > >>>>> have. > >>>>> > >>>>> I noticed that window movement may get choppy, when you compile a new > >>>>> kernel (DRM) and don't recompile a fresh radeonhd driver. This > >>>>> happens especially when DRI is enabled for your xorg server. > >>>>> > >>>>> -- > >>>>> Martin > >>>> > >>>> As far as I know, radeonhd from ports doesn't work with DRI enabled on > >>>> FreeBSD - so it doesn't work on my box either. I guess you're > >>>> following the recommendations using the development brnach directly > >>>> from GIT. > >>> > >>> Works for me on amd64 8-current. > >>> > >>> garyj:ernst:~:-bash:4> grep DRI /var/log/Xorg.0.log > >>> (II) Loading extension XFree86-DRI > >>> (II) Loading extension DRI2 > >>> (**) RADEONHD(0): Option "DRI" > >>> (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x024B4000 > >>> (size = 0x00B13000) (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at > >>> offset 0x02FC7000 (size = 0x00B13000) (II) RADEONHD(0): FB: Allocated > >>> DRI Textures at offset 0x03ADA000 (size = 0x0C400000) (II) RADEONHD(0): > >>> [DRI] installation complete > >>> (II) GLX: Initialized DRISWRAST GL provider for screen 0 > >>> garyj:ernst:~:-bash:5> ls -d /var/db/pkg/*radeon* > >>> drwxr-xr-x 2 root wheel 512 Apr 14 11:32 > >>> /var/db/pkg/xf86-video-radeonhd-devel-1.2.5.20090412 > >> > >> Tried radeonhd-devel and failed also! > >> > >> When enabling DRI in config file, I see the XDM login box and the box > >> crashes and freezes immediately. Without DRI radeonhd-devel is horrible > >> slow when moving windows around - inacceptable. It doesn't matter > >> whether EXA is enabled or not and the phenomenon ist the same as with > >> the regular radeonhd-driver from xorg-drivers. > >> > >> I'm back with the VESA driver. > > > > Hmm. Are the drm and radeondrm in your kernel up-to-date? Your posting > > was chopped by the first replier and I can't remember. > > > > Can't think of anything else. > > > > I personally don't use xdm/gdm/kdm. I just use startx. > > > > --- > > Gary Jennejohn > > The kernel modules 'radeon' and 'drm' are loaded via /boot/loader.conf > when booting and they are up to date (I do a buildworld on a regular > basis these days and it takes ~30 minutes for a quad core box). > > Even when not starting X via xdm, the box crashes immediately, freezes > and is only 'revivable' by cold resetting. This happens with driver > radeonhd and enabled DRI. Without DRI the radeonhd driver works, but > moving a window looks like on Windooze when using standard VGA driver > without acceleration (this is bot with EXA on or off) - scrolling and > moving objects is really choppy. > > 'radeon' doesn't even show up anything, freezes the box as well as > 'radeonhd', but no matter whether DRI enabled or not. > > At home I will test radeonhd-devel with the RV770LE chipset (here I have > only RV730). The RV770LE seems not to be recognized by 'radeonhd', but > works fine with 'radeon'. But in both cases, DRI enabled crashes the box. Could you post your xorg.conf? From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 05:48: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 A28D3106564A for ; Thu, 16 Apr 2009 05:48:55 +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 5CCB38FC0C for ; Thu, 16 Apr 2009 05:48:55 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [195.93.241.27] (port=31952 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuKT0-0001Vg-15; Thu, 16 Apr 2009 09:48:54 +0400 Message-ID: <49E6C6C5.7000401@lissyara.su> Date: Thu, 16 Apr 2009 09:48:53 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.21) Gecko/20090406 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Ivan Voras References: <49E41A2F.9080105@lissyara.su> In-Reply-To: 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: freebsd-current@freebsd.org Subject: Re: NMI ISA 2c, EISA ff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 05:48:55 -0000 Ivan Voras пишет: > Alex Keda wrote: > >> I try install FreBSD; boot from USB hard drive on HP 2133 (laptop) >> Boot not success: >> >> agp0: on host0 >> agp0: aperture size is 128M >> NMI ISA 2c, EISA ff >> > > NMIs are most commonly caused by memory errors (but could be other types > of hardware errors) I try 7.2, with GENERIC - all OK It's CURRENT problem. From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 07:16: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 23B14106566C for ; Thu, 16 Apr 2009 07:16:32 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id E3CB48FC13 for ; Thu, 16 Apr 2009 07:16:31 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id n3G7GU8B039731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 00:16:31 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <49E6DB39.8080103@FreeBSD.org> Date: Thu, 16 Apr 2009 00:16:09 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Sam Leffler Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, "current@freebsd.org" Subject: kernel compile fails without AH_SUPPORT_AR5416 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 07:16:32 -0000 Sam, What is the reason to have this option in the kernel config if kernel compilation fails when this option is enabled? It also affects 7-stable. cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/dev/ath/if_ath.c -I/usr/src/sys/dev/ath /usr/src/sys/dev/ath/if_ath.c: In function 'ath_rx_tap': /usr/src/sys/dev/ath/if_ath.c:3414: error: 'const struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/if_ath.c:3416: error: 'const struct ath_rx_status' has no member named 'rs_flags' -Maxim From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 07:34: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 D8162106564A for ; Thu, 16 Apr 2009 07:34:08 +0000 (UTC) (envelope-from p.pisati@oltrelinux.com) Received: from contactlab34-bk-3.contactlab.it (contactlab34-bk-3.contactlab.it [93.94.34.3]) by mx1.freebsd.org (Postfix) with ESMTP id 688608FC0C for ; Thu, 16 Apr 2009 07:34:08 +0000 (UTC) (envelope-from p.pisati@oltrelinux.com) DKIM-Signature: v=1; a=rsa-sha1; d=contactlab.it; s=s768; c=simple/simple; q=dns/txt; i=@contactlab.it; t=1239865982; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=i+S79oxGzDZwhpTkBj3TzfRNCs4=; b=H2Sg9ovcuAsteBzcmVpY/5P3kBfFRKgdJ5L7zRcy9/twhqwXycIazSUzK6hCfwER psOyFABfGV22+j48acJBxddzoir9aysBXp56wOVfwcM7se0PTEc6vHC16Pr5Q0JG; Received: from [213.92.0.53] ([213.92.0.53:64117] helo=mail0.tomato.it) by vmta3.contactlab.it (envelope-from ) (ecelerity 2.2.2.37 r(28822M)) with ESMTP id 53/2E-06803-E7AD6E94; Thu, 16 Apr 2009 09:13:02 +0200 Received: from ferret.tomato.lan (fast.tomato.it [62.101.64.91]) by mail0.tomato.it (Postfix) with ESMTP id 121812841D; Thu, 16 Apr 2009 09:13:50 +0200 (CEST) Message-ID: <49E6DA6C.1050800@oltrelinux.com> Date: Thu, 16 Apr 2009 09:12:44 +0200 From: Paolo Pisati User-Agent: Thunderbird 2.0.0.19 (X11/20090226) MIME-Version: 1.0 To: Alex Keda References: <49E41A2F.9080105@lissyara.su> <49E6C6C5.7000401@lissyara.su> In-Reply-To: <49E6C6C5.7000401@lissyara.su> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: NMI ISA 2c, EISA ff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 07:34:09 -0000 Alex Keda wrote: > Ivan Voras =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> Alex Keda wrote: >> =20 >>> I try install FreBSD; boot from USB hard drive on HP 2133 (laptop) >>> Boot not success: >>> >>> agp0: on host0 >>> agp0: aperture size is 128M >>> NMI ISA 2c, EISA ff >>> =20 >> >> NMIs are most commonly caused by memory errors (but could be other typ= es >> of hardware errors) > I try 7.2, with GENERIC - all OK > It's CURRENT problem. FWIW i've an hp 2133 running HEAD for a while with no problems (except=20 for missing sound). For some tips: http://laptop.bsdgroup.de/freebsd/index.html?action=3Dshow_laptop_detail&= laptop=3D12784 i didn't enable synaptic support since it made double-tap impossible,=20 nor i can get suspend&resume to work due to ndis, and the vga cam has no drivers, but the rest works fine:=20 bluetooth, wifi, video, lan, sd, etcetc i did my first installation with an usb<->pata adapter and it went fine. --=20 bye, P. From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 07:40:40 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8C22106564A; Thu, 16 Apr 2009 07:40:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A97498FC08; Thu, 16 Apr 2009 07:40:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3G7echq089253; Thu, 16 Apr 2009 03:40:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3G7ebMZ086156; Thu, 16 Apr 2009 03:40:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DFF797302F; Thu, 16 Apr 2009 03:40:37 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090416074037.DFF797302F@freebsd-current.sentex.ca> Date: Thu, 16 Apr 2009 03:40:37 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on 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, 16 Apr 2009 07:40:41 -0000 TB --- 2009-04-16 05:34:14 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-16 05:34:14 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-04-16 05:34:14 - cleaning the object tree TB --- 2009-04-16 05:34:47 - cvsupping the source tree TB --- 2009-04-16 05:34:47 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-04-16 05:34:57 - building world TB --- 2009-04-16 05:34:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-16 05:34:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-16 05:34:57 - TARGET=ia64 TB --- 2009-04-16 05:34:57 - TARGET_ARCH=ia64 TB --- 2009-04-16 05:34:57 - TZ=UTC TB --- 2009-04-16 05:34:57 - __MAKE_CONF=/dev/null TB --- 2009-04-16 05:34:57 - cd /src TB --- 2009-04-16 05:34:57 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 16 05:34: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 >>> World build completed on Thu Apr 16 07:26:41 UTC 2009 TB --- 2009-04-16 07:26:41 - generating LINT kernel config TB --- 2009-04-16 07:26:41 - cd /src/sys/ia64/conf TB --- 2009-04-16 07:26:41 - /usr/bin/make -B LINT TB --- 2009-04-16 07:26:42 - building LINT kernel TB --- 2009-04-16 07:26:42 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-16 07:26:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-16 07:26:42 - TARGET=ia64 TB --- 2009-04-16 07:26:42 - TARGET_ARCH=ia64 TB --- 2009-04-16 07:26:42 - TZ=UTC TB --- 2009-04-16 07:26:42 - __MAKE_CONF=/dev/null TB --- 2009-04-16 07:26:42 - cd /src TB --- 2009-04-16 07:26:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 16 07:26:42 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/geom/part/g_part.c awk -f /src/sys/tools/makeobjops.awk /src/sys/geom/part/g_part_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 g_part_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/geom/part/g_part_apm.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/geom/part/g_part_bsd.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/geom/part/g_part_ebr.c cc1: warnings being treated as errors /src/sys/geom/part/g_part_ebr.c: In function 'g_part_ebr_fullname': /src/sys/geom/part/g_part_ebr.c:327: warning: field precision should have type 'int', but argument 3 has type 'size_t' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-16 07:40:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-16 07:40:37 - ERROR: failed to build lint kernel TB --- 2009-04-16 07:40:37 - 6049.14 user 443.75 system 7583.65 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 08:04: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 578FB106564A; Thu, 16 Apr 2009 08:04:54 +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 0FD7B8FC2C; Thu, 16 Apr 2009 08:04:53 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [195.93.241.27] (port=19583 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuMaa-0006Fe-IS; Thu, 16 Apr 2009 12:04:52 +0400 Message-ID: <49E6E6A4.207@lissyara.su> Date: Thu, 16 Apr 2009 12:04:52 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.21) Gecko/20090406 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Paolo Pisati References: <49E41A2F.9080105@lissyara.su> <49E6C6C5.7000401@lissyara.su> <49E6DA6C.1050800@oltrelinux.com> In-Reply-To: <49E6DA6C.1050800@oltrelinux.com> 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: freebsd-current@freebsd.org, Ivan Voras Subject: Re: NMI ISA 2c, EISA ff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 08:04:54 -0000 Paolo Pisati пишет: > Alex Keda wrote: >> Ivan Voras пишет: >>> Alex Keda wrote: >>> >>>> I try install FreBSD; boot from USB hard drive on HP 2133 (laptop) >>>> Boot not success: >>>> >>>> agp0: on host0 >>>> agp0: aperture size is 128M >>>> NMI ISA 2c, EISA ff >>>> >>> >>> NMIs are most commonly caused by memory errors (but could be other >>> types >>> of hardware errors) >> I try 7.2, with GENERIC - all OK >> It's CURRENT problem. > FWIW i've an hp 2133 running HEAD for a while with no problems (except > for missing sound). > For some tips: > > http://laptop.bsdgroup.de/freebsd/index.html?action=show_laptop_detail&laptop=12784 > > > i didn't enable synaptic support since it made double-tap impossible, > nor i can get suspend&resume to work > due to ndis, and the vga cam has no drivers, but the rest works fine: > bluetooth, wifi, video, lan, sd, etcetc > > i did my first installation with an usb<->pata adapter and it went fine. > for different countries make different hardware... From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 08:13: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 03CE01065670; Thu, 16 Apr 2009 08:13:00 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 7DB498FC18; Thu, 16 Apr 2009 08:12:58 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1LuMiP-0004yu-9B>; Thu, 16 Apr 2009 10:12:57 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1LuMiP-0001aA-4d>; Thu, 16 Apr 2009 10:12:57 +0200 Message-ID: <49E6E833.3010105@zedat.fu-berlin.de> Date: Thu, 16 Apr 2009 08:11:31 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.21 (X11/20090415) MIME-Version: 1.0 To: vehemens References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090415160311.2e898844@ernst.jennejohn.org> <49E5EE04.1050208@zedat.fu-berlin.de> <200904152053.56058.vehemens@verizon.net> In-Reply-To: <200904152053.56058.vehemens@verizon.net> Content-Type: multipart/mixed; boundary="------------060900050109030703000103" X-Originating-IP: 130.133.86.198 Cc: freebsd-x11 , freebsd-current@freebsd.org, Martin Subject: Re: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 08:13:00 -0000 This is a multi-part message in MIME format. --------------060900050109030703000103 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit vehemens wrote: > On Wednesday 15 April 2009 07:24:04 am O. Hartmann wrote: >> Gary Jennejohn wrote: >>> On Wed, 15 Apr 2009 10:07:59 +0000 >>> >>> "O. Hartmann" wrote: >>>> Gary Jennejohn wrote: >>>>> On Wed, 15 Apr 2009 06:55:44 +0000 >>>>> >>>>> "O. Hartmann" wrote: >>>>>> Martin wrote: >>>>>>> Am Tue, 14 Apr 2009 18:08:54 +0200 >>>>>>> >>>>>>> schrieb "O. Hartmann" : >>>>>>>> [...] >>>>>>> Hi, >>>>>>> >>>>>>> if you have problems with the radeonhd driver, you should tell the >>>>>>> guys who work at it. They are really nice and try to help everywhere. >>>>>>> >>>>>>> Subscribe there: >>>>>>> http://lists.opensuse.org/radeonhd/ >>>>>>> >>>>>>> I am only using radeonhd, because it works for me on all cards I >>>>>>> have. >>>>>>> >>>>>>> I noticed that window movement may get choppy, when you compile a new >>>>>>> kernel (DRM) and don't recompile a fresh radeonhd driver. This >>>>>>> happens especially when DRI is enabled for your xorg server. >>>>>>> >>>>>>> -- >>>>>>> Martin >>>>>> As far as I know, radeonhd from ports doesn't work with DRI enabled on >>>>>> FreeBSD - so it doesn't work on my box either. I guess you're >>>>>> following the recommendations using the development brnach directly >>>>>> from GIT. >>>>> Works for me on amd64 8-current. >>>>> >>>>> garyj:ernst:~:-bash:4> grep DRI /var/log/Xorg.0.log >>>>> (II) Loading extension XFree86-DRI >>>>> (II) Loading extension DRI2 >>>>> (**) RADEONHD(0): Option "DRI" >>>>> (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x024B4000 >>>>> (size = 0x00B13000) (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at >>>>> offset 0x02FC7000 (size = 0x00B13000) (II) RADEONHD(0): FB: Allocated >>>>> DRI Textures at offset 0x03ADA000 (size = 0x0C400000) (II) RADEONHD(0): >>>>> [DRI] installation complete >>>>> (II) GLX: Initialized DRISWRAST GL provider for screen 0 >>>>> garyj:ernst:~:-bash:5> ls -d /var/db/pkg/*radeon* >>>>> drwxr-xr-x 2 root wheel 512 Apr 14 11:32 >>>>> /var/db/pkg/xf86-video-radeonhd-devel-1.2.5.20090412 >>>> Tried radeonhd-devel and failed also! >>>> >>>> When enabling DRI in config file, I see the XDM login box and the box >>>> crashes and freezes immediately. Without DRI radeonhd-devel is horrible >>>> slow when moving windows around - inacceptable. It doesn't matter >>>> whether EXA is enabled or not and the phenomenon ist the same as with >>>> the regular radeonhd-driver from xorg-drivers. >>>> >>>> I'm back with the VESA driver. >>> Hmm. Are the drm and radeondrm in your kernel up-to-date? Your posting >>> was chopped by the first replier and I can't remember. >>> >>> Can't think of anything else. >>> >>> I personally don't use xdm/gdm/kdm. I just use startx. >>> >>> --- >>> Gary Jennejohn >> The kernel modules 'radeon' and 'drm' are loaded via /boot/loader.conf >> when booting and they are up to date (I do a buildworld on a regular >> basis these days and it takes ~30 minutes for a quad core box). >> >> Even when not starting X via xdm, the box crashes immediately, freezes >> and is only 'revivable' by cold resetting. This happens with driver >> radeonhd and enabled DRI. Without DRI the radeonhd driver works, but >> moving a window looks like on Windooze when using standard VGA driver >> without acceleration (this is bot with EXA on or off) - scrolling and >> moving objects is really choppy. >> >> 'radeon' doesn't even show up anything, freezes the box as well as >> 'radeonhd', but no matter whether DRI enabled or not. >> >> At home I will test radeonhd-devel with the RV770LE chipset (here I have >> only RV730). The RV770LE seems not to be recognized by 'radeonhd', but >> works fine with 'radeon'. But in both cases, DRI enabled crashes the box. > > Could you post your xorg.conf? > > Well, next round. First some notices. All probem occure at the very moment on FreeBSD 8.0-CURRENT/amd64 due to the fact I do not have any i386 box and I'm not running any graphical 7.X-based boxes. So, here we go. My private box is a UP machine equipted with a RV770LE based graphicscard (MSI R4830). Yesterday I replaced the 'radeon' driver from xf86-video-ati with 'radeonhd' from xf86-video-radeonhd-devel (most recent in ports). Without DRI enabled, this driver is as horrible choppy as I mentioned before. But with all the DRI and EXA stuff enabled, it is as fast as the 'radeon' driver, no difference. On my lab's box the picture is different. This box is a quadcore Q6600 based box, P35 chipset (for PCIe-specs), SMP. This box doesn't work with 'radeon', it crashes immediateley. Using 'radeonhd', either from xf86-video-radeonhd or xf86-video-radeonhd-devel leaves my desktop as choppy as unaccelerated. But enabling DRI crahes the box immediately. Attached you'll find my xorg.conf (at the moment with the VESA driver enabled) and the last Xorg.0.log when the box crashed. It surprises me that there is no evidence of 'RADEONHD' loaded, only 'VESA'. I hope Xorg writes a logfile before killing itself. A comment to the driver section of my xorg.conf: I also commented out everything but Options DRI and EXA without success. Files named Xorg.log.XXX are older files and results of experiments with the regular, non-devel-drivers and dated from the 26. March this year, I put them also into the attachment, for your convenience. Regards, Oliver --------------060900050109030703000103 Content-Type: text/plain; name="Xorg.0.log.radeonhd" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Xorg.0.log.radeonhd" _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/telesto.geoinf.fu-berlin.de:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-CURRENT amd64 Current Operating System: FreeBSD telesto.geoinf.fu-berlin.de 8.0-CURRENT FreeBSD 8.0-CURRENT #12 r191101: Wed Apr 15 07:16:32 UTC 2009 root@telesto.geoinf.fu-berlin.de:/usr/obj/usr/src/sys/TELESTO amd64 Build Date: 15 April 2009 07:36:25AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Apr 15 09:57:23 2009 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Simple Layout" (**) |-->Screen "Screen 1" (0) (**) | |-->Monitor "SyncMaster204B" (**) | |-->Device "HD4670" (**) |-->Input Device "Mouse1" (**) |-->Input Device "Keyboard1" (**) Option "DontZoom" (**) Option "AllowEmptyInput" "Off" (**) Option "AutoAddDevices" "Off" (**) Option "AutoEnableDevices" "Off" (**) Not automatically adding devices (**) Not automatically enabling devices (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/local/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/local/"). (WW) The directory "/usr/local/lib/X11/fonts/Speedo/" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/freefont/" does not exist. Entry deleted from font path. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/TrueType/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, built-ins (==) ModulePath set to "/usr/local/lib/xorg/modules" (II) Loader magic: 0x1520 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on freebsd (--) Using syscons driver with X support (version 2.0) (--) using VT number 8 (--) PCI:*(0@1:0:0) ATI Technologies Inc RV730XT [Radeon HD 4670] rev 0, Mem @ 0xd0000000/268435456, 0xfe9e0000/65536, I/O @ 0x0000c000/256, BIOS @ 0x????????/65536 (II) System resource ranges: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded by default. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded by default. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) "dri2" will be loaded by default. (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "type1" (WW) Warning, couldn't open module type1 (II) UnloadModule: "type1" (EE) Failed to load module "type1" (module does not exist, 0) (II) LoadModule: "freetype" (WW) Warning, couldn't open module freetype (II) UnloadModule: "freetype" (EE) Failed to load module "freetype" (module does not exist, 0) (II) LoadModule: "xtt" (WW) Warning, couldn't open module xtt (II) UnloadModule: "xtt" (EE) Failed to load module "xtt" (module does not exist, 0) (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (==) AIGLX disabled (II) Loading extension GLX (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "vesa" (II) Loading /usr/local/lib/xorg/modules/drivers//vesa_drv.so (II) Module vesa: vendor="X.Org Foundation" compiled for 1.6.0, module version = 2.1.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.4.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.3.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (II) VESA: driver for VESA chipsets: vesa (II) Primary Device is: PCI 01@00:00:0 (II) resource ranges after probing: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) Loading sub module "vbe" (II) LoadModule: "vbe" (II) Loading /usr/local/lib/xorg/modules//libvbe.so (II) Module vbe: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.1.0 ABI class: X.Org Video Driver, version 5.0 (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/local/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) VESA(0): initializing int10 (==) VESA(0): Write-combining range (0xa0000,0x20000) was already clear (==) VESA(0): Write-combining range (0xc0000,0x40000) was already clear (II) VESA(0): Primary V_BIOS segment is: 0xc000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VESA BIOS detected (II) VESA(0): VESA VBE Version 3.0 (II) VESA(0): VESA VBE Total Mem: 16384 kB (II) VESA(0): VESA VBE OEM: ATI ATOMBIOS (II) VESA(0): VESA VBE OEM Software Rev: 11.9 (II) VESA(0): VESA VBE OEM Vendor: (C) 1988-2005, ATI Technologies Inc. (II) VESA(0): VESA VBE OEM Product: RV730 (II) VESA(0): VESA VBE OEM Product Rev: 01.00 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (**) VESA(0): Depth 24, (--) framebuffer bpp 32 (==) VESA(0): RGB weight 888 (==) VESA(0): Default visual is TrueColor (==) VESA(0): Using gamma correction (1.0, 1.0, 1.0) (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Module "ddc" already built-in (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VESA VBE DDC supported (II) VESA(0): VESA VBE DDC Level 2 (II) VESA(0): VESA VBE DDC transfer in appr. 1 sec. (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VESA VBE DDC read successfully (II) VESA(0): Manufacturer: SAM Model: 1ae Serial#: 1112683056 (II) VESA(0): Year: 2006 Week: 16 (II) VESA(0): EDID Version: 1.3 (II) VESA(0): Digital Display Input (II) VESA(0): Max Image Size [cm]: horiz.: 41 vert.: 31 (II) VESA(0): Gamma: 2.20 (II) VESA(0): DPMS capabilities: Off (II) VESA(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 (II) VESA(0): First detailed timing is preferred mode (II) VESA(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) VESA(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) VESA(0): Supported VESA Video Modes: (II) VESA(0): 720x400@70Hz (II) VESA(0): 640x480@60Hz (II) VESA(0): 640x480@67Hz (II) VESA(0): 640x480@72Hz (II) VESA(0): 640x480@75Hz (II) VESA(0): 800x600@56Hz (II) VESA(0): 800x600@60Hz (II) VESA(0): 800x600@72Hz (II) VESA(0): 800x600@75Hz (II) VESA(0): 832x624@75Hz (II) VESA(0): 1024x768@60Hz (II) VESA(0): 1024x768@70Hz (II) VESA(0): 1024x768@75Hz (II) VESA(0): 1280x1024@75Hz (II) VESA(0): 1152x870@75Hz (II) VESA(0): Manufacturer's mask: 0 (II) VESA(0): Supported Future Video Modes: (II) VESA(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) VESA(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) VESA(0): #2: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) VESA(0): #3: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) VESA(0): Supported additional Video Mode: (II) VESA(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) VESA(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) VESA(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) VESA(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz (II) VESA(0): Monitor name: SyncMaster (II) VESA(0): Serial No: HSXL401264 (II) VESA(0): EDID (in hex): (II) VESA(0): 00ffffffffffff004c2dae0130325242 (II) VESA(0): 1010010380291f782aee95a3544c9926 (II) VESA(0): 0f5054bfef80a94081808140714f0101 (II) VESA(0): 010101010101483f403062b0324040c0 (II) VESA(0): 130098321100001e000000fd00384b1e (II) VESA(0): 5111000a202020202020000000fc0053 (II) VESA(0): 796e634d61737465720a2020000000ff (II) VESA(0): 004853584c3430313236340a20200028 (II) VESA(0): EDID vendor "SAM", prod id 430 (II) VESA(0): Using hsync ranges from config file (II) VESA(0): Using vrefresh ranges from config file (II) VESA(0): Printing DDC gathered Modelines: (II) VESA(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) (II) VESA(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) VESA(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) VESA(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) VESA(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) (II) VESA(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) VESA(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) VESA(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) VESA(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) VESA(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) VESA(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) VESA(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) VESA(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) VESA(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) VESA(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) VESA(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) VESA(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) (II) VESA(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) VESA(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) (II) VESA(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) VESA(0): Searching for matching VESA mode(s): (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 100 (640x400) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 640 XResolution: 640 YResolution: 400 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 63 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 63 LinNumberOfImagePages: 63 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 101 (640x480) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 640 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 50 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 50 LinNumberOfImagePages: 50 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 103 (800x600) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 832 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 31 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 832 BnkNumberOfImagePages: 31 LinNumberOfImagePages: 31 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 105 (1024x768) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1024 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 18 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1024 BnkNumberOfImagePages: 18 LinNumberOfImagePages: 18 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 107 (1280x1024) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1280 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 11 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 11 LinNumberOfImagePages: 11 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 110 (640x480) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1280 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 24 RedMaskSize: 5 RedFieldPosition: 10 GreenMaskSize: 5 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 24 LinNumberOfImagePages: 24 LinRedMaskSize: 5 LinRedFieldPosition: 10 LinGreenMaskSize: 5 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 111 (640x480) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1280 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 24 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 24 LinNumberOfImagePages: 24 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 113 (800x600) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1600 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 16 RedMaskSize: 5 RedFieldPosition: 10 GreenMaskSize: 5 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1600 BnkNumberOfImagePages: 16 LinNumberOfImagePages: 16 LinRedMaskSize: 5 LinRedFieldPosition: 10 LinGreenMaskSize: 5 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 114 (800x600) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1600 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 16 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1600 BnkNumberOfImagePages: 16 LinNumberOfImagePages: 16 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 116 (1024x768) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 2048 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 9 RedMaskSize: 5 RedFieldPosition: 10 GreenMaskSize: 5 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2048 BnkNumberOfImagePages: 9 LinNumberOfImagePages: 9 LinRedMaskSize: 5 LinRedFieldPosition: 10 LinGreenMaskSize: 5 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 117 (1024x768) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 2048 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 9 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2048 BnkNumberOfImagePages: 9 LinNumberOfImagePages: 9 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 119 (1280x1024) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 2560 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 5 RedMaskSize: 5 RedFieldPosition: 10 GreenMaskSize: 5 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 5 LinRedFieldPosition: 10 LinGreenMaskSize: 5 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 11a (1280x1024) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 2560 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 5 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 10d (320x200) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 640 XResolution: 320 YResolution: 200 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 127 RedMaskSize: 5 RedFieldPosition: 10 GreenMaskSize: 5 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 127 LinNumberOfImagePages: 127 LinRedMaskSize: 5 LinRedFieldPosition: 10 LinGreenMaskSize: 5 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 10e (320x200) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 640 XResolution: 320 YResolution: 200 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 127 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 127 LinNumberOfImagePages: 127 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 120 (320x200) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1280 XResolution: 320 YResolution: 200 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 63 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 63 LinNumberOfImagePages: 63 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 193 (320x240) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 320 XResolution: 320 YResolution: 240 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 127 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 320 BnkNumberOfImagePages: 127 LinNumberOfImagePages: 127 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 195 (320x240) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 640 XResolution: 320 YResolution: 240 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 84 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 84 LinNumberOfImagePages: 84 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 196 (320x240) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1280 XResolution: 320 YResolution: 240 XCharSize: 8 YCharSize: 8 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 50 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 50 LinNumberOfImagePages: 50 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1b3 (512x384) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 512 XResolution: 512 YResolution: 384 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 63 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 512 BnkNumberOfImagePages: 63 LinNumberOfImagePages: 63 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1b5 (512x384) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1024 XResolution: 512 YResolution: 384 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 35 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1024 BnkNumberOfImagePages: 35 LinNumberOfImagePages: 35 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 1b6 (512x384) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 2048 XResolution: 512 YResolution: 384 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 18 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2048 BnkNumberOfImagePages: 18 LinNumberOfImagePages: 18 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1c3 (640x350) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 640 XResolution: 640 YResolution: 350 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 63 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 640 BnkNumberOfImagePages: 63 LinNumberOfImagePages: 63 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1c5 (640x350) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1280 XResolution: 640 YResolution: 350 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 35 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 35 LinNumberOfImagePages: 35 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 1c6 (640x350) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 2560 XResolution: 640 YResolution: 350 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 17 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 17 LinNumberOfImagePages: 17 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 133 (720x400) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 768 XResolution: 720 YResolution: 400 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 50 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 768 BnkNumberOfImagePages: 50 LinNumberOfImagePages: 50 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 135 (720x400) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1472 XResolution: 720 YResolution: 400 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 27 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1472 BnkNumberOfImagePages: 27 LinNumberOfImagePages: 27 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 136 (720x400) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 2944 XResolution: 720 YResolution: 400 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 13 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2944 BnkNumberOfImagePages: 13 LinNumberOfImagePages: 13 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 153 (1152x864) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1152 XResolution: 1152 YResolution: 864 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 15 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1152 BnkNumberOfImagePages: 15 LinNumberOfImagePages: 15 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 155 (1152x864) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 2304 XResolution: 1152 YResolution: 864 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 7 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2304 BnkNumberOfImagePages: 7 LinNumberOfImagePages: 7 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 156 (1152x864) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 4608 XResolution: 1152 YResolution: 864 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 3 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 4608 BnkNumberOfImagePages: 3 LinNumberOfImagePages: 3 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 163 (1280x960) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1280 XResolution: 1280 YResolution: 960 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 12 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1280 BnkNumberOfImagePages: 12 LinNumberOfImagePages: 12 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 165 (1280x960) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 2560 XResolution: 1280 YResolution: 960 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 5 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 166 (1280x960) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 5120 XResolution: 1280 YResolution: 960 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 5120 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 121 (640x480) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 2560 XResolution: 640 YResolution: 480 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 12 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2560 BnkNumberOfImagePages: 12 LinNumberOfImagePages: 12 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 122 (800x600) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 3200 XResolution: 800 YResolution: 600 XCharSize: 8 YCharSize: 14 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 7 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 3200 BnkNumberOfImagePages: 7 LinNumberOfImagePages: 7 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 123 (1024x768) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 4096 XResolution: 1024 YResolution: 768 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 4 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 4096 BnkNumberOfImagePages: 4 LinNumberOfImagePages: 4 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 124 (1280x1024) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 5120 XResolution: 1280 YResolution: 1024 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 5120 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 143 (1400x1050) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1408 XResolution: 1400 YResolution: 1050 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 10 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1408 BnkNumberOfImagePages: 10 LinNumberOfImagePages: 10 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 145 (1400x1050) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 2816 XResolution: 1400 YResolution: 1050 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 4 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 2816 BnkNumberOfImagePages: 4 LinNumberOfImagePages: 4 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 146 (1400x1050) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 5632 XResolution: 1400 YResolution: 1050 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 5632 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 173 (1600x1200) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1600 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 7 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1600 BnkNumberOfImagePages: 7 LinNumberOfImagePages: 7 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 175 (1600x1200) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 3200 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 3 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 3200 BnkNumberOfImagePages: 3 LinNumberOfImagePages: 3 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear *Mode: 176 (1600x1200) ModeAttributes: 0xbb WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 6400 XResolution: 1600 YResolution: 1200 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 6400 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 183 (1792x1344) ModeAttributes: 0xba WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1792 XResolution: 1792 YResolution: 1344 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 5 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1792 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 185 (1792x1344) ModeAttributes: 0xba WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 3584 XResolution: 1792 YResolution: 1344 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 3584 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 186 (1792x1344) ModeAttributes: 0xba WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 7168 XResolution: 1792 YResolution: 1344 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 7168 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1d3 (1856x1392) ModeAttributes: 0xba WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1856 XResolution: 1856 YResolution: 1392 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 5 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1856 BnkNumberOfImagePages: 5 LinNumberOfImagePages: 5 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1d5 (1856x1392) ModeAttributes: 0xba WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 3712 XResolution: 1856 YResolution: 1392 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 3712 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1d6 (1856x1392) ModeAttributes: 0xba WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 7424 XResolution: 1856 YResolution: 1392 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 7424 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1e3 (1920x1440) ModeAttributes: 0xba WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 1920 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 8 NumberOfBanks: 1 MemoryModel: 4 BankSize: 0 NumberOfImages: 4 RedMaskSize: 0 RedFieldPosition: 0 GreenMaskSize: 0 GreenFieldPosition: 0 BlueMaskSize: 0 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 1920 BnkNumberOfImagePages: 4 LinNumberOfImagePages: 4 LinRedMaskSize: 0 LinRedFieldPosition: 0 LinGreenMaskSize: 0 LinGreenFieldPosition: 0 LinBlueMaskSize: 0 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1e5 (1920x1440) ModeAttributes: 0xba WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 3840 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 16 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 2 RedMaskSize: 5 RedFieldPosition: 11 GreenMaskSize: 6 GreenFieldPosition: 5 BlueMaskSize: 5 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 3840 BnkNumberOfImagePages: 2 LinNumberOfImagePages: 2 LinRedMaskSize: 5 LinRedFieldPosition: 11 LinGreenMaskSize: 6 LinGreenFieldPosition: 5 LinBlueMaskSize: 5 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Mode: 1e6 (1920x1440) ModeAttributes: 0xba WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 WinSize: 64 WinASegment: 0xa000 WinBSegment: 0x0 WinFuncPtr: 0xc000506f BytesPerScanline: 7680 XResolution: 1920 YResolution: 1440 XCharSize: 8 YCharSize: 16 NumberOfPlanes: 1 BitsPerPixel: 32 NumberOfBanks: 1 MemoryModel: 6 BankSize: 0 NumberOfImages: 1 RedMaskSize: 8 RedFieldPosition: 16 GreenMaskSize: 8 GreenFieldPosition: 8 BlueMaskSize: 8 BlueFieldPosition: 0 RsvdMaskSize: 0 RsvdFieldPosition: 0 DirectColorModeInfo: 0 PhysBasePtr: 0xd0000000 LinBytesPerScanLine: 7680 BnkNumberOfImagePages: 1 LinNumberOfImagePages: 1 LinRedMaskSize: 8 LinRedFieldPosition: 16 LinGreenMaskSize: 8 LinGreenFieldPosition: 8 LinBlueMaskSize: 8 LinBlueFieldPosition: 0 LinRsvdMaskSize: 0 LinRsvdFieldPosition: 0 MaxPixelClock: 400000000 (II) VESA(0): Total Memory: 256 64KB banks (16384kB) (II) VESA(0): SyncMaster204B: Using hsync range of 24.00-90.50 kHz (II) VESA(0): SyncMaster204B: Using vrefresh value of 60.00 Hz (II) VESA(0): SyncMaster204B: Using maximum pixel clock of 170.00 MHz (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): Not using built-in mode "1400x1050" (no mode of this name) (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): Not using built-in mode "1152x864" (no mode of this name) (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): Not using built-in mode "720x400" (no mode of this name) (II) VESA(0): Not using built-in mode "640x350" (no mode of this name) (II) VESA(0): Not using built-in mode "512x384" (no mode of this name) (II) VESA(0): Not using built-in mode "320x240" (no mode of this name) (II) VESA(0): Not using built-in mode "320x200" (no mode of this name) (--) VESA(0): Virtual size is 1600x1200 (pitch 1600) (**) VESA(0): *Built-in mode "1600x1200" (**) VESA(0): Built-in mode "1280x1024" (**) VESA(0): Built-in mode "1280x960" (**) VESA(0): Built-in mode "1024x768" (**) VESA(0): Built-in mode "800x600" (**) VESA(0): Built-in mode "640x480" (**) VESA(0): Display dimensions: (410, 310) mm (**) VESA(0): DPI set to (99, 98) (**) VESA(0): Using "Shadow Framebuffer" (II) Loading sub module "shadow" (II) LoadModule: "shadow" (II) Loading /usr/local/lib/xorg/modules//libshadow.so (II) Module shadow: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.1.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/local/lib/xorg/modules//libint10.so (II) VESA(0): initializing int10 (==) VESA(0): Write-combining range (0xa0000,0x20000) was already clear (II) VESA(0): Primary V_BIOS segment is: 0xc000 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VESA BIOS detected (II) VESA(0): VESA VBE Version 3.0 (II) VESA(0): VESA VBE Total Mem: 16384 kB (II) VESA(0): VESA VBE OEM: ATI ATOMBIOS (II) VESA(0): VESA VBE OEM Software Rev: 11.9 (II) VESA(0): VESA VBE OEM Vendor: (C) 1988-2005, ATI Technologies Inc. (II) VESA(0): VESA VBE OEM Product: RV730 (II) VESA(0): VESA VBE OEM Product Rev: 01.00 (II) VESA(0): virtual address = 0x802a00000, physical address = 0xd0000000, size = 16777216 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): Setting up VESA Mode 0x176 (1600x1200) (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) VESA(0): VBESetVBEMode failed(==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear ...Tried again without customized values. (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Default visual is TrueColor (==) VESA(0): Backing store disabled (II) VESA(0): DPMS enabled (==) RandR enabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 (**) Option "Protocol" "Auto" (**) Mouse1: Device: "/dev/sysmouse" (**) Mouse1: Protocol: "Auto" (**) Option "CorePointer" (**) Mouse1: always reports core events (**) Option "Device" "/dev/sysmouse" (==) Mouse1: Emulate3Buttons, Emulate3Timeout: 50 (**) Option "ZAxisMapping" "4 5 6 7" (**) Mouse1: ZAxisMapping: buttons 4, 5, 6 and 7 (**) Mouse1: Buttons: 11 (**) Option "Resolution" "1024" (**) Mouse1: Resolution: 1024 (**) Mouse1: Sensitivity: 1 (II) XINPUT: Adding extended input device "Mouse1" (type: MOUSE) (**) Mouse1: (accel) keeping acceleration scheme 1 (**) Mouse1: (accel) filter chain progression: 2.00 (**) Mouse1: (accel) filter stage 0: 20.00 ms (**) Mouse1: (accel) set acceleration profile 0 (II) Mouse1: SetupAuto: hw.iftype is 4, hw.model is 0 (II) Mouse1: SetupAuto: protocol is SysMouse (**) Option "CoreKeyboard" (**) Keyboard1: always reports core events (**) Option "Protocol" "standard" (**) Keyboard1: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Keyboard1: XkbRules: "xorg" (**) Option "XkbModel" "pc101" (**) Keyboard1: XkbModel: "pc101" (**) Option "XkbLayout" "us" (**) Keyboard1: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) Keyboard1: CustomKeycodes disabled (II) XINPUT: Adding extended input device "Keyboard1" (type: KEYBOARD) (II) 3rd Button detected: disabling emulate3Button (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (II) UnloadModule: "mouse" (II) UnloadModule: "kbd" (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear (==) VESA(0): Write-combining range (0x0,0x1000) was already clear Fatal server error: Caught signal 10. Server aborting Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. --------------060900050109030703000103 Content-Type: text/plain; name="xorg.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xorg.conf" # File generated by xorgconfig. # # Copyright 2004 The X.Org Foundation # # Permission is hereby granted, free of charge, to any person obtaining a # copy of this software and associated documentation files (the "Software"), # to deal in the Software without restriction, including without limitation # the rights to use, copy, modify, merge, publish, distribute, sublicense, # and/or sell copies of the Software, and to permit persons to whom the # Software is furnished to do so, subject to the following conditions: # # The above copyright notice and this permission notice shall be included in # all copies or substantial portions of the Software. # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL # The X.Org Foundation BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, # WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF # OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE # SOFTWARE. # # Except as contained in this notice, the name of The X.Org Foundation shall # not be used in advertising or otherwise to promote the sale, use or other # dealings in this Software without prior written authorization from # The X.Org Foundation. # # ********************************************************************** # Refer to the xorg.conf(5) man page for details about the format of # this file. # ********************************************************************** # ********************************************************************** # Module section -- this section is used to specify # which dynamically loadable modules to load. # ********************************************************************** # Section "Module" # This loads the DBE extension module. # Load "dbe" # Double buffer extension # This loads the miscellaneous extensions module, and disables # initialisation of the XFree86-DGA extension within that module. SubSection "extmod" Option "omit xfree86-dga" # don't initialise the DGA extension EndSubSection # This loads the font modules Load "type1" Load "freetype" Load "xtt" EndSection # ********************************************************************** # Files section. This allows default font and rgb paths to be set # ********************************************************************** Section "Files" # Multiple FontPath entries are allowed (which are concatenated together), # as well as specifying multiple comma-separated entries in one FontPath # command (or a combination of both methods) # # FontPath "/usr/local/lib/X11/fonts/misc/" FontPath "/usr/local/lib/X11/fonts/TTF/" FontPath "/usr/local/lib/X11/fonts/OTF" FontPath "/usr/local/lib/X11/fonts/Type1/" FontPath "/usr/local/lib/X11/fonts/100dpi/" FontPath "/usr/local/lib/X11/fonts/75dpi/" FontPath "/usr/local/lib/X11/fonts/local/" FontPath "/usr/local/lib/X11/fonts/Speedo/" FontPath "/usr/local/lib/X11/fonts/TrueType/" FontPath "/usr/local/lib/X11/fonts/freefont/" # The module search path. The default path is shown here. # ModulePath "/usr/local/lib/modules" EndSection # ********************************************************************** # Server flags section. # ********************************************************************** Section "ServerFlags" # Uncomment this to cause a core dump at the spot where a signal is # received. This may leave the console in an unusable state, but may # provide a better stack trace in the core dump to aid in debugging # Option "NoTrapSignals" # Uncomment this to disable the VT switch sequence # (where n is 1 through 12). This allows clients to receive these key # events. # Option "DontVTSwitch" # Uncomment this to disable the server abort sequence # This allows clients to receive this key event. # Option "DontZap" # Uncomment this to disable the / mode switching # sequences. This allows clients to receive these key events. Option "Dont Zoom" # Uncomment this to disable tuning with the xvidtune client. With # it the client can still run and fetch card and monitor attributes, # but it will not be allowed to change them. If it tries it will # receive a protocol error. # Option "DisableVidModeExtension" # Uncomment this to enable the use of a non-local xvidtune client. # Option "AllowNonLocalXvidtune" # Uncomment this to disable dynamically modifying the input device # (mouse and keyboard) settings. # Option "DisableModInDev" # Uncomment this to enable the use of a non-local client to # change the keyboard or mouse settings (currently only xset). # Option "AllowNonLocalModInDev" # # Neccessary due to avoidance of hald # Option "AutoAddDevices" "Off" Option "AutoEnableDevices" "Off" Option "AllowEmptyInput" "Off" EndSection # ********************************************************************** # Input devices # ********************************************************************** # ********************************************************************** # Core keyboard's InputDevice section # ********************************************************************** Section "InputDevice" Identifier "Keyboard1" Driver "kbd" # For most OSs the protocol can be omitted (it defaults to "Standard"). # When using XQUEUE (only for SVR3 and SVR4, but not Solaris), # uncomment the following line. # Option "Protocol" "Xqueue" Option "AutoRepeat" "500 30" # Specify which keyboard LEDs can be user-controlled (eg, with xset(1)) # Option "Xleds" "1 2 3" # Option "LeftAlt" "Meta" # Option "RightAlt" "ModeShift" # To customise the XKB settings to suit your keyboard, modify the # lines below (which are the defaults). For example, for a non-U.S. # keyboard, you will probably want to use: # Option "XkbModel" "pc105" # If you have a US Microsoft Natural keyboard, you can use: # Option "XkbModel" "microsoft" # # Then to change the language, change the Layout setting. # For example, a german layout can be obtained with: # Option "XkbLayout" "de" # or: # Option "XkbLayout" "de" # Option "XkbVariant" "nodeadkeys" # # If you'd like to switch the positions of your capslock and # control keys, use: # Option "XkbOptions" "ctrl:swapcaps" # These are the default XKB settings for Xorg # Option "XkbRules" "xorg" # Option "XkbModel" "pc105" # Option "XkbLayout" "us" # Option "XkbVariant" "" # Option "XkbOptions" "" # Option "XkbDisable" Option "XkbRules" "xorg" Option "XkbModel" "pc101" Option "XkbLayout" "us" EndSection # ********************************************************************** # Core Pointer's InputDevice section # ********************************************************************** Section "InputDevice" # Identifier and driver Identifier "Mouse1" Driver "mouse" Option "Protocol" "Auto" # Auto detect Option "Device" "/dev/sysmouse" #Option "Device" "/dev/ums0" # When using XQUEUE, comment out the above two lines, and uncomment # the following line. Option "Protocol" "Xqueue" # Mouse-speed setting for PS/2 mouse. Option "Resolution" "1024" # Baudrate and SampleRate are only for some Logitech mice. In # almost every case these lines should be omitted. # Option "BaudRate" "9600" # Option "SampleRate" "150" # Mouse wheel mapping. Default is to map vertical wheel to buttons 4 & 5, # horizontal wheel to buttons 6 & 7. Change if your mouse has more than # 3 buttons and you need to map the wheel to different button ids to avoid # conflicts. Option "ZAxisMapping" "4 5 6 7" # Emulate3Buttons is an option for 2-button mice # Emulate3Timeout is the timeout in milliseconds (default is 50ms) # Option "Emulate3Buttons" # Option "Emulate3Timeout" "50" # ChordMiddle is an option for some 3-button Logitech mice # Option "ChordMiddle" EndSection # ********************************************************************** # Other input device sections # this is optional and is required only if you # are using extended input devices. This is for example only. Refer # to the xorg.conf man page for a description of the options. # ********************************************************************** # # Section "InputDevice" # Identifier "Mouse2" # Driver "mouse" # Option "Protocol" "MouseMan" # Option "Device" "/dev/mouse2" # EndSection # # Section "InputDevice" # Identifier "spaceball" # Driver "magellan" # Option "Device" "/dev/cua0" # EndSection # # Section "InputDevice" # Identifier "spaceball2" # Driver "spaceorb" # Option "Device" "/dev/cua0" # EndSection # # Section "InputDevice" # Identifier "touchscreen0" # Driver "microtouch" # Option "Device" "/dev/ttyS0" # Option "MinX" "1412" # Option "MaxX" "15184" # Option "MinY" "15372" # Option "MaxY" "1230" # Option "ScreenNumber" "0" # Option "ReportingMode" "Scaled" # Option "ButtonNumber" "1" # Option "SendCoreEvents" # EndSection # # Section "InputDevice" # Identifier "touchscreen1" # Driver "elo2300" # Option "Device" "/dev/ttyS0" # Option "MinX" "231" # Option "MaxX" "3868" # Option "MinY" "3858" # Option "MaxY" "272" # Option "ScreenNumber" "0" # Option "ReportingMode" "Scaled" # Option "ButtonThreshold" "17" # Option "ButtonNumber" "1" # Option "SendCoreEvents" # EndSection # ********************************************************************** # Monitor section # ********************************************************************** # Any number of monitor sections may be present Section "Monitor" Identifier "SyncMaster204B" # HorizSync is in kHz unless units are specified. # HorizSync may be a comma separated list of discrete values, or a # comma separated list of ranges of values. # NOTE: THE VALUES HERE ARE EXAMPLES ONLY. REFER TO YOUR MONITOR'S # USER MANUAL FOR THE CORRECT NUMBERS. HorizSync 24.0-90.5 # HorizSync 30-64 # multisync # HorizSync 31.5, 35.2 # multiple fixed sync frequencies # HorizSync 15-25, 30-50 # multiple ranges of sync frequencies # VertRefresh is in Hz unless units are specified. # VertRefresh may be a comma separated list of discrete values, or a # comma separated list of ranges of values. # NOTE: THE VALUES HERE ARE EXAMPLES ONLY. REFER TO YOUR MONITOR'S # USER MANUAL FOR THE CORRECT NUMBERS. VertRefresh 60 EndSection # ********************************************************************** # Graphics device section # ********************************************************************** # Any number of graphics device sections may be present # Standard VGA Device: Section "Device" Identifier "Standard VGA" VendorName "Unknown" BoardName "Unknown" # The chipset line is optional in most cases. It can be used to override # the driver's chipset detection, and should not normally be specified. # Chipset "generic" # The Driver line must be present. When using run-time loadable driver # modules, this line instructs the server to load the specified driver # module. Even when not using loadable driver modules, this line # indicates which driver should interpret the information in this section. Driver "vga" # The BusID line is used to specify which of possibly multiple devices # this section is intended for. When this line isn't present, a device # section can only match up with the primary video device. For PCI # devices a line like the following could be used. This line should not # normally be included unless there is more than one video device # intalled. # BusID "PCI:0:10:0" # VideoRam 256 # Clocks 25.2 28.3 EndSection # Device configured by xorgconfig: Section "Device" Identifier "HD4670" #Driver "radeonhd" Driver "vesa" Option "AccelMethod" "EXA" Option "DRI" "On" Option "Audio" #Option "DynamicClocks" "On" EndSection # ********************************************************************** # Screen sections # ********************************************************************** # Any number of screen sections may be present. Each describes # the configuration of a single screen. A single specific screen section # may be specified from the X server command line with the "-screen" # option. Section "Screen" Identifier "Screen 1" Device "HD4670" Monitor "SyncMaster204B" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1600x1200" ViewPort 0 0 EndSubsection EndSection # ********************************************************************** # ServerLayout sections. # ********************************************************************** # Any number of ServerLayout sections may be present. Each describes # the way multiple screens are organised. A specific ServerLayout # section may be specified from the X server command line with the # "-layout" option. In the absence of this, the first section is used. # When now ServerLayout section is present, the first Screen section # is used alone. Section "ServerLayout" # The Identifier line must be present Identifier "Simple Layout" # Each Screen line specifies a Screen section name, and optionally # the relative position of other screens. The four names after # primary screen name are the screens to the top, bottom, left and right # of the primary screen. In this example, screen 2 is located to the # right of screen 1. Screen "Screen 1" # Each InputDevice line specifies an InputDevice section name and # optionally some options to specify the way the device is to be # used. Those options include "CorePointer", "CoreKeyboard" and # "SendCoreEvents". InputDevice "Mouse1" "CorePointer" InputDevice "Keyboard1" "CoreKeyboard" EndSection Section "DRI" Mode 0666 EndSection --------------060900050109030703000103 Content-Type: text/plain; name="Xorg.log.0.radeon" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Xorg.log.0.radeon" _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/telesto.geoinf.fu-berlin.de:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 X.Org X Server 1.5.3 Release Date: 5 November 2008 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-CURRENT amd64 Current Operating System: FreeBSD telesto.geoinf.fu-berlin.de 8.0-CURRENT FreeBSD 8.0-CURRENT #28 r190437: Thu Mar 26 07:51:49 UTC 2009 root@telesto.geoinf.fu-berlin.de:/usr/obj/usr/src/sys/TELESTO amd64 Build Date: 18 March 2009 11:24:10AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu Mar 26 11:33:18 2009 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Simple Layout" (**) |-->Screen "Screen 1" (0) (**) | |-->Monitor "SyncMaster204B" (**) | |-->Device "HD4670" (**) |-->Input Device "Mouse1" (**) |-->Input Device "Keyboard1" (**) Option "DontZoom" (**) Option "AllowEmptyInput" "Off" (**) Option "AutoAddDevices" "Off" (**) Option "AutoEnableDevices" "Off" (**) Not automatically adding devices (**) Not automatically enabling devices (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/local/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/local/"). (WW) The directory "/usr/local/lib/X11/fonts/Speedo/" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/TrueType/" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/freefont/" does not exist. Entry deleted from font path. (==) Including the default font path /usr/local/lib/X11/fonts/misc/,/usr/local/lib/X11/fonts/TTF/,/usr/local/lib/X11/fonts/OTF,/usr/local/lib/X11/fonts/Type1/,/usr/local/lib/X11/fonts/100dpi/,/usr/local/lib/X11/fonts/75dpi/. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (==) ModulePath set to "/usr/local/lib/xorg/modules" (II) Loader magic: 0x65e6e0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 4.1 X.Org XInput driver : 2.1 X.Org Server Extension : 1.1 X.Org Font Renderer : 0.6 (II) Loader running on freebsd (--) Using syscons driver with X support (version 2.0) (--) using VT number 8 (--) PCI:*(0@1:0:0) ATI Technologies Inc RV730XT [Radeon HD 4670] rev 0, Mem @ 0xd0000000/268435456, I/O @ 0x0000c000/256, BIOS @ 0x????????/65536 (II) System resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded by default. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "freetype" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded by default. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 1.1 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "type1" (WW) Warning, couldn't open module type1 (II) UnloadModule: "type1" (EE) Failed to load module "type1" (module does not exist, 0) (II) LoadModule: "freetype" (II) Loading /usr/local/lib/xorg/modules/fonts//libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 1.5.3, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.6 (II) Loading font FreeType (II) LoadModule: "xtt" (WW) Warning, couldn't open module xtt (II) UnloadModule: "xtt" (EE) Failed to load module "xtt" (module does not exist, 0) (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 ABI class: X.Org Server Extension, version 1.1 (==) AIGLX disabled (==) Exporting typical set of GLX visuals (II) Loading extension GLX (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 ABI class: X.Org Server Extension, version 1.1 (II) Loading extension XFree86-DRI (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 1.1 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 1.1 (II) Loading extension RECORD (II) LoadModule: "radeon" (II) Loading /usr/local/lib/xorg/modules/drivers//radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" compiled for 1.5.3, module version = 6.12.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 4.1 (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.4.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.1 (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.3.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.1 (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI), ATI Radeon Mobility X300 (M24) 3152 (PCIE), ATI FireGL M24 GL 3154 (PCIE), ATI Radeon X600 (RV380) 3E50 (PCIE), ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), ATI FireGL Z1 AG (AGP), ATI Radeon 9800SE AH (AGP), ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP), ATI FireGL X2 AK (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI Radeon 9650, ATI FireGL RV360 AV (AGP), ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon 8500 AIW BB (AGP), ATI Radeon 8500 AIW BC (AGP), ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330M/340M/350M (U2) 4337, ATI Radeon Mobility 7000 IGP 4437, ATI Radeon 9000/PRO If (AGP/PCI), ATI Radeon 9000 Ig (AGP/PCI), ATI Radeon X800 (R420) JH (AGP), ATI Radeon X800PRO (R420) JI (AGP), ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP), ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP), ATI Radeon Mobility 9800 (M18) JN (AGP), ATI Radeon X800 SE (R420) (AGP), ATI Radeon X800XT (R420) JP (AGP), ATI Radeon X850 XT (R480) (AGP), ATI Radeon X850 SE (R480) (AGP), ATI Radeon X850 PRO (R480) (AGP), ATI Radeon X850 XT PE (R480) (AGP), ATI Radeon Mobility M7 LW (AGP), ATI Mobility FireGL 7800 M7 LX (AGP), ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), ATI FireGL Mobility 9000 (M9) Ld (AGP), ATI Radeon Mobility 9000 (M9) Lf (AGP), ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9600TX NF (AGP), ATI FireGL X1 NG (AGP), ATI Radeon 9800PRO NH (AGP), ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP), ATI Radeon 9800XT NJ (AGP), ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP), ATI Radeon Mobility 9600 (M10) NQ (AGP), ATI Radeon Mobility 9600 (M11) NR (AGP), ATI Radeon Mobility 9600 (M10) NS (AGP), ATI FireGL Mobility T2 (M10) NT (AGP), ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 9100 QM (AGP), ATI Radeon 7500 QW (AGP/PCI), ATI Radeon 7500 QX (AGP/PCI), ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI), ATI ES1000 515E (PCI), ATI Radeon Mobility X300 (M22) 5460 (PCIE), ATI Radeon Mobility X600 SE (M24C) 5462 (PCIE), ATI FireGL M22 GL 5464 (PCIE), ATI Radeon X800 (R423) UH (PCIE), ATI Radeon X800PRO (R423) UI (PCIE), ATI Radeon X800LE (R423) UJ (PCIE), ATI Radeon X800SE (R423) UK (PCIE), ATI Radeon X800 XTP (R430) (PCIE), ATI Radeon X800 XL (R430) (PCIE), ATI Radeon X800 SE (R430) (PCIE), ATI Radeon X800 (R430) (PCIE), ATI FireGL V7100 (R423) (PCIE), ATI FireGL V5100 (R423) UQ (PCIE), ATI FireGL unknown (R423) UR (PCIE), ATI FireGL unknown (R423) UT (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility Radeon X700 XL (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Radeon X550XTX 5657 (PCIE), ATI Radeon 9100 IGP (A5) 5834, ATI Radeon Mobility 9100 IGP (U3) 5835, ATI Radeon XPRESS 200 5954 (PCIE), ATI Radeon XPRESS 200M 5955 (PCIE), ATI Radeon 9250 5960 (AGP), ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI), ATI ES1000 5969 (PCI), ATI Radeon XPRESS 200 5974 (PCIE), ATI Radeon XPRESS 200M 5975 (PCIE), ATI Radeon XPRESS 200 5A41 (PCIE), ATI Radeon XPRESS 200M 5A42 (PCIE), ATI Radeon XPRESS 200 5A61 (PCIE), ATI Radeon XPRESS 200M 5A62 (PCIE), ATI Radeon X300 (RV370) 5B60 (PCIE), ATI Radeon X600 (RV370) 5B62 (PCIE), ATI Radeon X550 (RV370) 5B63 (PCIE), ATI FireGL V3100 (RV370) 5B64 (PCIE), ATI FireMV 2200 PCIE (RV370) 5B65 (PCIE), ATI Radeon Mobility 9200 (M9+) 5C61 (AGP), ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Mobility Radeon X800 XT (M28) (PCIE), ATI Mobility FireGL V5100 (M28) (PCIE), ATI Mobility Radeon X800 (M28) (PCIE), ATI Radeon X850 5D4C (PCIE), ATI Radeon X850 XT PE (R480) (PCIE), ATI Radeon X850 SE (R480) (PCIE), ATI Radeon X850 PRO (R480) (PCIE), ATI unknown Radeon / FireGL (R480) 5D50 (PCIE), ATI Radeon X850 XT (R480) (PCIE), ATI Radeon X800XT (R423) 5D57 (PCIE), ATI FireGL V5000 (RV410) (PCIE), ATI Radeon X700 XT (RV410) (PCIE), ATI Radeon X700 PRO (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X700 (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X1800, ATI Mobility Radeon X1800 XT, ATI Mobility Radeon X1800, ATI Mobility FireGL V7200, ATI FireGL V7200, ATI FireGL V5300, ATI Mobility FireGL V7100, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI FireGL V7300, ATI FireGL V7350, ATI Radeon X1600, ATI RV505, ATI Radeon X1300/X1550, ATI Radeon X1550, ATI M54-GL, ATI Mobility Radeon X1400, ATI Radeon X1300/X1550, ATI Radeon X1550 64-bit, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Radeon X1300, ATI Radeon X1300, ATI RV505, ATI RV505, ATI FireGL V3300, ATI FireGL V3350, ATI Radeon X1300, ATI Radeon X1550 64-bit, ATI Radeon X1300/X1550, ATI Radeon X1600, ATI Radeon X1300/X1550, ATI Mobility Radeon X1450, ATI Radeon X1300/X1550, ATI Mobility Radeon X2300, ATI Mobility Radeon X2300, ATI Mobility Radeon X1350, ATI Mobility Radeon X1350, ATI Mobility Radeon X1450, ATI Radeon X1300, ATI Radeon X1550, ATI Mobility Radeon X1350, ATI FireMV 2250, ATI Radeon X1550 64-bit, ATI Radeon X1600, ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1600, ATI Mobility FireGL V5200, ATI Mobility Radeon X1600, ATI Radeon X1650, ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1300 XT/X1600 Pro, ATI FireGL V3400, ATI Mobility FireGL V5250, ATI Mobility Radeon X1700, ATI Mobility Radeon X1700 XT, ATI FireGL V5200, ATI Mobility Radeon X1700, ATI Radeon X2300HD, ATI Mobility Radeon HD 2300, ATI Mobility Radeon HD 2300, ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI AMD Stream Processor, ATI Radeon X1900, ATI Radeon X1950, ATI RV560, ATI RV560, ATI Mobility Radeon X1900, ATI RV560, ATI Radeon X1950 GT, ATI RV570, ATI RV570, ATI FireGL V7400, ATI RV560, ATI Radeon X1650, ATI Radeon X1650, ATI RV560, ATI Radeon 9100 PRO IGP 7834, ATI Radeon Mobility 9200 IGP 7835, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI RS740, ATI RS740M, ATI RS740, ATI RS740M, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 Pro, ATI Radeon HD 2900 GT, ATI FireGL V8650, ATI FireGL V8600, ATI FireGL V7600, ATI Radeon 4800 Series, ATI Radeon HD 4870 x2, ATI Radeon 4800 Series, ATI FirePro V8750 (FireGL), ATI FirePro V7760 (FireGL), ATI Mobility RADEON HD 4850, ATI Mobility RADEON HD 4850 X2, ATI Radeon 4800 Series, ATI FirePro RV770, AMD FireStream 9270, AMD FireStream 9250, ATI FirePro V8700 (FireGL), ATI Mobility RADEON HD 4870, ATI Mobility RADEON M98, ATI FirePro M7750, ATI M98, ATI M98, ATI M98, ATI Radeon RV730 (AGP), ATI FirePro M5750, ATI Radeon RV730 (AGP), ATI RV730XT [Radeon HD 4670], ATI RADEON E4600, ATI RV730 PRO [Radeon HD 4650], ATI FirePro V7750 (FireGL), ATI FirePro V5700 (FireGL), ATI FirePro V3750 (FireGL), ATI RV610, ATI Radeon HD 2400 XT, ATI Radeon HD 2400 Pro, ATI Radeon HD 2400 PRO AGP, ATI FireGL V4000, ATI RV610, ATI Radeon HD 2350, ATI Mobility Radeon HD 2400 XT, ATI Mobility Radeon HD 2400, ATI RADEON E2400, ATI RV610, ATI FireMV 2260, ATI RV670, ATI Radeon HD3870, ATI Mobility Radeon HD 3850, ATI Radeon HD3850, ATI Mobility Radeon HD 3850 X2, ATI RV670, ATI Mobility Radeon HD 3870, ATI Mobility Radeon HD 3870 X2, ATI Radeon HD3870 X2, ATI FireGL V7700, ATI Radeon HD3850, ATI Radeon HD3690, AMD Firestream 9170, ATI Radeon HD 4550, ATI Radeon RV710, ATI Radeon RV710, ATI Radeon HD 4350, ATI Mobility Radeon 4300 Series, ATI Mobility Radeon 4500 Series, ATI Mobility Radeon 4500 Series, ATI RV630, ATI Mobility Radeon HD 2600, ATI Mobility Radeon HD 2600 XT, ATI Radeon HD 2600 XT AGP, ATI Radeon HD 2600 Pro AGP, ATI Radeon HD 2600 XT, ATI Radeon HD 2600 Pro, ATI Gemini RV630, ATI Gemini Mobility Radeon HD 2600 XT, ATI FireGL V5600, ATI FireGL V3600, ATI Radeon HD 2600 LE, ATI Mobility FireGL Graphics Processor, ATI Radeon RV710, ATI Radeon HD 3470, ATI Mobility Radeon HD 3430, ATI Mobility Radeon HD 3400 Series, ATI Radeon HD 3450, ATI Radeon HD 3450, ATI Radeon HD 3430, ATI Radeon HD 3450, ATI FirePro V3700, ATI FireMV 2450, ATI FireMV 2260, ATI FireMV 2260, ATI Radeon HD 3600 Series, ATI Radeon HD 3650 AGP, ATI Radeon HD 3600 PRO, ATI Radeon HD 3600 XT, ATI Radeon HD 3600 PRO, ATI Mobility Radeon HD 3650, ATI Mobility Radeon HD 3670, ATI Mobility FireGL V5700, ATI Mobility FireGL V5725, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3300 Graphics (II) Primary Device is: PCI 01@00:00:0 (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) resource ranges after probing: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [5] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [6] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [7] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [8] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [9] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [10] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) RADEON(0): TOTO SAYS 0000000000000000 (EE) RADEON(0): No valid MMIO address (II) UnloadModule: "radeon" (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found --------------060900050109030703000103 Content-Type: text/plain; name="Xorg.log.0.radeonhd" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Xorg.log.0.radeonhd" _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/telesto.geoinf.fu-berlin.de:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 X.Org X Server 1.5.3 Release Date: 5 November 2008 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-CURRENT amd64 Current Operating System: FreeBSD telesto.geoinf.fu-berlin.de 8.0-CURRENT FreeBSD 8.0-CURRENT #28 r190437: Thu Mar 26 07:51:49 UTC 2009 root@telesto.geoinf.fu-berlin.de:/usr/obj/usr/src/sys/TELESTO amd64 Build Date: 18 March 2009 11:24:10AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu Mar 26 11:33:03 2009 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Simple Layout" (**) |-->Screen "Screen 1" (0) (**) | |-->Monitor "SyncMaster204B" (**) | |-->Device "HD4670" (**) |-->Input Device "Mouse1" (**) |-->Input Device "Keyboard1" (**) Option "DontZoom" (**) Option "AllowEmptyInput" "Off" (**) Option "AutoAddDevices" "Off" (**) Option "AutoEnableDevices" "Off" (**) Not automatically adding devices (**) Not automatically enabling devices (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/local/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/local/"). (WW) The directory "/usr/local/lib/X11/fonts/Speedo/" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/TrueType/" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/freefont/" does not exist. Entry deleted from font path. (==) Including the default font path /usr/local/lib/X11/fonts/misc/,/usr/local/lib/X11/fonts/TTF/,/usr/local/lib/X11/fonts/OTF,/usr/local/lib/X11/fonts/Type1/,/usr/local/lib/X11/fonts/100dpi/,/usr/local/lib/X11/fonts/75dpi/. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (==) ModulePath set to "/usr/local/lib/xorg/modules" (II) Loader magic: 0x65e6e0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 4.1 X.Org XInput driver : 2.1 X.Org Server Extension : 1.1 X.Org Font Renderer : 0.6 (II) Loader running on freebsd (--) Using syscons driver with X support (version 2.0) (--) using VT number 8 (--) PCI:*(0@1:0:0) ATI Technologies Inc RV730XT [Radeon HD 4670] rev 0, Mem @ 0xd0000000/268435456, I/O @ 0x0000c000/256, BIOS @ 0x????????/65536 (II) System resource ranges: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded by default. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "freetype" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded by default. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 1.1 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "type1" (WW) Warning, couldn't open module type1 (II) UnloadModule: "type1" (EE) Failed to load module "type1" (module does not exist, 0) (II) LoadModule: "freetype" (II) Loading /usr/local/lib/xorg/modules/fonts//libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 1.5.3, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.6 (II) Loading font FreeType (II) LoadModule: "xtt" (WW) Warning, couldn't open module xtt (II) UnloadModule: "xtt" (EE) Failed to load module "xtt" (module does not exist, 0) (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 ABI class: X.Org Server Extension, version 1.1 (==) AIGLX disabled (==) Exporting typical set of GLX visuals (II) Loading extension GLX (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 ABI class: X.Org Server Extension, version 1.1 (II) Loading extension XFree86-DRI (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 1.1 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 1.1 (II) Loading extension RECORD (II) LoadModule: "radeonhd" (II) Loading /usr/local/lib/xorg/modules/drivers//radeonhd_drv.so (II) Module radeonhd: vendor="AMD GPG" compiled for 1.5.3, module version = 1.2.4 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 4.1 (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.4.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.1 (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.5.3, module version = 1.3.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.1 (II) RADEONHD: X driver for the following AMD GPG (ATI) graphics devices: RV505 : Radeon X1550, X1550 64bit. RV515 : Radeon X1300, X1550, X1600; FireGL V3300, V3350. RV516 : Radeon X1300, X1550, X1550 64-bit, X1600; FireMV 2250. R520 : Radeon X1800; FireGL V5300, V7200, V7300, V7350. RV530 : Radeon X1300 XT, X1600, X1600 Pro, X1650; FireGL V3400, V5200. RV535 : Radeon X1300, X1650. RV550 : Radeon X2300 HD. RV560 : Radeon X1650. RV570 : Radeon X1950, X1950 GT; FireGL V7400. R580 : Radeon X1900, X1950; AMD Stream Processor. R600 : Radeon HD 2900 GT/Pro/XT; FireGL V7600/V8600/V8650. RV610 : Radeon HD 2350, HD 2400 Pro/XT, HD 2400 Pro AGP; FireGL V4000. RV620 : Radeon HD 3450, HD 3470. RV630 : Radeon HD 2600 LE/Pro/XT, HD 2600 Pro/XT AGP; Gemini RV630; FireGL V3600/V5600. RV635 : Radeon HD 3650, HD 3670. RV670 : Radeon HD 3690, 3850, HD 3870, FireGL V7700, FireStream 9170. R680 : Radeon HD 3870 X2. M52 : Mobility Radeon X1300. M54 : Mobility Radeon X1400; M54-GL. M56 : Mobility Radeon X1600; Mobility FireGL V5200. M58 : Mobility Radeon X1800, X1800 XT; Mobility FireGL V7100, V7200. M62 : Mobility Radeon X1350. M64 : Mobility Radeon X1450, X2300. M66 : Mobility Radeon X1700, X1700 XT; FireGL V5250. M68 : Mobility Radeon X1900. M71 : Mobility Radeon HD 2300. M72 : Mobility Radeon HD 2400; Radeon E2400. M74 : Mobility Radeon HD 2400 XT. M76 : Mobility Radeon HD 2600; (Gemini ATI) Mobility Radeon HD 2600 XT. M82 : Mobility Radeon HD 3400. M86 : Mobility Radeon HD 3650, HD 3670, Mobility FireGL V5700. M88 : Mobility Radeon HD 3850, HD 3850 X2, HD 3870, HD3870 X2. RS600 : Radeon Xpress 1200, Xpress 1250. RS690 : Radeon X1200, X1250, X1270. RS740 : RS740, RS740M. RS780 : Radeon HD 3100/3200/3300 Series. RV770 : Radeon HD 4800 Series; Everest, K2, Denali ATI FirePro. R700 : Radeon R700. M98 : Radeon M98 Mobility. RV730 : Radeon HD4670, HD4650. M96 : Radeon M96 Mobility. RV710 : Radeon HD4570, HD4350. (II) RADEONHD: version 1.2.4, built from dist of git branch master, commit 4e897263 (II) Primary Device is: PCI 01@00:00:0 (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) resource ranges after probing: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [5] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [6] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [7] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [8] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [9] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [10] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (**) RADEONHD(0): Depth 24, (--) framebuffer bpp 32 (**) RADEONHD(0): Selected ShadowFB. (II) RADEONHD(0): Unknown card detected: 0x9490:0x1462:0x1590. If - and only if - your card does not work or does not work optimally please contact radeonhd@opensuse.org to help rectify this. Use the subject: 0x9490:0x1462:0x1590: and *please* describe the problems you are seeing in your message. (--) RADEONHD(0): Detected an RV730 on an unidentified card (EE) RADEONHD(0): Failed to map MMIO. (II) RADEONHD(0): Query for AtomBIOS Teardown: failed (II) UnloadModule: "radeonhd" (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found --------------060900050109030703000103-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 08:55: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 E373E1065735; Thu, 16 Apr 2009 08:55:46 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9E8E28FC12; Thu, 16 Apr 2009 08:55:46 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1LuNNo-0006KT-It>; Thu, 16 Apr 2009 10:55:45 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1LuNNf-0004R8-SL>; Thu, 16 Apr 2009 10:55:44 +0200 Message-ID: <49E6F231.7010803@zedat.fu-berlin.de> Date: Thu, 16 Apr 2009 08:54:09 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.21 (X11/20090415) MIME-Version: 1.0 To: freebsd-questions@freebsd.org, freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: firefox3 gets stuck/freezing for 30 seconds every 30 seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 08:55:49 -0000 Since a week now my firefox3 got stuck and freezing for 30 seconds (approx.) every 30 seconds. I'm running a SMP box with FreeBSD 8.0-CURRENT/amd64, OS is most recent. I also recompiled firefox3, dbus, libX11 and xcb (maybe senseless since I do not know what causes the freezing/hungs), but without success. By the way, perl-5.10 is installed and every port has been recompiled depending on perl. So ... I'm floating like a dead man in the water. What can I do? Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 08:57: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 B1211106574B; Thu, 16 Apr 2009 08:57:25 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 517098FC14; Thu, 16 Apr 2009 08:57:25 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1LuNPQ-0007Co-HI>; Thu, 16 Apr 2009 10:57:24 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1LuNPQ-0004mt-FQ>; Thu, 16 Apr 2009 10:57:24 +0200 Message-ID: <49E6F29E.7050004@zedat.fu-berlin.de> Date: Thu, 16 Apr 2009 08:55:58 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.21 (X11/20090415) MIME-Version: 1.0 To: vehemens References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090415160311.2e898844@ernst.jennejohn.org> <49E5EE04.1050208@zedat.fu-berlin.de> <200904152053.56058.vehemens@verizon.net> <49E6E833.3010105@zedat.fu-berlin.de> In-Reply-To: <49E6E833.3010105@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-x11 , freebsd-current@freebsd.org, Martin Subject: Re: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 08:57:27 -0000 O. Hartmann wrote: > vehemens wrote: >> On Wednesday 15 April 2009 07:24:04 am O. Hartmann wrote: >>> Gary Jennejohn wrote: >>>> On Wed, 15 Apr 2009 10:07:59 +0000 >>>> >>>> "O. Hartmann" wrote: >>>>> Gary Jennejohn wrote: >>>>>> On Wed, 15 Apr 2009 06:55:44 +0000 >>>>>> >>>>>> "O. Hartmann" wrote: >>>>>>> Martin wrote: >>>>>>>> Am Tue, 14 Apr 2009 18:08:54 +0200 >>>>>>>> >>>>>>>> schrieb "O. Hartmann" : >>>>>>>>> [...] >>>>>>>> Hi, >>>>>>>> >>>>>>>> if you have problems with the radeonhd driver, you should tell the >>>>>>>> guys who work at it. They are really nice and try to help >>>>>>>> everywhere. >>>>>>>> >>>>>>>> Subscribe there: >>>>>>>> http://lists.opensuse.org/radeonhd/ >>>>>>>> >>>>>>>> I am only using radeonhd, because it works for me on all cards I >>>>>>>> have. >>>>>>>> >>>>>>>> I noticed that window movement may get choppy, when you compile >>>>>>>> a new >>>>>>>> kernel (DRM) and don't recompile a fresh radeonhd driver. This >>>>>>>> happens especially when DRI is enabled for your xorg server. >>>>>>>> >>>>>>>> -- >>>>>>>> Martin >>>>>>> As far as I know, radeonhd from ports doesn't work with DRI >>>>>>> enabled on >>>>>>> FreeBSD - so it doesn't work on my box either. I guess you're >>>>>>> following the recommendations using the development brnach directly >>>>>>> from GIT. >>>>>> Works for me on amd64 8-current. >>>>>> >>>>>> garyj:ernst:~:-bash:4> grep DRI /var/log/Xorg.0.log >>>>>> (II) Loading extension XFree86-DRI >>>>>> (II) Loading extension DRI2 >>>>>> (**) RADEONHD(0): Option "DRI" >>>>>> (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x024B4000 >>>>>> (size = 0x00B13000) (II) RADEONHD(0): FB: Allocated DRI Depth >>>>>> Buffer at >>>>>> offset 0x02FC7000 (size = 0x00B13000) (II) RADEONHD(0): FB: Allocated >>>>>> DRI Textures at offset 0x03ADA000 (size = 0x0C400000) (II) >>>>>> RADEONHD(0): >>>>>> [DRI] installation complete >>>>>> (II) GLX: Initialized DRISWRAST GL provider for screen 0 >>>>>> garyj:ernst:~:-bash:5> ls -d /var/db/pkg/*radeon* >>>>>> drwxr-xr-x 2 root wheel 512 Apr 14 11:32 >>>>>> /var/db/pkg/xf86-video-radeonhd-devel-1.2.5.20090412 >>>>> Tried radeonhd-devel and failed also! >>>>> >>>>> When enabling DRI in config file, I see the XDM login box and the box >>>>> crashes and freezes immediately. Without DRI radeonhd-devel is >>>>> horrible >>>>> slow when moving windows around - inacceptable. It doesn't matter >>>>> whether EXA is enabled or not and the phenomenon ist the same as with >>>>> the regular radeonhd-driver from xorg-drivers. >>>>> >>>>> I'm back with the VESA driver. >>>> Hmm. Are the drm and radeondrm in your kernel up-to-date? Your >>>> posting >>>> was chopped by the first replier and I can't remember. >>>> >>>> Can't think of anything else. >>>> >>>> I personally don't use xdm/gdm/kdm. I just use startx. >>>> >>>> --- >>>> Gary Jennejohn >>> The kernel modules 'radeon' and 'drm' are loaded via /boot/loader.conf >>> when booting and they are up to date (I do a buildworld on a regular >>> basis these days and it takes ~30 minutes for a quad core box). >>> >>> Even when not starting X via xdm, the box crashes immediately, freezes >>> and is only 'revivable' by cold resetting. This happens with driver >>> radeonhd and enabled DRI. Without DRI the radeonhd driver works, but >>> moving a window looks like on Windooze when using standard VGA driver >>> without acceleration (this is bot with EXA on or off) - scrolling and >>> moving objects is really choppy. >>> >>> 'radeon' doesn't even show up anything, freezes the box as well as >>> 'radeonhd', but no matter whether DRI enabled or not. >>> >>> At home I will test radeonhd-devel with the RV770LE chipset (here I have >>> only RV730). The RV770LE seems not to be recognized by 'radeonhd', but >>> works fine with 'radeon'. But in both cases, DRI enabled crashes the >>> box. >> >> Could you post your xorg.conf? >> >> > > Well, > next round. > > First some notices. All probem occure at the very moment on FreeBSD > 8.0-CURRENT/amd64 due to the fact I do not have any i386 box and I'm not > running any graphical 7.X-based boxes. > > So, here we go. My private box is a UP machine equipted with a RV770LE > based graphicscard (MSI R4830). Yesterday I replaced the 'radeon' driver > from xf86-video-ati with 'radeonhd' from xf86-video-radeonhd-devel (most > recent in ports). Without DRI enabled, this driver is as horrible choppy > as I mentioned before. But with all the DRI and EXA stuff enabled, it is > as fast as the 'radeon' driver, no difference. > > On my lab's box the picture is different. This box is a quadcore Q6600 > based box, P35 chipset (for PCIe-specs), SMP. > This box doesn't work with 'radeon', it crashes immediateley. Using > 'radeonhd', either from xf86-video-radeonhd or xf86-video-radeonhd-devel > leaves my desktop as choppy as unaccelerated. But enabling DRI crahes > the box immediately. > > Attached you'll find my xorg.conf (at the moment with the VESA driver > enabled) and the last Xorg.0.log when the box crashed. It surprises me > that there is no evidence of 'RADEONHD' loaded, only 'VESA'. I hope Xorg > writes a logfile before killing itself. > > A comment to the driver section of my xorg.conf: I also commented out > everything but Options DRI and EXA without success. > > Files named Xorg.log.XXX are older files and results of experiments with > the regular, non-devel-drivers and dated from the 26. March this year, I > put them also into the attachment, for your convenience. > > Regards, > Oliver > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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" Please forget about the log file 'Xorg.0.log'. X-server does not write properly a suitable log, so the log is always the last successfully written log. I tried starting X via 'startx', redirecting the log, but whenever the server starts, the box crashes/reboots. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 09:27: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 5AC6B106566B for ; Thu, 16 Apr 2009 09:27:40 +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 E2E648FC19 for ; Thu, 16 Apr 2009 09:27:39 +0000 (UTC) (envelope-from gavin@FreeBSD.org) 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 n3G9RXGN022966; Thu, 16 Apr 2009 10:27:33 +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 1LuNsb-0005dT-72; Thu, 16 Apr 2009 10:27:33 +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 n3G9RWKB013211; Thu, 16 Apr 2009 10:27:32 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n3G9RW8Z013210; Thu, 16 Apr 2009 10:27:32 +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: Nenhum_de_Nos In-Reply-To: <00652174bdc7334a1a2d3d8db7c667a7.squirrel@10.1.1.10> References: <00652174bdc7334a1a2d3d8db7c667a7.squirrel@10.1.1.10> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 16 Apr 2009 10:27:31 +0100 Message-Id: <1239874051.12971.1.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: ata and seagate microdrive problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 09:27:41 -0000 On Thu, 2009-04-09 at 19:03 -0300, Nenhum_de_Nos wrote: > hail, > > I'm trying to install current on via itx using ide 44pin to cf adapter and > a seagate 8GB microdrive. > > I thought it was to be ok, but just today when I received the adapter I > got nowhere in this. I tried 7.1-STABLE and 8.0-CURRENT from 200902, and > both fail to find it. the same thing in 7.1R. Can you boot in verbose mode, and post the dmesg somewhere please? Also, can you confirm which ATA channel the drive should show up on? Thanks, Gavin > I found this http://forums.freebsd.org/archive/index.php/t-2733.html, but > hw.ata.ata_dma_check_80pin=0 is no good :( > > and found this pr > http://lists.freebsd.org/pipermail/freebsd-bugs/2007-March/022884.html as > the only pr that mentions microdrive (I may be wrong). From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 09:52: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 A827D106566B for ; Thu, 16 Apr 2009 09:52:14 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from airy.salford.ac.uk (airy.salford.ac.uk [146.87.0.11]) by mx1.freebsd.org (Postfix) with SMTP id 374158FC0C for ; Thu, 16 Apr 2009 09:52:13 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 58273 invoked by uid 98); 16 Apr 2009 10:52:12 +0100 Received: from 146.87.255.121 by airy.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.94.2/9245. spamassassin: 3.2.4. Clear:RC:1(146.87.255.121):. Processed in 0.043905 secs); 16 Apr 2009 09:52:12 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by airy.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Thu, 16 Apr 2009 10:52:12 +0100 Received: (qmail 91751 invoked by uid 1002); 16 Apr 2009 09:52:10 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Apr 2009 09:52:10 -0000 Date: Thu, 16 Apr 2009 10:52:10 +0100 (BST) From: "Mark Powell" To: "James R. Van Artsdalen" In-Reply-To: <49E69F7C.9020402@jrv.org> Message-ID: <20090416104803.O88758@rust.salford.ac.uk> References: <49E4CED7.2040206@jrv.org> <49E69F7C.9020402@jrv.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1115800636-1239875530=:88758" Cc: freebsd-current@freebsd.org Subject: Re: ata FLUSHCACHE timeout errors? [patch] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 09:52:15 -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. --0-1115800636-1239875530=:88758 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Wed, 15 Apr 2009, James R. Van Artsdalen wrote: > James R. Van Artsdalen wrote: >> I am getting many FLUSHCACHE timeout errors during "zfs recv" operations. > > This patch fixes this. PR to be filed. > In addition this causes any ata request that times out to print the > timeout, since it's going to be the timeout itself that's likely wrong. This is well known and had been repeated ad. inf.. Problem is, it never got addressed: http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting Attached is an 8-CURRENT patch which makes the ata timeout a tuneable. Shamelessy ripped off the FreeNAS patch on the above url. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information & Learning Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 5888 www.pgp.com for PGP key --0-1115800636-1239875530=:88758 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=patch.ata_to.fbsd8.diff Content-Transfer-Encoding: BASE64 Content-ID: <20090416105210.R88758@rust.salford.ac.uk> Content-Description: Content-Disposition: attachment; filename=patch.ata_to.fbsd8.diff LS0tIGF0YS1hbGwuYy5vcmlnCTIwMDktMDMtMTkgMTQ6MDA6MzYuMDAwMDAw MDAwICswMDAwDQorKysgYXRhLWFsbC5jCTIwMDktMDMtMTkgMTQ6MDQ6NTUu MDAwMDAwMDAwICswMDAwDQpAQCAtNzUsNiArNzUsNyBAQA0KIHVtYV96b25l X3QgYXRhX3JlcXVlc3Rfem9uZTsNCiB1bWFfem9uZV90IGF0YV9jb21wb3Np dGVfem9uZTsNCiBpbnQgYXRhX3djID0gMTsNCitpbnQgYXRhX3RvID0gNTsN CiBpbnQgYXRhX3NldG1heCA9IDA7DQogaW50IGF0YV9kbWFfY2hlY2tfODBw aW4gPSAxOw0KIA0KQEAgLTk3LDYgKzk4LDkgQEANCiBUVU5BQkxFX0lOVCgi aHcuYXRhLndjIiwgJmF0YV93Yyk7DQogU1lTQ1RMX0lOVChfaHdfYXRhLCBP SURfQVVUTywgd2MsIENUTEZMQUdfUkRUVU4sICZhdGFfd2MsIDAsDQogCSAg ICJBVEEgZGlzayB3cml0ZSBjYWNoaW5nIik7DQorVFVOQUJMRV9JTlQoImh3 LmF0YS50byIsICZhdGFfdG8pOw0KK1NZU0NUTF9JTlQoX2h3X2F0YSwgT0lE X0FVVE8sIHRvLCBDVExGTEFHX1JXLCAmYXRhX3RvLCAwLA0KKwkgICAiQVRB IGRpc2sgdGltZW91dCB2aXMtYS12aXMgcG93ZXItc2F2aW5nIik7DQogVFVO QUJMRV9JTlQoImh3LmF0YS5zZXRtYXgiLCAmYXRhX3NldG1heCk7DQogU1lT Q1RMX0lOVChfaHdfYXRhLCBPSURfQVVUTywgc2V0bWF4LCBDVExGTEFHX1JE VFVOLCAmYXRhX3NldG1heCwgMCwNCiAJICAgIkFUQSBkaXNrIHNldCBtYXgg bmF0aXZlIGFkZHJlc3MiKTsNCi0tLSBhdGEtYWxsLmgub3JpZwkyMDA5LTAz LTE5IDE0OjAwOjM2LjAwMDAwMDAwMCArMDAwMA0KKysrIGF0YS1hbGwuaAky MDA5LTAzLTE5IDE0OjA1OjMxLjAwMDAwMDAwMCArMDAwMA0KQEAgLTU0NSw2 ICs1NDUsNyBAQA0KIGV4dGVybiBzdHJ1Y3QgaW50cl9jb25maWdfaG9vayAq YXRhX2RlbGF5ZWRfYXR0YWNoOw0KIGV4dGVybiBkZXZjbGFzc190IGF0YV9k ZXZjbGFzczsNCiBleHRlcm4gaW50IGF0YV93YzsNCitleHRlcm4gaW50IGF0 YV90bzsNCiBleHRlcm4gaW50IGF0YV9zZXRtYXg7DQogZXh0ZXJuIGludCBh dGFfZG1hX2NoZWNrXzgwcGluOw0KIA0KLS0tIGF0YS1kaXNrLmMub3JpZwky MDA5LTAzLTE5IDE0OjAwOjM2LjAwMDAwMDAwMCArMDAwMA0KKysrIGF0YS1k aXNrLmMJMjAwOS0wMy0xOSAxNDowNjo0MS4wMDAwMDAwMDAgKzAwMDANCkBA IC0yMzAsNyArMjMwLDcgQEANCiAgICAgfQ0KICAgICByZXF1ZXN0LT5kZXYg PSBkZXY7DQogICAgIHJlcXVlc3QtPmZsYWdzID0gQVRBX1JfQ09OVFJPTDsN Ci0gICAgcmVxdWVzdC0+dGltZW91dCA9IDU7DQorICAgIHJlcXVlc3QtPnRp bWVvdXQgPSBhdGFfdG87DQogICAgIHJlcXVlc3QtPnJldHJpZXMgPSAxOw0K ICAgICByZXF1ZXN0LT5jYWxsYmFjayA9IGFkX3Bvd2VyX2NhbGxiYWNrOw0K ICAgICByZXF1ZXN0LT51LmF0YS5jb21tYW5kID0gQVRBX1NUQU5EQllfSU1N RURJQVRFOw0KQEAgLTI2NSw3ICsyNjUsNyBAQA0KIAlyZXF1ZXN0LT50aW1l b3V0ID0gMzE7DQogICAgIH0NCiAgICAgZWxzZSB7DQotCXJlcXVlc3QtPnRp bWVvdXQgPSA1Ow0KKwlyZXF1ZXN0LT50aW1lb3V0ID0gYXRhX3RvOw0KICAg ICB9DQogICAgIHJlcXVlc3QtPnJldHJpZXMgPSAyOw0KICAgICByZXF1ZXN0 LT5kYXRhID0gYnAtPmJpb19kYXRhOw0KQEAgLTQ2MCw3ICs0NjAsNyBAQA0K ICAgICByZXF1ZXN0LT51LmF0YS5jb3VudCA9IDA7DQogICAgIHJlcXVlc3Qt PnUuYXRhLmZlYXR1cmUgPSAwOw0KICAgICByZXF1ZXN0LT5mbGFncyA9IEFU QV9SX0NPTlRST0wgfCBBVEFfUl9RVUlFVDsNCi0gICAgcmVxdWVzdC0+dGlt ZW91dCA9IDU7DQorICAgIHJlcXVlc3QtPnRpbWVvdXQgPSBhdGFfdG87DQog ICAgIHJlcXVlc3QtPnJldHJpZXMgPSAwOw0KICAgICBhdGFfcXVldWVfcmVx dWVzdChyZXF1ZXN0KTsNCiAgICAgaWYgKHJlcXVlc3QtPnN0YXR1cyAmIEFU QV9TX0VSUk9SKQ0KQEAgLTQ3OSw3ICs0NzksNyBAQA0KICAgICByZXF1ZXN0 LT51LmF0YS5jb3VudCA9IDE7DQogICAgIHJlcXVlc3QtPnUuYXRhLmZlYXR1 cmUgPSAwOw0KICAgICByZXF1ZXN0LT5mbGFncyA9IEFUQV9SX0NPTlRST0w7 DQotICAgIHJlcXVlc3QtPnRpbWVvdXQgPSA1Ow0KKyAgICByZXF1ZXN0LT50 aW1lb3V0ID0gYXRhX3RvOw0KICAgICByZXF1ZXN0LT5yZXRyaWVzID0gMDsN CiAgICAgYXRhX3F1ZXVlX3JlcXVlc3QocmVxdWVzdCk7DQogICAgIGlmIChy ZXF1ZXN0LT5zdGF0dXMgJiBBVEFfU19FUlJPUikNCg== --0-1115800636-1239875530=:88758-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 09:56: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 D39BE1065672 for ; Thu, 16 Apr 2009 09:56:49 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 627608FC0C for ; Thu, 16 Apr 2009 09:56:48 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id n3G9ubKo009721; Thu, 16 Apr 2009 11:56:38 +0200 Received: from webmail.entel.upc.edu (www-entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 52C982CBD07; Thu, 16 Apr 2009 11:56:41 +0200 (CEST) Received: from 147.83.40.68 by webmail.entel.upc.edu with HTTP; Thu, 16 Apr 2009 11:56:41 +0200 (CEST) Message-ID: <55169.147.83.40.68.1239875801.squirrel@webmail.entel.upc.edu> In-Reply-To: <49E6F231.7010803@zedat.fu-berlin.de> References: <49E6F231.7010803@zedat.fu-berlin.de> Date: Thu, 16 Apr 2009 11:56:41 +0200 (CEST) From: "Gustavo Perez Querol" To: "O. Hartmann" User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Thu, 16 Apr 2009 11:56:38 +0200 (CEST) Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: firefox3 gets stuck/freezing for 30 seconds every 30 seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 09:56:50 -0000 > Since a week now my firefox3 got stuck and freezing for 30 seconds > (approx.) every 30 seconds. I'm running a SMP box with FreeBSD > 8.0-CURRENT/amd64, OS is most recent. > > I also recompiled firefox3, dbus, libX11 and xcb (maybe senseless since > I do not know what causes the freezing/hungs), but without success. By > the way, perl-5.10 is installed and every port has been recompiled > depending on perl. So ... I'm floating like a dead man in the water. > What can I do? Something like this happened to me. I have i386 CURRENT cvsup'ed yesterday. Do you have flash support with nspluginwrapper ? Do you have linux-f8 and compat.linux.osrelease=2.6.16 ? If both are true, please try compat.linux.osrelease=2.4.2 and switch back to f4. With these settings problems vanished in my case, may be they will work for you too. Looks like linux 2.6.16 emulation has problems with flash9. Can anyone confirm this ? Regards, Gus > > Regards, > Oliver > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 07:45: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 17E471065674; Thu, 16 Apr 2009 07:45:54 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id D79EE8FC16; Thu, 16 Apr 2009 07:45:53 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id n3G7GAOU039725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 00:16:10 -0700 (PDT) (envelope-from sobomax@sippysoft.com) Message-ID: <49E6DB25.2010601@sippysoft.com> Date: Thu, 16 Apr 2009 00:15:49 -0700 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Sam Leffler Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 16 Apr 2009 11:42:19 +0000 Cc: stable@FreeBSD.org, "current@freebsd.org" Subject: kernel compile fails without AH_SUPPORT_AR5416 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 07:45:54 -0000 Sam, What is the reason to have this option in the kernel config if kernel compilation fails when this option is enabled? It also affects 7-stable. cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/dev/ath/if_ath.c -I/usr/src/sys/dev/ath /usr/src/sys/dev/ath/if_ath.c: In function 'ath_rx_tap': /usr/src/sys/dev/ath/if_ath.c:3414: error: 'const struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/if_ath.c:3416: error: 'const struct ath_rx_status' has no member named 'rs_flags' -Maxim From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 09:51:35 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6969F106566C; Thu, 16 Apr 2009 09:51:35 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 15C588FC18; Thu, 16 Apr 2009 09:51:34 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id n3G9pXGQ041361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 02:51:34 -0700 (PDT) (envelope-from sobomax@sippysoft.com) Message-ID: <49E6FF8F.4070403@sippysoft.com> Date: Thu, 16 Apr 2009 02:51:11 -0700 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dennis Melentyev References: <49E6DB25.2010601@sippysoft.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 16 Apr 2009 11:42:28 +0000 Cc: stable@freebsd.org, Sam Leffler , "current@freebsd.org" Subject: Re: kernel compile fails without AH_SUPPORT_AR5416 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 09:51:35 -0000 Dennis Melentyev wrote: > Could be worth an entry in UPDATING and/or explicitly added to GENERIC. My point is that if the option is mandatory for compiling ath(4) driver, then there is no point in having this option in the first place. -Maxim From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 10:09:35 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5D3210657EF; Thu, 16 Apr 2009 10:09:35 +0000 (UTC) (envelope-from dennis.melentyev@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id DC70C8FC12; Thu, 16 Apr 2009 10:09:34 +0000 (UTC) (envelope-from dennis.melentyev@gmail.com) Received: by bwz8 with SMTP id 8so317362bwz.43 for ; Thu, 16 Apr 2009 03:09:33 -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=joCfI6aGudiiOSnzl+8q0uLCkNKJTwbrqK/1NjouYkw=; b=qNY+0IoEQ/T6SuUcZf+V5fVfg3wipvSJI2poelXbrqLFFnZSwPXz48oZRD1AABL/S2 uK+9bNc1CxWD/O73M51mol7TqF43K29kcB9EG34XAj6WU40jGmSfHdmr12Cc9bynihRY 23jdQpd9jXXq69YlR1MFo+cixvE0hwUGigMbI= 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=WbwnOCObH+1YkzqbQETelcXAOY3Vufl/2SvQUEx08FGkuDrRIU4He2GYborQt/dJKf Fg2MPV6EC3fMZDVpXioV6/WYBkem9f9dGJ+oksYL9DQLmauc3/fYcrPSnrYiW/N4dRhK nkMnPJo8hQhUVOS1FVNyoegBRw8UonftfdMYM= MIME-Version: 1.0 Received: by 10.204.115.67 with SMTP id h3mr1053896bkq.173.1239874682637; Thu, 16 Apr 2009 02:38:02 -0700 (PDT) In-Reply-To: <49E6DB25.2010601@sippysoft.com> References: <49E6DB25.2010601@sippysoft.com> Date: Thu, 16 Apr 2009 12:38:02 +0300 Message-ID: From: Dennis Melentyev To: Maxim Sobolev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 16 Apr 2009 11:42:47 +0000 Cc: stable@freebsd.org, Sam Leffler , "current@freebsd.org" Subject: Re: kernel compile fails without AH_SUPPORT_AR5416 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 10:09:40 -0000 Hi Max, Also seen that. Fixed with careful merging on my kernel config with GENERIC one. There are additional strings involved: device ath device ath_rate_sample After adding the later one (and probably, the first one too (?)) compiled o= k. Could be worth an entry in UPDATING and/or explicitly added to GENERIC. /dennis 2009/4/16 Maxim Sobolev : > Sam, > > What is the reason to have this option in the kernel config if kernel > compilation fails when this option is enabled? It also affects 7-stable. > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing =C2=A0-std=3Dc99 = -g -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototyp= es > -Wpointer-arith -Winline -Wcast-qual =C2=A0-Wundef -Wno-pointer-sign > -fformat-extensions -nostdinc =C2=A0-I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inclu= de > opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D100 > --param large-function-growth=3D1000 -mcmodel=3Dkernel -mno-red-zone > =C2=A0-mfpmath=3D387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow =C2=A0-msoft-= float > -fno-asynchronous-unwind-tables -ffreestanding -Werror > =C2=A0/usr/src/sys/dev/ath/if_ath.c -I/usr/src/sys/dev/ath > /usr/src/sys/dev/ath/if_ath.c: In function 'ath_rx_tap': > /usr/src/sys/dev/ath/if_ath.c:3414: error: 'const struct ath_rx_status' h= as > no member named 'rs_flags' > /usr/src/sys/dev/ath/if_ath.c:3416: error: 'const struct ath_rx_status' h= as > no member named 'rs_flags' > > -Maxim > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > --=20 Dennis Melentyev From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 11:41: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 7D61E106566C; Thu, 16 Apr 2009 11:41:32 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by mx1.freebsd.org (Postfix) with ESMTP id C9CC28FC21; Thu, 16 Apr 2009 11:39:36 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.20] (helo=10.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #88) id 1LuPwN-0003TA-Lh; Thu, 16 Apr 2009 13:39:35 +0200 Received: from tcf8a.t.pppool.de ([89.55.207.138]:30482 helo=ernst.jennejohn.org) by 10.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1LuPwN-0000td-FB; Thu, 16 Apr 2009 13:39:35 +0200 Date: Thu, 16 Apr 2009 13:39:34 +0200 From: Gary Jennejohn To: "O. Hartmann" Message-ID: <20090416133934.40427f74@ernst.jennejohn.org> In-Reply-To: <49E6F29E.7050004@zedat.fu-berlin.de> References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090415160311.2e898844@ernst.jennejohn.org> <49E5EE04.1050208@zedat.fu-berlin.de> <200904152053.56058.vehemens@verizon.net> <49E6E833.3010105@zedat.fu-berlin.de> <49E6F29E.7050004@zedat.fu-berlin.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-x11 , freebsd-current@freebsd.org Subject: Re: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! 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: Thu, 16 Apr 2009 11:41:33 -0000 On Thu, 16 Apr 2009 08:55:58 +0000 "O. Hartmann" wrote: [very large snip - radeonhd with dri kills Xorg] > Please forget about the log file 'Xorg.0.log'. X-server does not write > properly a suitable log, so the log is always the last successfully > written log. > So it's crashing before it can even write the log. > I tried starting X via 'startx', redirecting the log, but whenever the > server starts, the box crashes/reboots. > No crash dump from the kernel? How about starting it in gdb? That might give you a chance to narrow down where it's crashing, if gdb can stop it before the box crashes. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 12:19: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 AFE971065678 for ; Thu, 16 Apr 2009 12:19:09 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay10.ispgateway.de (smtprelay10.ispgateway.de [80.67.29.24]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD548FC19 for ; Thu, 16 Apr 2009 12:19:09 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [62.143.132.243] (helo=localhost) by smtprelay10.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LuQYe-0005Uo-51 for freebsd-current@freebsd.org; Thu, 16 Apr 2009 14:19:08 +0200 Date: Thu, 16 Apr 2009 14:18:55 +0200 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20090416141855.75ff5184@fabiankeil.de> In-Reply-To: References: X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/1kDxBHLvUAAkAayjueo3Qyy"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Df-Sender: 775067 Subject: Re: [patch] prevent atkbd(4) from calling callback in polled 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: Thu, 16 Apr 2009 12:19:09 -0000 --Sig_/1kDxBHLvUAAkAayjueo3Qyy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Maksim Yevmenkin wrote: > would anyone object to the small attached atkbd(4) patch? the idea is > to basically prevent atkbd(4) interrupt handler from calling keyboard > callback function when polled mode is enabled. >=20 > i would really like to hear from people who is using kbdmux(4) on smp > systems and having problems with duplicated/missing characters while > using keyboard at mountroot, geli, etc. prompts. basically, when low > level console input functions (cngetc(), gets(), etc.) are used _and_ > interrupts are enabled. Thanks. This version of your patch works for me, too. Fabian --Sig_/1kDxBHLvUAAkAayjueo3Qyy Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknnIjsACgkQBYqIVf93VJ2pTQCgv3ibdki9hfGR8yFI49uXlCEb eCIAnRnRzbEPOWiBrxrU0TDuiJhykyjw =Z1v1 -----END PGP SIGNATURE----- --Sig_/1kDxBHLvUAAkAayjueo3Qyy-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 13:23: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 5BFDC1065670 for ; Thu, 16 Apr 2009 13:23:05 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 189168FC13 for ; Thu, 16 Apr 2009 13:23:05 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (hyperion.scode.org [85.17.42.115]) by hyperion.scode.org (Postfix) with ESMTPS id C8C9C2394AA; Thu, 16 Apr 2009 15:23:03 +0200 (CEST) Date: Thu, 16 Apr 2009 15:23:02 +0200 From: Peter Schuller To: Artem Belevich Message-ID: <20090416132302.GA86096@hyperion.scode.org> References: <49C2CFF6.8070608@egr.msu.edu> <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org, Ben Kelly Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 13:23:05 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > BTW, now that you're tinkering with ZFS threads and priorities, whould > you by any chance have any idea why zfs scrub is so painfully slow on > -current? > When I start scrub on my -stable box, it pretty much runs full speed > -- I can see disks under load all the time. > However on -current scrub seems to run in small bursts. Disks get busy > for a second or so and then things get quiet for about five seconds or > so and this pattern repeats over and over. This is intentional. The newer ZFS code has, if I remember correctly, something like "spend at most 1/5 of the time doing scrub for each underlying vdev". I could be wrong on the details and I don't have source refs off-hand, by I looked into this when I wanted to see if I could tweak this (while I definitely like it rate limited, I would have liked to up the threshold a bit). My conclusion at the time was that there was no way to tweak it other than recompiling the kernel. --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknnMTYACgkQDNor2+l1i336pACggYkwt6NFavYiTKKYZ3OH9EEK oK0AmwVcai3KXjdYK/C2Yaa3/aRC4W4h =K1CW -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 13:32:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4312106566B; Thu, 16 Apr 2009 13:32:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 902EF8FC14; Thu, 16 Apr 2009 13:32:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3GDVveX016824; Thu, 16 Apr 2009 09:31:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3GDVuVq030894; Thu, 16 Apr 2009 09:31:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A4E6E7302F; Thu, 16 Apr 2009 09:31:56 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090416133156.A4E6E7302F@freebsd-current.sentex.ca> Date: Thu, 16 Apr 2009 09:31:56 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/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, 16 Apr 2009 13:32:02 -0000 TB --- 2009-04-16 12:48:34 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-16 12:48:34 - starting HEAD tinderbox run for i386/i386 TB --- 2009-04-16 12:48:34 - cleaning the object tree TB --- 2009-04-16 12:49:08 - cvsupping the source tree TB --- 2009-04-16 12:49:08 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-04-16 12:49:17 - building world TB --- 2009-04-16 12:49:17 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-16 12:49:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-16 12:49:17 - TARGET=i386 TB --- 2009-04-16 12:49:17 - TARGET_ARCH=i386 TB --- 2009-04-16 12:49:17 - TZ=UTC TB --- 2009-04-16 12:49:17 - __MAKE_CONF=/dev/null TB --- 2009-04-16 12:49:17 - cd /src TB --- 2009-04-16 12:49:17 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 16 12:49:18 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 [...] mkdep -f .depend -a /src/usr.sbin/rarpd/rarpd.c echo rarpd: /obj/src/tmp/usr/lib/libc.a >> .depend ===> usr.sbin/raycontrol (depend) rm -f .depend mkdep -f .depend -a -I/src/usr.sbin/raycontrol/../../sys /src/usr.sbin/raycontrol/raycontrol.c /src/usr.sbin/raycontrol/raycontrol.c:47:31: error: dev/ray/if_rayreg.h: No such file or directory /src/usr.sbin/raycontrol/raycontrol.c:48:31: error: dev/ray/if_raymib.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/usr.sbin/raycontrol. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-16 13:31:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-16 13:31:56 - ERROR: failed to build world TB --- 2009-04-16 13:31:56 - 1983.53 user 232.36 system 2602.05 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 14:15: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 47BD1106564A; Thu, 16 Apr 2009 14:15:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id E6E268FC19; Thu, 16 Apr 2009 14:15:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3GEFYF3024259; Thu, 16 Apr 2009 10:15:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3GEFYIh033297; Thu, 16 Apr 2009 10:15:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9E0DB7302F; Thu, 16 Apr 2009 10:15:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090416141534.9E0DB7302F@freebsd-current.sentex.ca> Date: Thu, 16 Apr 2009 10:15:34 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 14:15:38 -0000 TB --- 2009-04-16 13:31:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-16 13:31:56 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-04-16 13:31:56 - cleaning the object tree TB --- 2009-04-16 13:32:29 - cvsupping the source tree TB --- 2009-04-16 13:32:29 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-04-16 13:32:37 - building world TB --- 2009-04-16 13:32:37 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-16 13:32:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-16 13:32:37 - TARGET=pc98 TB --- 2009-04-16 13:32:37 - TARGET_ARCH=i386 TB --- 2009-04-16 13:32:37 - TZ=UTC TB --- 2009-04-16 13:32:37 - __MAKE_CONF=/dev/null TB --- 2009-04-16 13:32:37 - cd /src TB --- 2009-04-16 13:32:37 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 16 13:32:41 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 [...] mkdep -f .depend -a /src/usr.sbin/rarpd/rarpd.c echo rarpd: /obj/pc98/src/tmp/usr/lib/libc.a >> .depend ===> usr.sbin/raycontrol (depend) rm -f .depend mkdep -f .depend -a -I/src/usr.sbin/raycontrol/../../sys /src/usr.sbin/raycontrol/raycontrol.c /src/usr.sbin/raycontrol/raycontrol.c:47:31: error: dev/ray/if_rayreg.h: No such file or directory /src/usr.sbin/raycontrol/raycontrol.c:48:31: error: dev/ray/if_raymib.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/usr.sbin/raycontrol. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-16 14:15:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-16 14:15:34 - ERROR: failed to build world TB --- 2009-04-16 14:15:34 - 1977.58 user 239.23 system 2617.91 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 14:42: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 998B2106566B for ; Thu, 16 Apr 2009 14:42:56 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay4-v.mail.gandi.net (relay4-v.mail.gandi.net [217.70.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 32D9F8FC23 for ; Thu, 16 Apr 2009 14:42:56 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from plebeian.afflictions.org (CPE0021296fd1ec-CM0019475d4056.cpe.net.cable.rogers.com [99.241.164.229]) by relay4-v.mail.gandi.net (Postfix) with ESMTP id 78F07BA47 for ; Thu, 16 Apr 2009 16:42:54 +0200 (CEST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id D84853056; Thu, 16 Apr 2009 10:42:51 -0400 (EDT) Date: Thu, 16 Apr 2009 10:42:51 -0400 From: Damian Gerow To: freebsd-current@freebsd.org Message-ID: <20090416144251.GA1605@plebeian.afflictions.org> References: <49BD117B.2080706@163.com> <012d01c9b706$ccace720$6606b560$@Sparrevohn@btinternet.com> <20090409003108.fe768d54.nork@FreeBSD.org> <200904131304.43585.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904131304.43585.jhb@freebsd.org> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 14:42:57 -0000 John Baldwin wrote: : I have no idea how this would break what you are seeing. The : zfs_get_xattrdir() function is only called from zfs_lookup() when : LOOKUP_XATTR is specified, and that only happens from the extended attribute : VOP routines. Are you using extended attributes at all? Also, have you : tried running with INVARIANTS and DEBUG_VFS_LOCKS to catch missing locks? I've spent most of the past week running tests, with various combinations, against sources dating back about two weeks ago. I've been using a standard GENERIC kernel with two modifications: I've removed umass, and added DEBUG_VFS_LOCKS. I also set vfs.zfs.debug=1, where debug.vfs_* and debug.mpsafevfs are all kept at their defaults of 1. What I've found: 1) Reverting the extended attribute locking change (r189967) does not change the situation for me. I still experience checksum issues and data loss. (Unsurprisingly.) 2) Without umass loaded, I have been completely unable to trigger the issue. 3) Once umass is loaded, and the symptoms start cropping up, unloading umass does not make them go away (again, unsurprisingly). What I haven't yet tested, but am currently working towards, is whether removing umass stops further checksum errors from ocurring. 4) r189967 does remove some LORs for me, even though I don't use (that I know of) extended attributes. 5) It seems that so long as umass is used at all, the symptoms will eventually show up. I've been able to trigger the symptoms by inserting then removing a umass device immediately after boot, then ramping up the workload. 6) The only difference made by vfs.zfs.debug=1 is that zfs reclaims are logged. I'm at a bit of a loss as to what to test next, other than checking for an increased number of checksum errors after unloading umass. However, I'm not convinced this is going to highlight the actual problem. I'm all ears as to what to test for at this point, as I'm running out of ideas. A little less wordy: help? - Damian From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 14:45:46 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 87BED106564A; Thu, 16 Apr 2009 14:45:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 63C5F8FC22; Thu, 16 Apr 2009 14:45:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 054B546B03; Thu, 16 Apr 2009 10:45:46 -0400 (EDT) Date: Thu, 16 Apr 2009 15:45:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: FreeBSD Tinderbox In-Reply-To: <20090416133156.A4E6E7302F@freebsd-current.sentex.ca> Message-ID: References: <20090416133156.A4E6E7302F@freebsd-current.sentex.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, i386@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 14:45:47 -0000 On Thu, 16 Apr 2009, FreeBSD Tinderbox wrote: > mkdep -f .depend -a -I/src/usr.sbin/raycontrol/../../sys /src/usr.sbin/raycontrol/raycontrol.c > /src/usr.sbin/raycontrol/raycontrol.c:47:31: error: dev/ray/if_rayreg.h: No such file or directory > /src/usr.sbin/raycontrol/raycontrol.c:48:31: error: dev/ray/if_raymib.h: No such file or directory > mkdep: compile failed > *** Error code 1 Looks like I forgot to commit to usr.sbin when removing ray(4) -- I've now GC'd raycontrol as well. Sorry about that! Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 15:07:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0C46106571C; Thu, 16 Apr 2009 15:07:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6328FC2A; Thu, 16 Apr 2009 15:07:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3GF731J035494; Thu, 16 Apr 2009 11:07:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3GF73pn035104; Thu, 16 Apr 2009 11:07:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5F7187302F; Thu, 16 Apr 2009 11:07:03 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090416150703.5F7187302F@freebsd-current.sentex.ca> Date: Thu, 16 Apr 2009 11:07:03 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on 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, 16 Apr 2009 15:07:10 -0000 TB --- 2009-04-16 14:15:34 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-16 14:15:34 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-04-16 14:15:34 - cleaning the object tree TB --- 2009-04-16 14:16:06 - cvsupping the source tree TB --- 2009-04-16 14:16:06 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-04-16 14:16:15 - building world TB --- 2009-04-16 14:16:15 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-16 14:16:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-16 14:16:15 - TARGET=ia64 TB --- 2009-04-16 14:16:15 - TARGET_ARCH=ia64 TB --- 2009-04-16 14:16:15 - TZ=UTC TB --- 2009-04-16 14:16:15 - __MAKE_CONF=/dev/null TB --- 2009-04-16 14:16:15 - cd /src TB --- 2009-04-16 14:16:15 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 16 14:16:16 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 [...] mkdep -f .depend -a /src/usr.sbin/rarpd/rarpd.c echo rarpd: /obj/ia64/src/tmp/usr/lib/libc.a >> .depend ===> usr.sbin/raycontrol (depend) rm -f .depend mkdep -f .depend -a -I/src/usr.sbin/raycontrol/../../sys /src/usr.sbin/raycontrol/raycontrol.c /src/usr.sbin/raycontrol/raycontrol.c:47:31: error: dev/ray/if_rayreg.h: No such file or directory /src/usr.sbin/raycontrol/raycontrol.c:48:31: error: dev/ray/if_raymib.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/usr.sbin/raycontrol. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-16 15:07:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-16 15:07:03 - ERROR: failed to build world TB --- 2009-04-16 15:07:03 - 2394.88 user 236.08 system 3088.38 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 15:13:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE57110657B2; Thu, 16 Apr 2009 15:13:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5BDFE8FC16; Thu, 16 Apr 2009 15:13:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3GFDILX088548; Thu, 16 Apr 2009 11:13:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3GFDIqm041331; Thu, 16 Apr 2009 11:13:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1E4317302F; Thu, 16 Apr 2009 11:13:18 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090416151318.1E4317302F@freebsd-current.sentex.ca> Date: Thu, 16 Apr 2009 11:13:18 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 15:13:22 -0000 TB --- 2009-04-16 14:34:45 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-16 14:34:45 - starting HEAD tinderbox run for mips/mips TB --- 2009-04-16 14:34:45 - cleaning the object tree TB --- 2009-04-16 14:35:08 - cvsupping the source tree TB --- 2009-04-16 14:35:08 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-04-16 14:35:16 - building world TB --- 2009-04-16 14:35:16 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-16 14:35:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-16 14:35:16 - TARGET=mips TB --- 2009-04-16 14:35:16 - TARGET_ARCH=mips TB --- 2009-04-16 14:35:16 - TZ=UTC TB --- 2009-04-16 14:35:16 - __MAKE_CONF=/dev/null TB --- 2009-04-16 14:35:16 - cd /src TB --- 2009-04-16 14:35:16 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 16 14:35:18 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 [...] mkdep -f .depend -a /src/usr.sbin/rarpd/rarpd.c echo rarpd: /obj/mips/src/tmp/usr/lib/libc.a >> .depend ===> usr.sbin/raycontrol (depend) rm -f .depend mkdep -f .depend -a -I/src/usr.sbin/raycontrol/../../sys /src/usr.sbin/raycontrol/raycontrol.c /src/usr.sbin/raycontrol/raycontrol.c:47:31: error: dev/ray/if_rayreg.h: No such file or directory /src/usr.sbin/raycontrol/raycontrol.c:48:31: error: dev/ray/if_raymib.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/usr.sbin/raycontrol. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-16 15:13:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-16 15:13:18 - ERROR: failed to build world TB --- 2009-04-16 15:13:18 - 1717.05 user 225.09 system 2312.82 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 15:14: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 959F010656D5; Thu, 16 Apr 2009 15:14:55 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9232A8FC1D; Thu, 16 Apr 2009 15:14:54 +0000 (UTC) (envelope-from avg@icyb.net.ua) 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 SAA23407; Thu, 16 Apr 2009 18:14:52 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <49E74B6B.50100@icyb.net.ua> Date: Thu, 16 Apr 2009 18:14:51 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Diego Depaoli References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <200904150838.25099.jhb@freebsd.org> <83e5fb980904151627k726294deoe8feba8c0b7d5167@mail.gmail.com> <200904151943.51066.jkim@FreeBSD.org> <83e5fb980904151722p17d4210dqeca1c137683eebb0@mail.gmail.com> In-Reply-To: <83e5fb980904151722p17d4210dqeca1c137683eebb0@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: disklablel/gpart [Was: AMD 780G chipset major issues 3/3 (btx)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 15:14:56 -0000 on 16/04/2009 03:22 Diego Depaoli said the following: > On Thu, Apr 16, 2009 at 1:43 AM, Jung-uk Kim wrote: >>> After reboot I get BTX halted. >>> Perhaps bsdlabel -B works only upon a slice with 0X80 flag set? >>> Otherwise I don't know... >> It only works when there is no error. ;-) It seems you have to fix the >> label first. > Starting from this... > can be done without loosing data? You can try to do it with gpart, maybe it will like slices of your disks better :) http://lists.freebsd.org/pipermail/freebsd-geom/2009-April/003440.html E.g.: gpart bootcode -b /boot/boot ad10s1 Be warned that gpart says back something like "partition has boot code" and it's not terribly clear what is actually meant here: "it (already) has boot code, so I am not doing anything" or "I did my job and it (now) has boot code". It is the latter :-) P.S. I have a disk that was labeled from the very start with gpart - both gpart and disklabel treat it nice; another disk was lebeled with disklabel in pre-gpart environment and then moved to a gpart environment - gpart works good with this disk, but disklabel barks the same kind of messages. I guess that this happens because gpart hasn't reset to zero offset field of the special partition c when it adopted disklabel-authored label. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 15:51:33 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D91BB106566C; Thu, 16 Apr 2009 15:51:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7084D8FC14; Thu, 16 Apr 2009 15:51:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3GFpUVZ047271; Thu, 16 Apr 2009 11:51:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3GFpTcV069026; Thu, 16 Apr 2009 11:51:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 853CB7302F; Thu, 16 Apr 2009 11:51:29 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090416155129.853CB7302F@freebsd-current.sentex.ca> Date: Thu, 16 Apr 2009 11:51:29 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 15:51:34 -0000 TB --- 2009-04-16 15:07:03 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-16 15:07:03 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-04-16 15:07:03 - cleaning the object tree TB --- 2009-04-16 15:07:31 - cvsupping the source tree TB --- 2009-04-16 15:07:31 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-04-16 15:07:39 - building world TB --- 2009-04-16 15:07:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-16 15:07:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-16 15:07:39 - TARGET=powerpc TB --- 2009-04-16 15:07:39 - TARGET_ARCH=powerpc TB --- 2009-04-16 15:07:39 - TZ=UTC TB --- 2009-04-16 15:07:39 - __MAKE_CONF=/dev/null TB --- 2009-04-16 15:07:39 - cd /src TB --- 2009-04-16 15:07:39 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 16 15:07:42 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 [...] mkdep -f .depend -a /src/usr.sbin/rarpd/rarpd.c echo rarpd: /obj/powerpc/src/tmp/usr/lib/libc.a >> .depend ===> usr.sbin/raycontrol (depend) rm -f .depend mkdep -f .depend -a -I/src/usr.sbin/raycontrol/../../sys /src/usr.sbin/raycontrol/raycontrol.c /src/usr.sbin/raycontrol/raycontrol.c:47:31: error: dev/ray/if_rayreg.h: No such file or directory /src/usr.sbin/raycontrol/raycontrol.c:48:31: error: dev/ray/if_raymib.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/usr.sbin/raycontrol. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-16 15:51:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-16 15:51:29 - ERROR: failed to build world TB --- 2009-04-16 15:51:29 - 2031.80 user 233.81 system 2666.10 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 15:55: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 006221065677 for ; Thu, 16 Apr 2009 15:55:35 +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 C89E58FC1C for ; Thu, 16 Apr 2009 15:55:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7B71546B81; Thu, 16 Apr 2009 11:55:35 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 6C3008A01C; Thu, 16 Apr 2009 11:55:34 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 16 Apr 2009 11:45:38 -0400 User-Agent: KMail/1.9.7 References: <49BD117B.2080706@163.com> <200904131304.43585.jhb@freebsd.org> <20090416144251.GA1605@plebeian.afflictions.org> In-Reply-To: <20090416144251.GA1605@plebeian.afflictions.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904161145.38687.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 16 Apr 2009 11:55:34 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Damian Gerow Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 15:55:36 -0000 On Thursday 16 April 2009 10:42:51 am Damian Gerow wrote: > I'm at a bit of a loss as to what to test next, other than checking for an > increased number of checksum errors after unloading umass. However, I'm not > convinced this is going to highlight the actual problem. I'm all ears as to > what to test for at this point, as I'm running out of ideas. > > A little less wordy: help? Do your umass(4) drives use ZFS or some other filesystem? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 15:55: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 57D681065670 for ; Thu, 16 Apr 2009 15:55:37 +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 2CD868FC1E for ; Thu, 16 Apr 2009 15:55:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D536B46B92; Thu, 16 Apr 2009 11:55:36 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id CB7F08A01D; Thu, 16 Apr 2009 11:55:35 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 16 Apr 2009 11:46:26 -0400 User-Agent: KMail/1.9.7 References: <49E1819B.7000604@jrv.org> <49E69DDF.3080104@jrv.org> In-Reply-To: <49E69DDF.3080104@jrv.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904161146.26647.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 16 Apr 2009 11:55:35 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "James R. Van Artsdalen" Subject: Re: can't boot 5.5 TB GPT disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 15:55:37 -0000 On Wednesday 15 April 2009 10:54:23 pm James R. Van Artsdalen wrote: > James R. Van Artsdalen wrote: > > I can't boot a GPT partitioned 5.5 TB disc, where the UFS root partition > > is near the end of the disk. > > For the record this fixes the bug. PR to be filed. Hmm, no need for a PR, I already committed the fix and will try to get it into 7.2. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 15:55: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 3B6D3106564A; Thu, 16 Apr 2009 15:55:39 +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 115E48FC13; Thu, 16 Apr 2009 15:55:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BAC2B46B89; Thu, 16 Apr 2009 11:55:38 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 8DAC28A01A; Thu, 16 Apr 2009 11:55:32 -0400 (EDT) From: John Baldwin To: deeptech71@gmail.com Date: Thu, 16 Apr 2009 11:16:57 -0400 User-Agent: KMail/1.9.7 References: <49E6ACEE.6080301@gmail.com> In-Reply-To: <49E6ACEE.6080301@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904161116.58094.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 16 Apr 2009 11:55:32 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=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, rnoland@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 15:55:39 -0000 [ moved to current@ ] On Wednesday 15 April 2009 11:58:38 pm deeptech71@gmail.com wrote: > I can reliably (~40%) reproduce a freeze, which I think is related. > > Using the GENERIC debug kernel built from SVN HEAD: > > # cd /usr/obj/usr/src/sys/GENERIC/ > # kgdb kernel.debug /var/crash/vmcore.0 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-marcel-freebsd"... [ snipped lots of stuff ] > Kernel page fault with the following non-sleepable locks held: > > exclusive sleep mutex drmdev (drmdev) r = 0 (0xc373f860) locked @ > /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:777 > > KDB: stack backtrace: > > calltrap() at calltrap+0x6 > > --- trap 0xc, eip = 0xc0b611b6, esp = 0xd67d4a98, ebp = 0xd67d4b48 --- > > slow_copyin(c373f800,c4103300,c42e64e0,d67d4b64,0,...) at > slow_copyin+0x6 > radeon_cp_texture(c373f800,c42e64e0,c4103300,309,c0c26218,...) at > radeon_cp_texture+0x199 > > drm_ioctl(c39d4e00,c018644e,c42e64e0,3,c40afaf0,...) at drm_ioctl+0x356 > The drm code is doing a copyin() while holding a mutex (which is not allowed). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 15:56:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEAD8106564A; Thu, 16 Apr 2009 15:56:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5B2078FC1F; Thu, 16 Apr 2009 15:56:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3GFuBR5049102; Thu, 16 Apr 2009 11:56:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3GFuBr2081816; Thu, 16 Apr 2009 11:56:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 666B67302F; Thu, 16 Apr 2009 11:56:11 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090416155611.666B67302F@freebsd-current.sentex.ca> Date: Thu, 16 Apr 2009 11:56:11 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on 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, 16 Apr 2009 15:56:14 -0000 TB --- 2009-04-16 15:13:18 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-16 15:13:18 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-04-16 15:13:18 - cleaning the object tree TB --- 2009-04-16 15:14:00 - cvsupping the source tree TB --- 2009-04-16 15:14:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-04-16 15:14:07 - building world TB --- 2009-04-16 15:14:07 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-16 15:14:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-16 15:14:07 - TARGET=sparc64 TB --- 2009-04-16 15:14:07 - TARGET_ARCH=sparc64 TB --- 2009-04-16 15:14:07 - TZ=UTC TB --- 2009-04-16 15:14:07 - __MAKE_CONF=/dev/null TB --- 2009-04-16 15:14:07 - cd /src TB --- 2009-04-16 15:14:07 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 16 15:14:09 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 [...] mkdep -f .depend -a /src/usr.sbin/rarpd/rarpd.c echo rarpd: /obj/sparc64/src/tmp/usr/lib/libc.a >> .depend ===> usr.sbin/raycontrol (depend) rm -f .depend mkdep -f .depend -a -I/src/usr.sbin/raycontrol/../../sys /src/usr.sbin/raycontrol/raycontrol.c /src/usr.sbin/raycontrol/raycontrol.c:47:31: error: dev/ray/if_rayreg.h: No such file or directory /src/usr.sbin/raycontrol/raycontrol.c:48:31: error: dev/ray/if_raymib.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/usr.sbin/raycontrol. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-16 15:56:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-16 15:56:11 - ERROR: failed to build world TB --- 2009-04-16 15:56:11 - 1905.09 user 230.84 system 2573.07 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 16:15: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 A655B10656DB for ; Thu, 16 Apr 2009 16:15:15 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3B62F8FC1E for ; Thu, 16 Apr 2009 16:15:15 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n3GGFEm8009043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 09:15:14 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49E75992.7050106@freebsd.org> Date: Thu, 16 Apr 2009 09:15:14 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Maxim Sobolev References: <49E6DB25.2010601@sippysoft.com> <49E6FF8F.4070403@sippysoft.com> In-Reply-To: <49E6FF8F.4070403@sippysoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: stable@freebsd.org, "current@freebsd.org" Subject: Re: kernel compile fails without AH_SUPPORT_AR5416 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 16:15:16 -0000 Maxim Sobolev wrote: > Dennis Melentyev wrote: >> Could be worth an entry in UPDATING and/or explicitly added to GENERIC. > > My point is that if the option is mandatory for compiling ath(4) > driver, then there is no point in having this option in the first place. There is an entry in UPDATING and it is present in GENERIC (in HEAD, I didn't commit the changes to RELENG_7 so don't know). When the ath hal src code was imported the meaning of the ath_hal device changed because internal configuration done during binary builds was now exposed. Specifically, the need for AH_SUPPORT_5416 to enable support for the extended descriptor format used by the 11n parts. If you read ath_hal(4) this should be clear--if not please help improve the manual page. However, it so happens you can eliminate this option because config will generate a #define you can use instead to identify the configuration of "ath_hal" but this magic is undocumented and I didn't know about it until ru recently told me. I suggested he go ahead and fixup the code to use it but haven't seen anything. I don't have time right now. Sam From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 16:18:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4077C1065672 for ; Thu, 16 Apr 2009 16:18:56 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay2-v.mail.gandi.net (relay2-v.mail.gandi.net [217.70.178.76]) by mx1.freebsd.org (Postfix) with ESMTP id 013A68FC13 for ; Thu, 16 Apr 2009 16:18:55 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from plebeian.afflictions.org (CPE0021296fd1ec-CM0019475d4056.cpe.net.cable.rogers.com [99.241.164.229]) by relay2-v.mail.gandi.net (Postfix) with ESMTP id 80125137E1 for ; Thu, 16 Apr 2009 18:18:54 +0200 (CEST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id 2BF04311C; Thu, 16 Apr 2009 12:18:52 -0400 (EDT) Date: Thu, 16 Apr 2009 12:18:51 -0400 From: Damian Gerow To: freebsd-current@freebsd.org Message-ID: <20090416161851.GC1605@plebeian.afflictions.org> References: <49BD117B.2080706@163.com> <200904131304.43585.jhb@freebsd.org> <20090416144251.GA1605@plebeian.afflictions.org> <200904161145.38687.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904161145.38687.jhb@freebsd.org> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 16:18:56 -0000 John Baldwin wrote: : > I'm at a bit of a loss as to what to test next, other than checking for an : > increased number of checksum errors after unloading umass. However, I'm not : > convinced this is going to highlight the actual problem. I'm all ears as to : > what to test for at this point, as I'm running out of ideas. : > : > A little less wordy: help? : : Do your umass(4) drives use ZFS or some other filesystem? Something in the FAT line, likely FAT32. I use ZFS for everything but my root filesystem (/usr, /var, /tmp, /home, and a few other non-default mountpoints), but I stick with FAT for removable devices. It's probably worth pointing out that I don't need to mount the filesystem to trigger the issue. From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 16:19: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 1238A106566C for ; Thu, 16 Apr 2009 16:19:35 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f170.google.com (mail-gx0-f170.google.com [209.85.217.170]) by mx1.freebsd.org (Postfix) with ESMTP id C4DDD8FC12 for ; Thu, 16 Apr 2009 16:19:34 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk18 with SMTP id 18so1299384gxk.12 for ; Thu, 16 Apr 2009 09:19:34 -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=FdvtN5Lok4GfEqGQnrPlaIaRQU/vEbSlZMCbitxHjp4=; b=mAF7lh4c1R5R67OdwaAyAY1zO7PVDOM12j4k9sqJCHmgXE1xJ2suGHjwKuoeqF+D07 WudI4QYg8KqWWrtdSN7596OC7o46WZnbNfhnp7PRRXJCkA2uxgEL0aUlcnlB+0RwF8zh hI95Pc2LMRm6kGOJh6feBX7AN9xydUkQoRarg= 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=Kss0oHpU2A0pWYsobnLGE/xYLg6IuOhla49MobCTGK/madAW63toRT5Bv1iRh/UPGx 0NGnsaj5K2ZPGmJ7JdyxSSTLa3qFdd/tNu0hI4fppwkTqSA4PhFH+UGKaapwb651kMqd FkTtGA1Ao3jfC8Scs+MjAg8HL79xEKd2Na1PM= MIME-Version: 1.0 Received: by 10.90.116.9 with SMTP id o9mr1599118agc.121.1239898773749; Thu, 16 Apr 2009 09:19:33 -0700 (PDT) In-Reply-To: <20090416141855.75ff5184@fabiankeil.de> References: <20090416141855.75ff5184@fabiankeil.de> Date: Thu, 16 Apr 2009 09:19:33 -0700 Message-ID: From: Maksim Yevmenkin To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tobias Grosser Subject: Re: [patch] prevent atkbd(4) from calling callback in polled 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: Thu, 16 Apr 2009 16:19:35 -0000 On Thu, Apr 16, 2009 at 5:18 AM, Fabian Keil wrote: > Maksim Yevmenkin wrote: > >> would anyone object to the small attached atkbd(4) patch? the idea is >> to basically prevent atkbd(4) interrupt handler from calling keyboard >> callback function when polled mode is enabled. >> >> i would really like to hear from people who is using kbdmux(4) on smp >> systems and having problems with duplicated/missing characters while >> using keyboard at mountroot, geli, etc. prompts. basically, when low >> level console input functions (cngetc(), gets(), etc.) are used _and_ >> interrupts are enabled. > > Thanks. This version of your patch works for me, too. thanks for trying it out guys! anyone else? i plan to commit it at the end of the day today, provided, of course, i do not hear anything bad. thanks, max From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 16:19:38 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 E9FF8106566B; Thu, 16 Apr 2009 16:19:37 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Thu, 16 Apr 2009 12:19:26 -0400 User-Agent: KMail/1.6.2 References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <83e5fb980904151722p17d4210dqeca1c137683eebb0@mail.gmail.com> <49E74B6B.50100@icyb.net.ua> In-Reply-To: <49E74B6B.50100@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200904161219.30639.jkim@FreeBSD.org> Cc: Diego Depaoli , freebsd-current@freebsd.org Subject: Re: disklablel/gpart [Was: AMD 780G chipset major issues 3/3 (btx)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 16:19:38 -0000 On Thursday 16 April 2009 11:14 am, Andriy Gapon wrote: > on 16/04/2009 03:22 Diego Depaoli said the following: > > On Thu, Apr 16, 2009 at 1:43 AM, Jung-uk Kim wrote: > >>> After reboot I get BTX halted. > >>> Perhaps bsdlabel -B works only upon a slice with 0X80 flag set? > >>> Otherwise I don't know... > >> > >> It only works when there is no error. ;-) It seems you have to > >> fix the label first. > > > > Starting from this... > > can be done without loosing data? > > You can try to do it with gpart, maybe it will like slices of your > disks better :) > http://lists.freebsd.org/pipermail/freebsd-geom/2009-April/003440.h >tml > > E.g.: gpart bootcode -b /boot/boot ad10s1 > > Be warned that gpart says back something like "partition has boot > code" and it's not terribly clear what is actually meant here: "it > (already) has boot code, so I am not doing anything" or "I did my > job and it (now) has boot code". It is the latter :-) Well, I recalculated everything with help of trusty bc(1). ;-) Seriously, I must say you should back it up first if the data is important. When I got my current laptop, I had to reinstall all OSes several times in different orders to make all OS loaders agree with an MBR. :-( Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 17:39: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 3D8D91065678; Thu, 16 Apr 2009 17:39:22 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id D65378FC1F; Thu, 16 Apr 2009 17:39:21 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-210-55.bna.bellsouth.net [65.1.210.55]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3GHdDBt025122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 13:39:16 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: John Baldwin In-Reply-To: <200904161116.58094.jhb@freebsd.org> References: <49E6ACEE.6080301@gmail.com> <200904161116.58094.jhb@freebsd.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Qwbm1mGYkoqbUOoR1n59" Organization: FreeBSD Date: Thu, 16 Apr 2009 12:38:09 -0500 Message-Id: <1239903489.2012.5.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: deeptech71@gmail.com, freebsd-current@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 17:39:23 -0000 --=-Qwbm1mGYkoqbUOoR1n59 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2009-04-16 at 11:16 -0400, John Baldwin wrote: > [ moved to current@ ] >=20 > On Wednesday 15 April 2009 11:58:38 pm deeptech71@gmail.com wrote: > > I can reliably (~40%) reproduce a freeze, which I think is related. > >=20 > > Using the GENERIC debug kernel built from SVN HEAD: > >=20 > > # cd /usr/obj/usr/src/sys/GENERIC/ > > # kgdb kernel.debug /var/crash/vmcore.0 > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and yo= u are > > welcome to change it and/or distribute copies of it under certain=20 > > conditions. > > Type "show copying" to see the conditions.=20 > >=20 > > There is absolutely no warranty for GDB. Type "show warranty" for=20 > > details. > > This GDB was configured as "i386-marcel-freebsd"...=20 >=20 > [ snipped lots of stuff ] >=20 > > Kernel page fault with the following non-sleepable locks held:=20 > >=20 > > exclusive sleep mutex drmdev (drmdev) r =3D 0 (0xc373f860) locked @=20 > > /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:777=20 > >=20 > > KDB: stack backtrace:=20 > >=20 > > calltrap() at calltrap+0x6=20 > >=20 > > --- trap 0xc, eip =3D 0xc0b611b6, esp =3D 0xd67d4a98, ebp =3D 0xd67d4b4= 8 ---=20 > >=20 > > slow_copyin(c373f800,c4103300,c42e64e0,d67d4b64,0,...) at=20 > > slow_copyin+0x6 > > radeon_cp_texture(c373f800,c42e64e0,c4103300,309,c0c26218,...) at=20 > > radeon_cp_texture+0x199=20 > >=20 > > drm_ioctl(c39d4e00,c018644e,c42e64e0,3,c40afaf0,...) at drm_ioctl+0x356= =20 > >=20 >=20 > The drm code is doing a copyin() while holding a mutex (which is not allo= wed). Hrm, ok... I'll take a look... There is already a fix in the Intel driver for a similar case. robert. --=20 Robert Noland FreeBSD --=-Qwbm1mGYkoqbUOoR1n59 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknnbQEACgkQM4TrQ4qfROPXsACfZ98GbrQ8b9pnysK44X69oi8V KucAnj5D1/Yuf3SCSxYL+gUnWW3Xwbv9 =vljF -----END PGP SIGNATURE----- --=-Qwbm1mGYkoqbUOoR1n59-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 17:39: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 EE2B71065672 for ; Thu, 16 Apr 2009 17:39:33 +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 C03088FC2F for ; Thu, 16 Apr 2009 17:39:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5717946B23; Thu, 16 Apr 2009 13:39:33 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 48E078A01A; Thu, 16 Apr 2009 13:39:32 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 16 Apr 2009 13:27:46 -0400 User-Agent: KMail/1.9.7 References: <49BD117B.2080706@163.com> <200904161145.38687.jhb@freebsd.org> <20090416161851.GC1605@plebeian.afflictions.org> In-Reply-To: <20090416161851.GC1605@plebeian.afflictions.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904161327.46509.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 16 Apr 2009 13:39:32 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Damian Gerow Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 17:39:35 -0000 On Thursday 16 April 2009 12:18:51 pm Damian Gerow wrote: > John Baldwin wrote: > : > I'm at a bit of a loss as to what to test next, other than checking for an > : > increased number of checksum errors after unloading umass. However, I'm not > : > convinced this is going to highlight the actual problem. I'm all ears as to > : > what to test for at this point, as I'm running out of ideas. > : > > : > A little less wordy: help? > : > : Do your umass(4) drives use ZFS or some other filesystem? > > Something in the FAT line, likely FAT32. I use ZFS for everything but my > root filesystem (/usr, /var, /tmp, /home, and a few other non-default > mountpoints), but I stick with FAT for removable devices. > > It's probably worth pointing out that I don't need to mount the filesystem > to trigger the issue. Try http://www.FreeBSD.org/~jhb/patches/dma_sg.patch please. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 17:39:35 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B173106567B; Thu, 16 Apr 2009 17:39:35 +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 2DC1B8FC16; Thu, 16 Apr 2009 17:39:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B8C9646B3B; Thu, 16 Apr 2009 13:39:34 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id A76178A01B; Thu, 16 Apr 2009 13:39:33 -0400 (EDT) From: John Baldwin To: current@FreeBSD.org Date: Thu, 16 Apr 2009 13:36:18 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904161336.18557.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 16 Apr 2009 13:39:33 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: hps@FreeBSD.org, rnoland@freebsd.org Subject: [PATCH] Possible fix to recent data corruption on HEAD since 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: Thu, 16 Apr 2009 17:39:38 -0000 Due to some good sleuthing by avg@, there is a patch that might fix the recent reports of data corruption on current. It would explain some of the recent reports where a file that was read would have missing gaps of bytes. The problem is with the BUS_DMA_KEEP_PG_OFFSET changes to bus_dma. When a bounce page was used by USB2, the changes to bus_dma would actually change the starting virtual and physical addresses of the bounce page. When the bounce page was no longer needed it was left in this bogus state. Later if another device used the same bounce page for DMA it would use the wrong offset and address. The issue there is if the second device was doing a full page of I/O. In that case the DMA from the device would actually spill over into the next page which could in theory be used by another DMA request. It could also break alignment assumptions (since the previous PG_OFFSET may not be aligned and the bus_dma code assumes bounce pages for the !PG_OFFSET case are page aligned). The quick fix is to always restore the bounce page to the normal state when a PG_OFFSET DMA request is finished. I'd actually prefer not ever touching the page's starting addresses, but those changes would be more invasive I believe. http://www.FreeBSD.org/~jhb/patches/dma_sg.patch Index: amd64/amd64/busdma_machdep.c =================================================================== --- amd64/amd64/busdma_machdep.c (revision 191101) +++ amd64/amd64/busdma_machdep.c (working copy) @@ -1138,8 +1138,6 @@ if (dmat->flags & BUS_DMA_KEEP_PG_OFFSET) { /* page offset needs to be preserved */ - bpage->vaddr &= ~PAGE_MASK; - bpage->busaddr &= ~PAGE_MASK; bpage->vaddr |= vaddr & PAGE_MASK; bpage->busaddr |= vaddr & PAGE_MASK; } @@ -1158,6 +1156,10 @@ bz = dmat->bounce_zone; bpage->datavaddr = 0; bpage->datacount = 0; + if (dmat->flags & BUS_DMA_KEEP_PG_OFFSET) { + bpage->vaddr &= ~PAGE_MASK; + bpage->busaddr &= ~PAGE_MASK; + } mtx_lock(&bounce_lock); STAILQ_INSERT_HEAD(&bz->bounce_page_list, bpage, links); Index: arm/arm/busdma_machdep.c =================================================================== --- arm/arm/busdma_machdep.c (revision 191101) +++ arm/arm/busdma_machdep.c (working copy) @@ -1428,8 +1428,6 @@ if (dmat->flags & BUS_DMA_KEEP_PG_OFFSET) { /* page offset needs to be preserved */ - bpage->vaddr &= ~PAGE_MASK; - bpage->busaddr &= ~PAGE_MASK; bpage->vaddr |= vaddr & PAGE_MASK; bpage->busaddr |= vaddr & PAGE_MASK; } @@ -1448,6 +1446,10 @@ bz = dmat->bounce_zone; bpage->datavaddr = 0; bpage->datacount = 0; + if (dmat->flags & BUS_DMA_KEEP_PG_OFFSET) { + bpage->vaddr &= ~PAGE_MASK; + bpage->busaddr &= ~PAGE_MASK; + } mtx_lock(&bounce_lock); STAILQ_INSERT_HEAD(&bz->bounce_page_list, bpage, links); Index: i386/i386/busdma_machdep.c =================================================================== --- i386/i386/busdma_machdep.c (revision 191101) +++ i386/i386/busdma_machdep.c (working copy) @@ -1156,8 +1156,6 @@ if (dmat->flags & BUS_DMA_KEEP_PG_OFFSET) { /* page offset needs to be preserved */ - bpage->vaddr &= ~PAGE_MASK; - bpage->busaddr &= ~PAGE_MASK; bpage->vaddr |= vaddr & PAGE_MASK; bpage->busaddr |= vaddr & PAGE_MASK; } @@ -1176,6 +1174,10 @@ bz = dmat->bounce_zone; bpage->datavaddr = 0; bpage->datacount = 0; + if (dmat->flags & BUS_DMA_KEEP_PG_OFFSET) { + bpage->vaddr &= ~PAGE_MASK; + bpage->busaddr &= ~PAGE_MASK; + } mtx_lock(&bounce_lock); STAILQ_INSERT_HEAD(&bz->bounce_page_list, bpage, links); Index: ia64/ia64/busdma_machdep.c =================================================================== --- ia64/ia64/busdma_machdep.c (revision 191101) +++ ia64/ia64/busdma_machdep.c (working copy) @@ -941,8 +941,6 @@ if (dmat->flags & BUS_DMA_KEEP_PG_OFFSET) { /* page offset needs to be preserved */ - bpage->vaddr &= ~PAGE_MASK; - bpage->busaddr &= ~PAGE_MASK; bpage->vaddr |= vaddr & PAGE_MASK; bpage->busaddr |= vaddr & PAGE_MASK; } @@ -959,6 +957,10 @@ bpage->datavaddr = 0; bpage->datacount = 0; + if (dmat->flags & BUS_DMA_KEEP_PG_OFFSET) { + bpage->vaddr &= ~PAGE_MASK; + bpage->busaddr &= ~PAGE_MASK; + } mtx_lock(&bounce_lock); STAILQ_INSERT_HEAD(&bounce_page_list, bpage, links); -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 17:52: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 86C121065672 for ; Thu, 16 Apr 2009 17:52:44 +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 4A8388FC19 for ; Thu, 16 Apr 2009 17:52:44 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 1C9A77E821 for ; Thu, 16 Apr 2009 09:52:33 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Thu, 16 Apr 2009 19:52:26 +0200 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.0; i386; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904161952.27379.mel.flynn+fbsd.current@mailing.thruhere.net> Subject: RELENG_7 jails on current host X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 17:52:44 -0000 Hi, I'm looking for some confirmation/caveats for using a -current host and RELENG_7 jails. Mostly I'm wondering whether -current is in good enough shape to host RELENG_7 jails. What I'm trying to accomplish is to have the machine that currently builds packages for -stable machines as well as hosting a number of services (low volume httpd/irc/imap/smtp), can be upgraded to current without significant modification to the jails. The only modification I expect to be making is fake uname output and set certain port related variables for the -stable build server. The reason I'm wanting to do this is because I'm happily running current on my work laptop but building ports interferes too much. I figured building ports in a -current jail on a -stable host would not work very well, but I'll happily be corrected on that if that's no problem. Jails have been built as per jail(8) manpage, not using ezjail. Nullfs mounts exist to share binaries and trees like /usr/ports. -- Mel From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 18:24: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 29451106566B for ; Thu, 16 Apr 2009 18:24:58 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id A2F828FC1C for ; Thu, 16 Apr 2009 18:24:57 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 39C88A07A4; Thu, 16 Apr 2009 20:24:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 2DB8AA07A3; Thu, 16 Apr 2009 20:24:56 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 1AE5FA07A2; Thu, 16 Apr 2009 20:24:56 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009041620245528-7765 ; Thu, 16 Apr 2009 20:24:55 +0200 Received: by wep4035 (sSMTP sendmail emulation); Thu, 16 Apr 2009 20:24:55 +0200 Date: Thu, 16 Apr 2009 20:24:55 +0200 From: Alexey Shuvaev To: John Baldwin Message-ID: <20090416182455.GA60341@wep4035.physik.uni-wuerzburg.de> References: <49BD117B.2080706@163.com> <200904161145.38687.jhb@freebsd.org> <20090416161851.GC1605@plebeian.afflictions.org> <200904161327.46509.jhb@freebsd.org> MIME-Version: 1.0 In-Reply-To: <200904161327.46509.jhb@freebsd.org> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 04/16/2009 08:24:55 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 04/16/2009 08:24:55 PM, Serialize complete at 04/16/2009 08:24:55 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: Damian Gerow , freebsd-current@freebsd.org Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 18:24:58 -0000 On Thu, Apr 16, 2009 at 01:27:46PM -0400, John Baldwin wrote: > On Thursday 16 April 2009 12:18:51 pm Damian Gerow wrote: > > John Baldwin wrote: > > : > I'm at a bit of a loss as to what to test next, other than checking for > an > > : > increased number of checksum errors after unloading umass. However, I'm > not > > : > convinced this is going to highlight the actual problem. I'm all ears > as to > > : > what to test for at this point, as I'm running out of ideas. > > : > > > : > A little less wordy: help? > > : > > : Do your umass(4) drives use ZFS or some other filesystem? > > > > Something in the FAT line, likely FAT32. I use ZFS for everything but my > > root filesystem (/usr, /var, /tmp, /home, and a few other non-default > > mountpoints), but I stick with FAT for removable devices. > > > > It's probably worth pointing out that I don't need to mount the filesystem > > to trigger the issue. > > Try http://www.FreeBSD.org/~jhb/patches/dma_sg.patch please. > You mean dma_pg.patch? ^^^^^^^^^^^^^ Alexey. From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 18:46: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 44F0F106566C for ; Thu, 16 Apr 2009 18:46:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outf.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 2BD578FC08 for ; Thu, 16 Apr 2009 18:46:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id E7FA95BA7E; Thu, 16 Apr 2009 11:46:03 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (unknown [64.244.102.2]) by idiom.com (Postfix) with ESMTP id 850FB2D606A; Thu, 16 Apr 2009 11:45:58 -0700 (PDT) Message-ID: <49E77CF4.70008@elischer.org> Date: Thu, 16 Apr 2009 11:46:12 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Mel Flynn References: <200904161952.27379.mel.flynn+fbsd.current@mailing.thruhere.net> In-Reply-To: <200904161952.27379.mel.flynn+fbsd.current@mailing.thruhere.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: RELENG_7 jails on current host X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 18:46:04 -0000 Mel Flynn wrote: > Hi, > > I'm looking for some confirmation/caveats for using a -current host and > RELENG_7 jails. Mostly I'm wondering whether -current is in good enough shape > to host RELENG_7 jails. What I'm trying to accomplish is to have the machine > that currently builds packages for -stable machines as well as hosting a > number of services (low volume httpd/irc/imap/smtp), can be upgraded to > current without significant modification to the jails. The only modification I > expect to be making is fake uname output and set certain port related > variables for the -stable build server. > > The reason I'm wanting to do this is because I'm happily running current on my > work laptop but building ports interferes too much. I figured building ports > in a -current jail on a -stable host would not work very well, but I'll > happily be corrected on that if that's no problem. > > Jails have been built as per jail(8) manpage, not using ezjail. Nullfs mounts > exist to share binaries and trees like /usr/ports. should work but you may need to have current versions of: netstat, ifconfig, ps, top and new versions of the libraries they want, or, as I sometimes do, copies of those from /rescue. From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 18:46: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 EC962106564A for ; Thu, 16 Apr 2009 18:46:29 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id C60D08FC14 for ; Thu, 16 Apr 2009 18:46:29 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: by mx1.synetsystems.com (Postfix, from userid 66) id 380AFCD2; Thu, 16 Apr 2009 14:46:28 -0400 (EDT) Received: from rmtodd by servalan.servalan.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuWS9-0001I8-2B; Thu, 16 Apr 2009 13:36:49 -0500 To: freebsd-current@freebsd.org, Damian Gerow References: <49BD117B.2080706@163.com> <012d01c9b706$ccace720$6606b560$@Sparrevohn@btinternet.com> <20090409003108.fe768d54.nork@FreeBSD.org> <200904131304.43585.jhb@freebsd.org> <20090416144251.GA1605@plebeian.afflictions.org> From: Richard Todd Date: Thu, 16 Apr 2009 13:36:48 -0500 In-Reply-To: (Damian Gerow's message of "Thu, 16 Apr 2009 10:42:51 -0400") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.22 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 18:46:30 -0000 Damian Gerow writes: > 1) Reverting the extended attribute locking change (r189967) does not change > the situation for me. I still experience checksum issues and data loss. > (Unsurprisingly.) > > 2) Without umass loaded, I have been completely unable to trigger the issue. > > 3) Once umass is loaded, and the symptoms start cropping up, unloading umass > does not make them go away (again, unsurprisingly). What I haven't yet > tested, but am currently working towards, is whether removing umass stops > further checksum errors from ocurring. > > 4) r189967 does remove some LORs for me, even though I don't use (that I > know of) extended attributes. > > 5) It seems that so long as umass is used at all, the symptoms will > eventually show up. I've been able to trigger the symptoms by inserting > then removing a umass device immediately after boot, then ramping up the > workload. > > 6) The only difference made by vfs.zfs.debug=1 is that zfs reclaims are > logged. > > I'm at a bit of a loss as to what to test next, other than checking for an > increased number of checksum errors after unloading umass. However, I'm not > convinced this is going to highlight the actual problem. I'm all ears as to > what to test for at this point, as I'm running out of ideas. I have a question or two, and an idea. The questions: 1) How much RAM do you have, is it 4G or more? (I'm guessing the answer is "yes".) 2) What does "sysctl -a | grep bounced" say? Check this both before and after loading umass and seeing the bug triggered. My idea: I suspect a bug in the bounce-buffer code that does I/O to memory space beyond the area a given piece of hardware can access directly thru DMA. I've had some similar issues with checksum errors, and they seem to have gone away since lowering hw.physmem to 3400M in loader.conf, which cuts memory usage down below the point where anything needs to use bounce buffers. You might try lowering hw.physmem and see if that helps; check with the "sysctl -a | grep bounced" command, you should be seeing something like hw.busdma.zone0.total_bounced: 0 hw.busdma.zone1.total_bounced: 0 hw.busdma.zone2.total_bounced: 0 if no bounce-buffer usage is going on. (The number of zones may be different on your system.) From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 19:16: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 DADB9106566C for ; Thu, 16 Apr 2009 19:16:58 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 62C8D8FC12 for ; Thu, 16 Apr 2009 19:16:58 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id A928CA07A2; Thu, 16 Apr 2009 20:47:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 9CFC7A079D; Thu, 16 Apr 2009 20:47:39 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 89F47A079B; Thu, 16 Apr 2009 20:47:39 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009041620473829-7825 ; Thu, 16 Apr 2009 20:47:38 +0200 Received: by wep4035 (sSMTP sendmail emulation); Thu, 16 Apr 2009 20:47:38 +0200 Date: Thu, 16 Apr 2009 20:47:38 +0200 From: Alexey Shuvaev To: John Baldwin Message-ID: <20090416184738.GA60409@wep4035.physik.uni-wuerzburg.de> References: <200904161336.18557.jhb@freebsd.org> MIME-Version: 1.0 In-Reply-To: <200904161336.18557.jhb@freebsd.org> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 04/16/2009 08:47:38 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 04/16/2009 08:47:38 PM, Serialize complete at 04/16/2009 08:47:38 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: current@FreeBSD.org Subject: Re: [PATCH] Possible fix to recent data corruption on HEAD since 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: Thu, 16 Apr 2009 19:17:01 -0000 On Thu, Apr 16, 2009 at 01:36:18PM -0400, John Baldwin wrote: > Due to some good sleuthing by avg@, > there is a patch that might fix the recent > reports of data corruption on current. It would explain some of the recent > reports where a file that was read would have missing gaps of bytes. The > problem is with the BUS_DMA_KEEP_PG_OFFSET changes to bus_dma. When a bounce > page was used by USB2, the changes to bus_dma would actually change the > starting virtual and physical addresses of the bounce page. When the bounce > page was no longer needed it was left in this bogus state. Later if another > device used the same bounce page for DMA it would use the wrong offset and > address. The issue there is if the second device was doing a full page of > I/O. In that case the DMA from the device would actually spill over into the > next page which could in theory be used by another DMA request. It could > also break alignment assumptions (since the previous PG_OFFSET may not be > aligned and the bus_dma code assumes bounce pages for the !PG_OFFSET case are > page aligned). The quick fix is to always restore the bounce page to the > normal state when a PG_OFFSET DMA request is finished. I'd actually prefer > not ever touching the page's starting addresses, but those changes would be > more invasive I believe. > > http://www.FreeBSD.org/~jhb/patches/dma_sg.patch > Am I right that hardware prerequisite in order to observe these problems is amd64 + 4Gb or more of RAM? Is it possible to fabricate some (artificial) test case to stress this particular situation (interleaved use of bounce pages by USB and some other device (?HDD?))? Asking because as I understand the data corruption is silent and affected consumer (of bounce pages) should have some mechanism of detecting this (e.g. zfs' CRCs). In my case stess testing unpatched system till UFS filesystems are dead is no fun... Alexey. From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 19:48: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 3762F1065670 for ; Thu, 16 Apr 2009 19:48:13 +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 D66818FC16 for ; Thu, 16 Apr 2009 19:48:12 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 519FD7E818; Thu, 16 Apr 2009 11:48:08 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Thu, 16 Apr 2009 21:48:05 +0200 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.0; i386; ; ) References: <200904161952.27379.mel.flynn+fbsd.current@mailing.thruhere.net> <49E77CF4.70008@elischer.org> In-Reply-To: <49E77CF4.70008@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904162148.06315.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Julian Elischer Subject: Re: RELENG_7 jails on current host X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 19:48:13 -0000 On Thursday 16 April 2009 20:46:12 Julian Elischer wrote: > Mel Flynn wrote: > > Hi, > > > > I'm looking for some confirmation/caveats for using a -current host and > > RELENG_7 jails. Mostly I'm wondering whether -current is in good enough > > shape to host RELENG_7 jails. What I'm trying to accomplish is to have > > the machine that currently builds packages for -stable machines as well > > as hosting a number of services (low volume httpd/irc/imap/smtp), can be > > upgraded to current without significant modification to the jails. The > > only modification I expect to be making is fake uname output and set > > certain port related variables for the -stable build server. > > > > The reason I'm wanting to do this is because I'm happily running current > > on my work laptop but building ports interferes too much. I figured > > building ports in a -current jail on a -stable host would not work very > > well, but I'll happily be corrected on that if that's no problem. > > > > Jails have been built as per jail(8) manpage, not using ezjail. Nullfs > > mounts exist to share binaries and trees like /usr/ports. > > should work but you may need to have current versions of: > netstat, ifconfig, ps, top and new versions of the libraries they > want, or, as I sometimes do, copies of those from /rescue. I don't actually share host binaries. I have a template RELENG_7 jail where installworld occurs, then share those binaries across stable jails. Does the above still apply? Meaning, I need to copy -current version of the above into the RELENG_7 template jail, including libc.so.8 and friends? -- Mel From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 19:59: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 0A70910656E7 for ; Thu, 16 Apr 2009 19:59:14 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out3.uni-muenster.de (ZIVM-OUT3.UNI-MUENSTER.DE [128.176.192.18]) by mx1.freebsd.org (Postfix) with ESMTP id 932138FC17 for ; Thu, 16 Apr 2009 19:59:13 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.40,200,1238968800"; d="scan'208";a="2928519" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay3.uni-muenster.de with ESMTP; 16 Apr 2009 21:59:12 +0200 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 11E611B0763; Thu, 16 Apr 2009 21:59:12 +0200 (CEST) Date: Thu, 16 Apr 2009 21:59:11 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: core dump with bluetooth device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 19:59:14 -0000 hi there, i'm running r191076M. when i try to send files from my mobile phone to my computer via bt the core dumps. here's a backtrace: Unread portion of the kernel message buffer: sblastmbufchk: sb_mb 0xc8d54d00 sb_mbtail 0 last 0xc8d54d00 packet tree: 0xc8d54d00 panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:797 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c07a4d9e,c56e5b64,c05a9993,c07c5e79,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07c5e79,0,c07abad5,c56e5b70,0,...) at kdb_backtrace+0x29 panic(c07abad5,c0768a0e,c07aba5a,31d,c8d54d00) at panic+0x114 sblastmbufchk(c8e08b08,c07aba5a,31d,2f1,4,c07aba5a,184) at sblastmbufchk+0xe3 sbcompress(c8e08b08,0,c8d54d00,24e,c8e08b28) at sbcompress+0x256 sbappendrecord_locked(c8e08b08,c8d54d00,c07aba5a,263,c90c91c0,...) at sbappendrecord_locked+0x10c sbappendrecord(c8e08b08,c8d54d00,c84e2129,57b,c56e5c3c,...) at sbappendrecord+0x3d ng_btsocket_l2cap_input(0,1,c07a650f,54,c7a64e9c,...) at ng_btsocket_l2cap_input+0xc82 taskqueue_run(c7a64e80,c56e5cc8,c058aa0f,0,0,...) at taskqueue_run+0x108 taskqueue_swi_giant_run(0,0,c079dd37,46d,c79b8cb8,...) at taskqueue_swi_giant_run+0x13 intr_event_execute_handlers(c792fa90,c79b8c80,c079dd37,4dd,c79b8cf0,...) at intr_event_execute_handlers+0x10f ithread_loop(c7a78b60,c56e5d38,c079daad,32d,c792fa90,...) at ithread_loop+0x98 fork_exit(c058b551,c7a78b60,c56e5d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc56e5d70, ebp = 0 --- Uptime: 7h16m51s Physical memory: 2026 MB Dumping 203 MB:usb2_do_poll: USB polling is not supported! Expensive timeout(9) function: 0xc05dccc8(0xc878dd20) 0.183307654 s 188 172 156 140 124 108 92 76 60 44 28 12 Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/ng_btsocket.ko...Reading symbols from /boot/kernel/ng_btsocket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_btsocket.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_bluetooth.ko...Reading symbols from /boot/kernel/ng_bluetooth.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_bluetooth.ko Reading symbols from /boot/kernel/ng_ubt.ko...Reading symbols from /boot/kernel/ng_ubt.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ubt.ko Reading symbols from /boot/kernel/ng_hci.ko...Reading symbols from /boot/kernel/ng_hci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_hci.ko Reading symbols from /boot/kernel/ng_l2cap.ko...Reading symbols from /boot/kernel/ng_l2cap.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_l2cap.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc05a96e9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc05a99cf in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc0603574 in sblastmbufchk (sb=0x0, file=0xc07aba5a "/usr/src/sys/kern/uipc_sockbuf.c", line=797) at /usr/src/sys/kern/uipc_sockbuf.c:427 #4 0xc0604b15 in sbcompress (sb=0xc8e08b08, m=0x0, n=0xc8d54d00) at /usr/src/sys/kern/uipc_sockbuf.c:797 #5 0xc0604c29 in sbappendrecord_locked (sb=0xc8e08b08, m0=0xc8d54d00) at /usr/src/sys/kern/uipc_sockbuf.c:601 #6 0xc0604c6e in sbappendrecord (sb=0xc8e08b08, m0=0xc8d54d00) at /usr/src/sys/kern/uipc_sockbuf.c:612 #7 0xc84d7005 in ng_btsocket_l2cap_input (context=0x0, pending=1) at /usr/src/sys/modules/netgraph/bluetooth/socket/../../../../netgraph/bluetooth/socket/ng_btsocket_l2cap.c:1458 #8 0xc05df273 in taskqueue_run (queue=0xc7a64e80) at /usr/src/sys/kern/subr_taskqueue.c:282 #9 0xc05df479 in taskqueue_swi_giant_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:336 #10 0xc058aa0f in intr_event_execute_handlers (p=0xc792fa90, ie=0xc79b8c80) at /usr/src/sys/kern/kern_intr.c:1134 #11 0xc058b5e9 in ithread_loop (arg=0xc7a78b60) at /usr/src/sys/kern/kern_intr.c:1147 #12 0xc05888b1 in fork_exit (callout=0xc058b551 , arg=0xc7a78b60, frame=0xc56e5d38) at /usr/src/sys/kern/kern_fork.c:821 #13 0xc0716330 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 this is my bt device: ubt0: on usbus0 cheers. alex From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 20:03: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 85F2A106564A for ; Thu, 16 Apr 2009 20:03:24 +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 57DC28FC23 for ; Thu, 16 Apr 2009 20:03:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0AE9646B65; Thu, 16 Apr 2009 16:03:24 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 62A308A01A; Thu, 16 Apr 2009 16:03:22 -0400 (EDT) From: John Baldwin To: Alexey Shuvaev Date: Thu, 16 Apr 2009 15:35:18 -0400 User-Agent: KMail/1.9.7 References: <49BD117B.2080706@163.com> <200904161327.46509.jhb@freebsd.org> <20090416182455.GA60341@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20090416182455.GA60341@wep4035.physik.uni-wuerzburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904161535.19220.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 16 Apr 2009 16:03:22 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Damian Gerow , freebsd-current@freebsd.org Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 20:03:24 -0000 On Thursday 16 April 2009 2:24:55 pm Alexey Shuvaev wrote: > On Thu, Apr 16, 2009 at 01:27:46PM -0400, John Baldwin wrote: > > On Thursday 16 April 2009 12:18:51 pm Damian Gerow wrote: > > > John Baldwin wrote: > > > : > I'm at a bit of a loss as to what to test next, other than checking for > > an > > > : > increased number of checksum errors after unloading umass. However, I'm > > not > > > : > convinced this is going to highlight the actual problem. I'm all ears > > as to > > > : > what to test for at this point, as I'm running out of ideas. > > > : > > > > : > A little less wordy: help? > > > : > > > : Do your umass(4) drives use ZFS or some other filesystem? > > > > > > Something in the FAT line, likely FAT32. I use ZFS for everything but my > > > root filesystem (/usr, /var, /tmp, /home, and a few other non-default > > > mountpoints), but I stick with FAT for removable devices. > > > > > > It's probably worth pointing out that I don't need to mount the filesystem > > > to trigger the issue. > > > > Try http://www.FreeBSD.org/~jhb/patches/dma_sg.patch please. > > > You mean dma_pg.patch? ^^^^^^^^^^^^^ Yes, and it is now symlinked to dma_sg as well. :) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 20:03:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A41A106566B for ; Thu, 16 Apr 2009 20:03: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 4B17D8FC24 for ; Thu, 16 Apr 2009 20:03:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id F2B2D46B0C; Thu, 16 Apr 2009 16:03:24 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id C9DEA8A01B; Thu, 16 Apr 2009 16:03:23 -0400 (EDT) From: John Baldwin To: Alexey Shuvaev Date: Thu, 16 Apr 2009 15:58:56 -0400 User-Agent: KMail/1.9.7 References: <200904161336.18557.jhb@freebsd.org> <20090416184738.GA60409@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20090416184738.GA60409@wep4035.physik.uni-wuerzburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904161558.56919.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 16 Apr 2009 16:03:23 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: current@freebsd.org Subject: Re: [PATCH] Possible fix to recent data corruption on HEAD since 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: Thu, 16 Apr 2009 20:03:25 -0000 On Thursday 16 April 2009 2:47:38 pm Alexey Shuvaev wrote: > On Thu, Apr 16, 2009 at 01:36:18PM -0400, John Baldwin wrote: > > Due to some good sleuthing by avg@, > > there is a patch that might fix the recent > > reports of data corruption on current. It would explain some of the recent > > reports where a file that was read would have missing gaps of bytes. The > > problem is with the BUS_DMA_KEEP_PG_OFFSET changes to bus_dma. When a bounce > > page was used by USB2, the changes to bus_dma would actually change the > > starting virtual and physical addresses of the bounce page. When the bounce > > page was no longer needed it was left in this bogus state. Later if another > > device used the same bounce page for DMA it would use the wrong offset and > > address. The issue there is if the second device was doing a full page of > > I/O. In that case the DMA from the device would actually spill over into the > > next page which could in theory be used by another DMA request. It could > > also break alignment assumptions (since the previous PG_OFFSET may not be > > aligned and the bus_dma code assumes bounce pages for the !PG_OFFSET case are > > page aligned). The quick fix is to always restore the bounce page to the > > normal state when a PG_OFFSET DMA request is finished. I'd actually prefer > > not ever touching the page's starting addresses, but those changes would be > > more invasive I believe. > > > > http://www.FreeBSD.org/~jhb/patches/dma_sg.patch > > > Am I right that hardware prerequisite in order to observe these problems > is amd64 + 4Gb or more of RAM? Well, i386 with PAE would do it as well. Basically, you need USB + one other device that use bounce pages and the other device ends up with corruption. > Is it possible to fabricate some (artificial) test case to stress this > particular situation (interleaved use of bounce pages by USB and some other > device (?HDD?))? I haven't constructed one though it might be possible to do so. > Asking because as I understand the data corruption is silent > and affected consumer (of bounce pages) should have some mechanism > of detecting this (e.g. zfs' CRCs). > In my case stess testing unpatched system till UFS filesystems are dead > is no fun... Understood. I know some other folks are going to test this and if there is early success that may make the risk easier to take. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 20:21: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 9ACC310658DE; Thu, 16 Apr 2009 20:21:41 +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 419278FC26; Thu, 16 Apr 2009 20:21:41 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-16-27.bna.bellsouth.net [70.156.16.27]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3GKLZ2X026277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 16:21:35 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: John Baldwin In-Reply-To: <200904161116.58094.jhb@freebsd.org> References: <49E6ACEE.6080301@gmail.com> <200904161116.58094.jhb@freebsd.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-rMvmULyedHvAfzNUtWRQ" Organization: FreeBSD Date: Thu, 16 Apr 2009 15:20:34 -0500 Message-Id: <1239913234.1991.1.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: deeptech71@gmail.com, freebsd-current@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 20:21:42 -0000 --=-rMvmULyedHvAfzNUtWRQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2009-04-16 at 11:16 -0400, John Baldwin wrote: > [ moved to current@ ] >=20 > On Wednesday 15 April 2009 11:58:38 pm deeptech71@gmail.com wrote: > > I can reliably (~40%) reproduce a freeze, which I think is related. > >=20 > > Using the GENERIC debug kernel built from SVN HEAD: > >=20 > > # cd /usr/obj/usr/src/sys/GENERIC/ > > # kgdb kernel.debug /var/crash/vmcore.0 > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and yo= u are > > welcome to change it and/or distribute copies of it under certain=20 > > conditions. > > Type "show copying" to see the conditions.=20 > >=20 > > There is absolutely no warranty for GDB. Type "show warranty" for=20 > > details. > > This GDB was configured as "i386-marcel-freebsd"...=20 >=20 > [ snipped lots of stuff ] >=20 > > Kernel page fault with the following non-sleepable locks held:=20 > >=20 > > exclusive sleep mutex drmdev (drmdev) r =3D 0 (0xc373f860) locked @=20 > > /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:777=20 > >=20 > > KDB: stack backtrace:=20 > >=20 > > calltrap() at calltrap+0x6=20 > >=20 > > --- trap 0xc, eip =3D 0xc0b611b6, esp =3D 0xd67d4a98, ebp =3D 0xd67d4b4= 8 ---=20 > >=20 > > slow_copyin(c373f800,c4103300,c42e64e0,d67d4b64,0,...) at=20 > > slow_copyin+0x6 > > radeon_cp_texture(c373f800,c42e64e0,c4103300,309,c0c26218,...) at=20 > > radeon_cp_texture+0x199=20 > >=20 > > drm_ioctl(c39d4e00,c018644e,c42e64e0,3,c40afaf0,...) at drm_ioctl+0x356= =20 > >=20 >=20 > The drm code is doing a copyin() while holding a mutex (which is not allo= wed). Ok, the quick and dirty fix for this is http://people.freebsd.org/~rnoland/drm_radeon_state-copyin-fix.patch I think there may be other places of concern though and a more proper fix is needed. robert. --=20 Robert Noland FreeBSD --=-rMvmULyedHvAfzNUtWRQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknnkxIACgkQM4TrQ4qfROMLawCeP2PeSvVBp9ZEYBxINY0Oxozc BoAAn15iz8xqwSFX+ww7k2A6+7p2GfcD =/Hii -----END PGP SIGNATURE----- --=-rMvmULyedHvAfzNUtWRQ-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 20:26: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 92133106568B for ; Thu, 16 Apr 2009 20:26:22 +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 AEF948FC14 for ; Thu, 16 Apr 2009 20:26:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 50A2946B2C; Thu, 16 Apr 2009 16:26:21 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 2F6C38A01A; Thu, 16 Apr 2009 16:26:20 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 16 Apr 2009 16:24:51 -0400 User-Agent: KMail/1.9.7 References: <49BD117B.2080706@163.com> <20090416144251.GA1605@plebeian.afflictions.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904161624.51920.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 16 Apr 2009 16:26:20 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Damian Gerow , Richard Todd Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 20:26:23 -0000 On Thursday 16 April 2009 2:36:48 pm Richard Todd wrote: > Damian Gerow writes: > > 1) Reverting the extended attribute locking change (r189967) does not change > > the situation for me. I still experience checksum issues and data loss. > > (Unsurprisingly.) > > > > 2) Without umass loaded, I have been completely unable to trigger the issue. > > > > 3) Once umass is loaded, and the symptoms start cropping up, unloading umass > > does not make them go away (again, unsurprisingly). What I haven't yet > > tested, but am currently working towards, is whether removing umass stops > > further checksum errors from ocurring. > > > > 4) r189967 does remove some LORs for me, even though I don't use (that I > > know of) extended attributes. > > > > 5) It seems that so long as umass is used at all, the symptoms will > > eventually show up. I've been able to trigger the symptoms by inserting > > then removing a umass device immediately after boot, then ramping up the > > workload. > > > > 6) The only difference made by vfs.zfs.debug=1 is that zfs reclaims are > > logged. > > > > I'm at a bit of a loss as to what to test next, other than checking for an > > increased number of checksum errors after unloading umass. However, I'm not > > convinced this is going to highlight the actual problem. I'm all ears as to > > what to test for at this point, as I'm running out of ideas. > > I have a question or two, and an idea. > > The questions: > > 1) How much RAM do you have, is it 4G or more? (I'm guessing the > answer is "yes".) > > 2) What does "sysctl -a | grep bounced" say? Check this both before and after > loading umass and seeing the bug triggered. > > My idea: I suspect a bug in the bounce-buffer code that does I/O to memory > space beyond the area a given piece of hardware can access directly thru DMA. > I've had some similar issues with checksum errors, and they seem to have gone > away since lowering hw.physmem to 3400M in loader.conf, which cuts memory > usage down below the point where anything needs to use bounce buffers. > You might try lowering hw.physmem and see if that helps; check with the > "sysctl -a | grep bounced" command, you should be seeing something like > > hw.busdma.zone0.total_bounced: 0 > hw.busdma.zone1.total_bounced: 0 > hw.busdma.zone2.total_bounced: 0 > > if no bounce-buffer usage is going on. (The number of zones may be different > on your system.) Can you please try http://www.FreeBSD.org/~jhb/patches/dma_pg.patch? This lines up with your analysis in that it fixes a problem in the bounce buffer code that was introduced with the new USB stack (and only triggers when the USB code has to use a bounce buffer). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 20:42: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 8C51B1065672 for ; Thu, 16 Apr 2009 20:42:48 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay4-v.mail.gandi.net (relay4-v.mail.gandi.net [217.70.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 505AD8FC1F for ; Thu, 16 Apr 2009 20:42:48 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from plebeian.afflictions.org (CPE0021296fd1ec-CM0019475d4056.cpe.net.cable.rogers.com [99.241.164.229]) by relay4-v.mail.gandi.net (Postfix) with ESMTP id E98D4BA17 for ; Thu, 16 Apr 2009 22:42:46 +0200 (CEST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id 4D21A30A1; Thu, 16 Apr 2009 16:42:44 -0400 (EDT) Date: Thu, 16 Apr 2009 16:42:44 -0400 From: Damian Gerow To: freebsd-current@freebsd.org Message-ID: <20090416204244.GB1186@plebeian.afflictions.org> References: <49BD117B.2080706@163.com> <200904161327.46509.jhb@freebsd.org> <20090416182455.GA60341@wep4035.physik.uni-wuerzburg.de> <200904161535.19220.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904161535.19220.jhb@freebsd.org> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 20:42:48 -0000 John Baldwin wrote: : > > > Something in the FAT line, likely FAT32. I use ZFS for everything but my : > > > root filesystem (/usr, /var, /tmp, /home, and a few other non-default : > > > mountpoints), but I stick with FAT for removable devices. : > > > : > > > It's probably worth pointing out that I don't need to mount the filesystem : > > > to trigger the issue. : > > : > > Try http://www.FreeBSD.org/~jhb/patches/dma_sg.patch please. : > > : > You mean dma_pg.patch? ^^^^^^^^^^^^^ : : Yes, and it is now symlinked to dma_sg as well. :) I've been running with the patch for two and a half hours, and I'm seeing a steady increase in bounced buffers, with no further complaints of checksum errors. I can usually trigger the problem about two hours into load generation, so things are looking good so far. From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 20:58:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2913C106566B; Thu, 16 Apr 2009 20:58:58 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: from mail-bw0-f165.google.com (mail-bw0-f165.google.com [209.85.218.165]) by mx1.freebsd.org (Postfix) with ESMTP id 7AD348FC18; Thu, 16 Apr 2009 20:58:57 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: by bwz9 with SMTP id 9so36808bwz.43 for ; Thu, 16 Apr 2009 13:58:56 -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=jNda8iSJLuFxf7cB28C8oWksuVuDnl4ck/4tnwoKo/g=; b=RjodbC6whKYM7p8Tbjwd423wHQYHrui2saHULMUidoH7rweAeB9sxpSVVuGYOKTaFA r1BuVVgQUKj9Wto8Uu8b3cT+754BN9EktkSjVq+UyUeRGoidtSgFT4AORi/cTHmeGsz2 J6iFRyJPTaZSiStqiWiqmISmhKeRLMOUgfOg8= 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=OJsFULqHjTlG1GWS+3vNJX9r8MHrYM+hXmmZLkVWgXHBdgyiKIRKxbhCLz/yoXEbZ2 Mmw2cvFslZuchHjQmT/R81PPxLs6P+H67yzzT/siLQhD3naU8QsUCWA1TjrZRM2XwcMc Kq6h1XjnOUSgcflu5vuvKVIaxL7S+pcpMjrTo= MIME-Version: 1.0 Received: by 10.223.110.11 with SMTP id l11mr533401fap.50.1239915536481; Thu, 16 Apr 2009 13:58:56 -0700 (PDT) In-Reply-To: <200904161219.30639.jkim@FreeBSD.org> References: <83e5fb980904061402q73940f8at4ec4b8f821354320@mail.gmail.com> <83e5fb980904151722p17d4210dqeca1c137683eebb0@mail.gmail.com> <49E74B6B.50100@icyb.net.ua> <200904161219.30639.jkim@FreeBSD.org> Date: Thu, 16 Apr 2009 22:58:56 +0200 Message-ID: <83e5fb980904161358p12992560xc3e1045745b36281@mail.gmail.com> From: Diego Depaoli To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: disklablel/gpart [Was: AMD 780G chipset major issues 3/3 (btx)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 20:58:58 -0000 On Thu, Apr 16, 2009 at 6:19 PM, Jung-uk Kim wrote: > On Thursday 16 April 2009 11:14 am, Andriy Gapon wrote: >> Be warned that gpart says back something like "partition has boot >> code" and it's not terribly clear what is actually meant here: "it >> (already) has boot code, so I am not doing anything" or "I did my >> job and it (now) has boot code". It is the latter :-) > > Well, I recalculated everything with help of trusty bc(1). ;-) > > Seriously, I must say you should back it up first if the data is > important. =A0When I got my current laptop, I had to reinstall all OSes > several times in different orders to make all OS loaders agree with > an MBR. :-( Many thanks to all. I wiped a slice on the 2nd drive, now I begin to backup data. If you read about a brutally murdered husband, then something gone wrong. Regards --=20 Diego Depaoli From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 12:05: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 4BECE10657AF; Thu, 16 Apr 2009 12:05:43 +0000 (UTC) (envelope-from dennis.melentyev@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF0D8FC1B; Thu, 16 Apr 2009 12:05:42 +0000 (UTC) (envelope-from dennis.melentyev@gmail.com) Received: by bwz8 with SMTP id 8so376643bwz.43 for ; Thu, 16 Apr 2009 05:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0zBl7aIL2g/ja7C4o+PzpUBSdVTF8yc4cIwlXboZBZQ=; b=xN48NbmUnWcPxfFoboQMot9X1HRYpKpXoR93UKo5QOW3PDIuQiKBOGYojqoch8njje tCHW41KYs7BoitLVYJD83mdj/eza1SvXCMS8cZFkq/8AKFEJrqupwxxpQn6uSNfaqc8K mHRn6aNidRyQZsRFFaA+Tmak45eoqEXOZ8U/k= 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=r1D+VXCNqti2y9ebC2yCovi1CJxrTm5OSrGHaa1AJ9ujxBjjbPp8JaF9zecnB8sg3o slH6yt8OpXEBQP4ZTD/LJQqwZGI75NI499I/rWYIC07ZWGmwA/CBOrG2FFJxV+ONWj+j U4oxTTXAoe99DDBjfZ/QqNdo9COAUpKmEzgT8= MIME-Version: 1.0 Received: by 10.204.31.101 with SMTP id x37mr1222176bkc.4.1239883541450; Thu, 16 Apr 2009 05:05:41 -0700 (PDT) In-Reply-To: <49E6FF8F.4070403@sippysoft.com> References: <49E6DB25.2010601@sippysoft.com> <49E6FF8F.4070403@sippysoft.com> Date: Thu, 16 Apr 2009 15:05:41 +0300 Message-ID: From: Dennis Melentyev To: Maxim Sobolev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 16 Apr 2009 21:11:22 +0000 Cc: stable@freebsd.org, Sam Leffler , "current@freebsd.org" Subject: Re: kernel compile fails without AH_SUPPORT_AR5416 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 12:05:57 -0000 2009/4/16 Maxim Sobolev : > Dennis Melentyev wrote: >> >> Could be worth an entry in UPDATING and/or explicitly added to GENERIC. > > My point is that if the option is mandatory for compiling ath(4) driver, > then there is no point in having this option in the first place. Well, fair. +1 from me :). -- Dennis Melentyev From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 14:29: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 643A9106566B for ; Thu, 16 Apr 2009 14:29:09 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 1D3048FC1E for ; Thu, 16 Apr 2009 14:29:09 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1LuSaS-0000II-CR>; Thu, 16 Apr 2009 16:29:08 +0200 Received: from e178013016.adsl.alicedsl.de ([85.178.13.16] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1LuSaS-0001x5-9H>; Thu, 16 Apr 2009 16:29:08 +0200 Message-ID: <49E740BB.7060005@mail.zedat.fu-berlin.de> Date: Thu, 16 Apr 2009 16:29:15 +0200 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.21 (X11/20090410) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.13.16 X-Mailman-Approved-At: Thu, 16 Apr 2009 21:12:06 +0000 Subject: /usr/src/usr.sbin/raycontrol/raycontrol.c:47:31: error: dev/ray/if_rayreg.h: No such file or directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 14:29:09 -0000 Today's 'make buildworld' fails with this error: ===> usr.sbin/raycontrol (depend) rm -f .depend mkdep -f .depend -a -I/usr/src/usr.sbin/raycontrol/../../sys /usr/src/usr.sbin/raycontrol/raycontrol.c /usr/src/usr.sbin/raycontrol/raycontrol.c:47:31: error: dev/ray/if_rayreg.h: No such file or directory /usr/src/usr.sbin/raycontrol/raycontrol.c:48:31: error: dev/ray/if_raymib.h: No such file or directory mkdep: compile failed *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 14:32: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 D3745106566C; Thu, 16 Apr 2009 14:32:32 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 893CB8FC26; Thu, 16 Apr 2009 14:32:32 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1LuSdj-0000kM-QE>; Thu, 16 Apr 2009 16:32:31 +0200 Received: from e178013016.adsl.alicedsl.de ([85.178.13.16] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1LuSdj-00027S-NB>; Thu, 16 Apr 2009 16:32:31 +0200 Message-ID: <49E74186.906@mail.zedat.fu-berlin.de> Date: Thu, 16 Apr 2009 16:32:38 +0200 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.21 (X11/20090410) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <49E4B516.2080901@mail.zedat.fu-berlin.de> <20090415160311.2e898844@ernst.jennejohn.org> <49E5EE04.1050208@zedat.fu-berlin.de> <200904152053.56058.vehemens@verizon.net> <49E6E833.3010105@zedat.fu-berlin.de> <49E6F29E.7050004@zedat.fu-berlin.de> <20090416133934.40427f74@ernst.jennejohn.org> In-Reply-To: <20090416133934.40427f74@ernst.jennejohn.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.13.16 X-Mailman-Approved-At: Thu, 16 Apr 2009 21:12:18 +0000 Cc: freebsd-x11 , freebsd-current@freebsd.org, "O. Hartmann" Subject: Re: Xorg/X11 driver Radeon: radeon vs. radeonhd, a mess! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 14:32:33 -0000 Gary Jennejohn wrote: > On Thu, 16 Apr 2009 08:55:58 +0000 > "O. Hartmann" wrote: > > [very large snip - radeonhd with dri kills Xorg] > >> Please forget about the log file 'Xorg.0.log'. X-server does not write >> properly a suitable log, so the log is always the last successfully >> written log. >> >> > > So it's crashing before it can even write the log. > > >> I tried starting X via 'startx', redirecting the log, but whenever the >> server starts, the box crashes/reboots. >> >> > > No crash dump from the kernel? > > How about starting it in gdb? That might give you a chance to narrow > down where it's crashing, if gdb can stop it before the box crashes. > > --- > Gary Jennejohn > No, no crash dump from kernel. Just before the box dies and reboots, I can see a completely distorted mousepointer / sprite. I saw this before with electrically damaged garphics devices, so I will exchange it with another one of which I know it's working. I'll try starting X within gdb, but I can perform this not today. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 21:12:46 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 98AC7106567B; Thu, 16 Apr 2009 21:12:46 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6568FC1E; Thu, 16 Apr 2009 21:12:45 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n3GLCfrH016446; Thu, 16 Apr 2009 15:12:41 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49E79F49.6000606@samsco.org> Date: Thu, 16 Apr 2009 15:12:41 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: John Baldwin References: <200904161336.18557.jhb@freebsd.org> <20090416184738.GA60409@wep4035.physik.uni-wuerzburg.de> <200904161558.56919.jhb@freebsd.org> In-Reply-To: <200904161558.56919.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Alexey Shuvaev , current@freebsd.org Subject: Re: [PATCH] Possible fix to recent data corruption on HEAD since 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: Thu, 16 Apr 2009 21:12:47 -0000 John Baldwin wrote: > On Thursday 16 April 2009 2:47:38 pm Alexey Shuvaev wrote: >> On Thu, Apr 16, 2009 at 01:36:18PM -0400, John Baldwin wrote: >>> Due to some good sleuthing by avg@, >>> there is a patch that might fix the recent >>> reports of data corruption on current. It would explain some of the recent >>> reports where a file that was read would have missing gaps of bytes. The >>> problem is with the BUS_DMA_KEEP_PG_OFFSET changes to bus_dma. When a bounce >>> page was used by USB2, the changes to bus_dma would actually change the >>> starting virtual and physical addresses of the bounce page. When the bounce >>> page was no longer needed it was left in this bogus state. Later if another >>> device used the same bounce page for DMA it would use the wrong offset and >>> address. The issue there is if the second device was doing a full page of >>> I/O. In that case the DMA from the device would actually spill over into the >>> next page which could in theory be used by another DMA request. It could >>> also break alignment assumptions (since the previous PG_OFFSET may not be >>> aligned and the bus_dma code assumes bounce pages for the !PG_OFFSET case are >>> page aligned). The quick fix is to always restore the bounce page to the >>> normal state when a PG_OFFSET DMA request is finished. I'd actually prefer >>> not ever touching the page's starting addresses, but those changes would be >>> more invasive I believe. >>> >>> http://www.FreeBSD.org/~jhb/patches/dma_sg.patch >>> >> Am I right that hardware prerequisite in order to observe these problems >> is amd64 + 4Gb or more of RAM? > > Well, i386 with PAE would do it as well. Basically, you need USB + one other > device that use bounce pages and the other device ends up with corruption. > >> Is it possible to fabricate some (artificial) test case to stress this >> particular situation (interleaved use of bounce pages by USB and some other >> device (?HDD?))? > > I haven't constructed one though it might be possible to do so. > >> Asking because as I understand the data corruption is silent >> and affected consumer (of bounce pages) should have some mechanism >> of detecting this (e.g. zfs' CRCs). >> In my case stess testing unpatched system till UFS filesystems are dead >> is no fun... > > Understood. I know some other folks are going to test this and if there is > early success that may make the risk easier to take. > I have pretty high confidence that John and Andriy found the problem and fixed it with this patch. It'll be good to get it tested, but I think that the risk to tester will be pretty low. Scott From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 21:33: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 654261065834; Thu, 16 Apr 2009 21:33:00 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 0E23D8FC0A; Thu, 16 Apr 2009 21:32:59 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n3GLWqJt016570; Thu, 16 Apr 2009 15:32:52 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49E7A404.5090208@samsco.org> Date: Thu, 16 Apr 2009 15:32:52 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: John Baldwin References: <49BD117B.2080706@163.com> <20090416144251.GA1605@plebeian.afflictions.org> <200904161624.51920.jhb@freebsd.org> In-Reply-To: <200904161624.51920.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Damian Gerow , freebsd-current@freebsd.org, Richard Todd Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 21:33:01 -0000 John Baldwin wrote: > On Thursday 16 April 2009 2:36:48 pm Richard Todd wrote: >> Damian Gerow writes: >>> 1) Reverting the extended attribute locking change (r189967) does not change >>> the situation for me. I still experience checksum issues and data loss. >>> (Unsurprisingly.) >>> >>> 2) Without umass loaded, I have been completely unable to trigger the issue. >>> >>> 3) Once umass is loaded, and the symptoms start cropping up, unloading umass >>> does not make them go away (again, unsurprisingly). What I haven't yet >>> tested, but am currently working towards, is whether removing umass stops >>> further checksum errors from ocurring. >>> >>> 4) r189967 does remove some LORs for me, even though I don't use (that I >>> know of) extended attributes. >>> >>> 5) It seems that so long as umass is used at all, the symptoms will >>> eventually show up. I've been able to trigger the symptoms by inserting >>> then removing a umass device immediately after boot, then ramping up the >>> workload. >>> >>> 6) The only difference made by vfs.zfs.debug=1 is that zfs reclaims are >>> logged. >>> >>> I'm at a bit of a loss as to what to test next, other than checking for an >>> increased number of checksum errors after unloading umass. However, I'm not >>> convinced this is going to highlight the actual problem. I'm all ears as to >>> what to test for at this point, as I'm running out of ideas. >> I have a question or two, and an idea. >> >> The questions: >> >> 1) How much RAM do you have, is it 4G or more? (I'm guessing the >> answer is "yes".) >> >> 2) What does "sysctl -a | grep bounced" say? Check this both before and after >> loading umass and seeing the bug triggered. >> >> My idea: I suspect a bug in the bounce-buffer code that does I/O to memory >> space beyond the area a given piece of hardware can access directly thru DMA. >> I've had some similar issues with checksum errors, and they seem to have gone >> away since lowering hw.physmem to 3400M in loader.conf, which cuts memory >> usage down below the point where anything needs to use bounce buffers. >> You might try lowering hw.physmem and see if that helps; check with the >> "sysctl -a | grep bounced" command, you should be seeing something like >> >> hw.busdma.zone0.total_bounced: 0 >> hw.busdma.zone1.total_bounced: 0 >> hw.busdma.zone2.total_bounced: 0 >> >> if no bounce-buffer usage is going on. (The number of zones may be different >> on your system.) > > Can you please try http://www.FreeBSD.org/~jhb/patches/dma_pg.patch? This > lines up with your analysis in that it fixes a problem in the bounce buffer > code that was introduced with the new USB stack (and only triggers when the > USB code has to use a bounce buffer). > As a data point, most normal I/O is not going to trigger this bug, even if it gets bounced. I/O using O_DIRECT can, and GEOM discovery I/O can as well. Since memory is allocated from the top of the system, I think that the damage gets done early during boot, and then propagates out over time as the system becomes busier. Scott From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 21: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 38684106566B for ; Thu, 16 Apr 2009 21:48:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0A66C8FC18 for ; Thu, 16 Apr 2009 21:48:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9EAD546B03; Thu, 16 Apr 2009 17:48:16 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id A330D8A01A; Thu, 16 Apr 2009 17:48:15 -0400 (EDT) From: John Baldwin To: Scott Long Date: Thu, 16 Apr 2009 17:48:07 -0400 User-Agent: KMail/1.9.7 References: <49BD117B.2080706@163.com> <200904161624.51920.jhb@freebsd.org> <49E7A404.5090208@samsco.org> In-Reply-To: <49E7A404.5090208@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904161748.08402.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 16 Apr 2009 17:48:15 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Damian Gerow , freebsd-current@freebsd.org, Richard Todd Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 21:48:17 -0000 On Thursday 16 April 2009 5:32:52 pm Scott Long wrote: > John Baldwin wrote: > > Can you please try http://www.FreeBSD.org/~jhb/patches/dma_pg.patch? This > > lines up with your analysis in that it fixes a problem in the bounce buffer > > code that was introduced with the new USB stack (and only triggers when the > > USB code has to use a bounce buffer). > > > > As a data point, most normal I/O is not going to trigger this bug, even > if it gets bounced. I/O using O_DIRECT can, and GEOM discovery I/O can > as well. Since memory is allocated from the top of the system, I think > that the damage gets done early during boot, and then propagates out > over time as the system becomes busier. Hmm, are you sure regular I/O won't trigger it as well? All it takes is for any USB transfer that starts off within a page to get a page into a non-zero offset and later have a request >= PAGE_SIZE bounce. Since the VM is going to always ask for I/O to pages (e.g. GET/PUTPAGES) normal disk I/O would break if it uses the bad bounce page I think. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 21:53: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 E057A106566C; Thu, 16 Apr 2009 21:53:41 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 8F98D8FC1A; Thu, 16 Apr 2009 21:53:41 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n3GLrZPI016717; Thu, 16 Apr 2009 15:53:35 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49E7A8DF.9080902@samsco.org> Date: Thu, 16 Apr 2009 15:53:35 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: John Baldwin References: <49BD117B.2080706@163.com> <200904161624.51920.jhb@freebsd.org> <49E7A404.5090208@samsco.org> <200904161748.08402.jhb@freebsd.org> In-Reply-To: <200904161748.08402.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.6 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Damian Gerow , freebsd-current@freebsd.org, Richard Todd Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 21:53:42 -0000 John Baldwin wrote: > On Thursday 16 April 2009 5:32:52 pm Scott Long wrote: >> John Baldwin wrote: >>> Can you please try http://www.FreeBSD.org/~jhb/patches/dma_pg.patch? This >>> lines up with your analysis in that it fixes a problem in the bounce > buffer >>> code that was introduced with the new USB stack (and only triggers when > the >>> USB code has to use a bounce buffer). >>> >> As a data point, most normal I/O is not going to trigger this bug, even >> if it gets bounced. I/O using O_DIRECT can, and GEOM discovery I/O can >> as well. Since memory is allocated from the top of the system, I think >> that the damage gets done early during boot, and then propagates out >> over time as the system becomes busier. > > Hmm, are you sure regular I/O won't trigger it as well? All it takes is for > any USB transfer that starts off within a page to get a page into a non-zero > offset and later have a request >= PAGE_SIZE bounce. Since the VM is going > to always ask for I/O to pages (e.g. GET/PUTPAGES) normal disk I/O would > break if it uses the bad bounce page I think. > Sorry, I knew what I meant but didn't say it that well. Once it gets triggered, it poisons that bounce page from thereon out, and any I/O will be affected. But the only I/O that will typically trigger it is GEOM scanning and O_DIRECT. Scott From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 22:04: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 01004106566B for ; Thu, 16 Apr 2009 22:04:49 +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 C72198FC1D for ; Thu, 16 Apr 2009 22:04:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7ABE446B03; Thu, 16 Apr 2009 18:04:48 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 7B20D8A01A; Thu, 16 Apr 2009 18:04:47 -0400 (EDT) From: John Baldwin To: Scott Long Date: Thu, 16 Apr 2009 18:04:41 -0400 User-Agent: KMail/1.9.7 References: <49BD117B.2080706@163.com> <200904161748.08402.jhb@freebsd.org> <49E7A8DF.9080902@samsco.org> In-Reply-To: <49E7A8DF.9080902@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904161804.42399.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 16 Apr 2009 18:04:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Damian Gerow , freebsd-current@freebsd.org, Richard Todd Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 22:04:49 -0000 On Thursday 16 April 2009 5:53:35 pm Scott Long wrote: > John Baldwin wrote: > > On Thursday 16 April 2009 5:32:52 pm Scott Long wrote: > >> John Baldwin wrote: > >>> Can you please try http://www.FreeBSD.org/~jhb/patches/dma_pg.patch? This > >>> lines up with your analysis in that it fixes a problem in the bounce > > buffer > >>> code that was introduced with the new USB stack (and only triggers when > > the > >>> USB code has to use a bounce buffer). > >>> > >> As a data point, most normal I/O is not going to trigger this bug, even > >> if it gets bounced. I/O using O_DIRECT can, and GEOM discovery I/O can > >> as well. Since memory is allocated from the top of the system, I think > >> that the damage gets done early during boot, and then propagates out > >> over time as the system becomes busier. > > > > Hmm, are you sure regular I/O won't trigger it as well? All it takes is for > > any USB transfer that starts off within a page to get a page into a non-zero > > offset and later have a request >= PAGE_SIZE bounce. Since the VM is going > > to always ask for I/O to pages (e.g. GET/PUTPAGES) normal disk I/O would > > break if it uses the bad bounce page I think. > > > > Sorry, I knew what I meant but didn't say it that well. Once it gets > triggered, it poisons that bounce page from thereon out, and any I/O > will be affected. But the only I/O that will typically trigger it is > GEOM scanning and O_DIRECT. Ah, ok. Actually, couldn't any USB request trigger it (so long as the source buffer isn't page aligned?) E.g. if you malloc()'d a 16-byte buffer and used it to receive some descriptor for the keyboard driver and malloc() used a backing page > 4GB, wouldn't that bounce and end up breaking a bounce page? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 22:08: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 B43961065672; Thu, 16 Apr 2009 22:08:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 484128FC14; Thu, 16 Apr 2009 22:08:13 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n3GM835A016814; Thu, 16 Apr 2009 16:08:04 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49E7AC43.8050901@samsco.org> Date: Thu, 16 Apr 2009 16:08:03 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: John Baldwin References: <49BD117B.2080706@163.com> <200904161748.08402.jhb@freebsd.org> <49E7A8DF.9080902@samsco.org> <200904161804.42399.jhb@freebsd.org> In-Reply-To: <200904161804.42399.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Damian Gerow , freebsd-current@freebsd.org, Richard Todd Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 22:08:15 -0000 John Baldwin wrote: > On Thursday 16 April 2009 5:53:35 pm Scott Long wrote: >> John Baldwin wrote: >>> On Thursday 16 April 2009 5:32:52 pm Scott Long wrote: >>>> John Baldwin wrote: >>>>> Can you please try http://www.FreeBSD.org/~jhb/patches/dma_pg.patch? > This >>>>> lines up with your analysis in that it fixes a problem in the bounce >>> buffer >>>>> code that was introduced with the new USB stack (and only triggers when >>> the >>>>> USB code has to use a bounce buffer). >>>>> >>>> As a data point, most normal I/O is not going to trigger this bug, even >>>> if it gets bounced. I/O using O_DIRECT can, and GEOM discovery I/O can >>>> as well. Since memory is allocated from the top of the system, I think >>>> that the damage gets done early during boot, and then propagates out >>>> over time as the system becomes busier. >>> Hmm, are you sure regular I/O won't trigger it as well? All it takes is > for >>> any USB transfer that starts off within a page to get a page into a > non-zero >>> offset and later have a request >= PAGE_SIZE bounce. Since the VM is > going >>> to always ask for I/O to pages (e.g. GET/PUTPAGES) normal disk I/O would >>> break if it uses the bad bounce page I think. >>> >> Sorry, I knew what I meant but didn't say it that well. Once it gets >> triggered, it poisons that bounce page from thereon out, and any I/O >> will be affected. But the only I/O that will typically trigger it is >> GEOM scanning and O_DIRECT. > > Ah, ok. Actually, couldn't any USB request trigger it (so long as the source > buffer isn't page aligned?) E.g. if you malloc()'d a 16-byte buffer and used > it to receive some descriptor for the keyboard driver and malloc() used a > backing page > 4GB, wouldn't that bounce and end up breaking a bounce page? > It could, and if that's happening, then some proactive measures should be taken by the usb code to generate buffers that won't bounce. It would suck to have to go through the bounce code for every single keystroke or mouse movement. I haven't looked at the new usb code, though, and I thought that the old code did a contigmalloc of some sort to avoid this. Scott From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 22:17: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 6BA2D1065675 for ; Thu, 16 Apr 2009 22:17:36 +0000 (UTC) (envelope-from dandee@hellteam.net) Received: from lucifer.hellteam.net (lucifer.hellteam.net [88.86.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id ECCB08FC17 for ; Thu, 16 Apr 2009 22:17:35 +0000 (UTC) (envelope-from dandee@hellteam.net) Received: from smtp.hellteam.net (rik.hellteam.net [78.108.102.225]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by lucifer.hellteam.net (Postfix) with ESMTPS id 8A7F23D1; Fri, 17 Apr 2009 00:06:50 +0200 (CEST) Received: from gandalf (devnull.hellteam.net [78.108.103.110]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.hellteam.net (Postfix) with ESMTPSA id D9093570050; Fri, 17 Apr 2009 00:02:11 +0200 (CEST) From: =?ISO-8859-1?Q?Daniel_Dvor=E1k?= To: "'Sam Leffler'" References: <49AB456E.3090105@errno.com> Date: Fri, 17 Apr 2009 00:02:11 +0200 Organization: Projekt HELL Message-ID: <5B009A189F2448B7B46CEDEFB456702D@tocnet28.jspoj.czf> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49AB456E.3090105@errno.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Importance: High Thread-Index: Acma38rxAU3ALlc5Qau91CLf9eseZwj/C7Ug Cc: freebsd-current@freebsd.org Subject: RE: HEADS UP: new wpa_supplicant and hostapd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@hellteam.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 22:17:36 -0000 Hi Sam, I would like to inform you about just successfully tested wired driver with wpa_supplicant in startting process of OS. 802.1x configuration with PEAP. Version of wpa_supplicant is lower than last imported. server# egrep em0 /etc/rc.conf ifconfig_em0="WPA DHCP" server# uname -a FreeBSD server 7.1-RELEASE-p4 FreeBSD 7.1-RELEASE-p4 #0: Sun Mar 22 12:35:36 UTC 2009 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 server# cat /etc/wpa_supplicant.conf update_config=1 ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel eapol_version=1 ap_scan=0 fast_reauth=1 network={ eapol_flags=0 key_mgmt=IEEE8021X eap=PEAP identity="SERVER$" password="!--- Output suppressed" # ca_cert="" phase1="peaplabel=0 peapver=1 include_tls_length=1" phase2="auth=MSCHAPV2" } server# wpa_supplicant -v wpa_supplicant v0.5.10 Copyright (c) 2003-2008, Jouni Malinen and contributors server# wpa_cli status Selected interface 'em0' bssid=01:80:c2:00:00:03 ssid= id=0 pairwise_cipher=NONE group_cipher=NONE key_mgmt=IEEE 802.1X (no WPA) wpa_state=COMPLETED ip_address=W.X.Y.Z Supplicant PAE state=AUTHENTICATED suppPortStatus=Authorized EAP state=SUCCESS selectedMethod=25 (EAP-PEAP) EAP TLS cipher=AES256-SHA EAP-PEAPv1 Phase2 method=MSCHAPV2 GREATCISCOSWITCH6500#sh dot1x interface gigabitEthernet 7/3 details Dot1x Info for GigabitEthernet7/3 ----------------------------------- PAE = AUTHENTICATOR PortControl = AUTO ControlDirection = Both HostMode = SINGLE_HOST ReAuthentication = Enabled QuietPeriod = 10 ServerTimeout = 30 SuppTimeout = 30 ReAuthPeriod = 3600 (Locally configured) ReAuthMax = 1 MaxReq = 1 TxPeriod = 20 Mac-Auth-Bypass = Enabled Dot1x Authenticator Client List ------------------------------- Supplicant = 00c0.wxyz.2c1f Auth SM State = AUTHENTICATED Auth BEND SM Stat = IDLE Port Status = AUTHORIZED ReAuthPeriod = 3600 ReAuthAction = Reauthenticate TimeToNextReauth = 2367 Authentication Method = Dot1x User-Name = SERVER$ Authorized By = Authentication Server Vlan Policy = 437 Starting wpa_supplicant. em0: no link ... . . got link DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 7 DHCPOFFER from W.X.Y.Z DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from W.X.Y.Z bound to W.X.Y.Z -- renewal in 345600 seconds. lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:c0:wx:yz:2c:1f inet W.X.Y.Z netmask 0xffffff00 broadcast W.X.Y.Z media: Ethernet autoselect (1000baseTX ) status: active I had to add em* definition to /etc/rc.d/wpa_supplicant script to execute wpa_supplicant with -Dwired, because fbsd 7.1 does not support it by default. And I would like to ask you to change it in fbsd 7.2, becuase it works and newer version 0.6.8 is not needed. ifn="$2" if [ -z "$ifn" ]; then return 1 fi case ${ifn} in ndis*) driver="ndis" ;; em*) driver="wired" ;; *) driver="bsd" ;; esac Bye Daniel -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Sam Leffler Sent: Monday, March 02, 2009 3:33 AM To: freebsd-current@freebsd.org Subject: HEADS UP: new wpa_supplicant and hostapd I've imported v0.6.8 which is now the tip of the stable branch in Jouni's repository. One side effect is there is now a combined tree in contrib. You should see no regressions but this has been lightly tested so beware (and -Dwired support in wpa_supplicant is not tested). Not sure what new functionality comes with this code. If something is not enabled in the build that should be please let me know. Sam _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 23:19: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 819F61065672 for ; Thu, 16 Apr 2009 23:19:45 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: from marklar.blazingdot.com (marklar.blazingdot.com [207.154.84.83]) by mx1.freebsd.org (Postfix) with SMTP id D28508FC19 for ; Thu, 16 Apr 2009 23:19:43 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: (qmail 43680 invoked by uid 503); 16 Apr 2009 22:53:02 -0000 Date: Thu, 16 Apr 2009 15:53:02 -0700 From: Marcus Reid To: Andrew Thompson Message-ID: <20090416225302.GA39766@blazingdot.com> References: <1237804575.1771.7.camel@balrog.2hip.net> <1237884572.1771.28.camel@balrog.2hip.net> <20090330061036.GA83528@citylink.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090330061036.GA83528@citylink.fud.org.nz> X-Coffee-Level: nearly-fatal User-Agent: Mutt/1.5.6i Cc: freebsd-current@freebsd.org, Nenhum_de_Nos , Robert Noland Subject: Re: Booting from usb hard disk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 23:19:46 -0000 On Sun, Mar 29, 2009 at 11:10:36PM -0700, Andrew Thompson wrote: > On Tue, Mar 24, 2009 at 03:49:32AM -0500, Robert Noland wrote: > > On Mon, 2009-03-23 at 19:40 -0300, Nenhum_de_Nos wrote: > > > On Mon, March 23, 2009 07:36, Robert Noland wrote: > > > > So I have my i386 install on a usb hard disk, which I can only boot on > > > > one machine now. The one machine that I can make work has a bios option > > > > that reads "BIOS ehci handoff". This used to work with the old usb > > > > stack. The machines that it doesn't work on, boot the kernel, but fail > > > > to mount root, giving me the forbidding mountroot> prompt, which is > > > > immediately followed by the message saying that da0 is attached. da0 is > > > > however not listed in the available boot devices list. I tried playing > > > > around with the timeout in vfs_mount.c, but that didn't seem to have any > > > > impact. It has been suggested that this may be a "geom" timeout, but I > > > > don't know anything about the boot system really. > > > > > > I had problem a while ago with via mini itx hardware, that was quite > > > close. If I try boot from usb (installed in usb hdd), I get to the point > > > of loader not finding my disk. > > > > > > I then used a small flash disk attached to the ata (44 pin ide) channel > > > and formatted /boot in there. this way I get to the point of mount root > > > you said, and da0 not being alive soon enough to mount root. list disks > > > also couldn't find da0 though. > > > > > > I tried current from that time, and no good. > > > > > > if this is solved, I'll be happy to try whatever patch to current. (as > > > long as I can install it from another box/or its ata channel, as it can't > > > boot vanilla 7.1R) > > > > So, my solution was to set kern.cam.scsi_delay=10000 > > in /boot/loader.conf > > The following patch should work. It creates interleaving root hold > tokens from the CAM probe to disk_create and geom providor tasting. > I had to add a malloc type flag as sleeping isnt allowed at the point I > added the token alloc in CAM. > > http://people.freebsd.org/~thompsa/root_wait.diff > > It needs review by the various geom/cam ppls. I'm running up against the problems booting from USB that are (somewhat) fixed by your patch. I noticed that it was comitted but reverted due to not being the correct approach. Setting kern.cam.scsi_delay=10000 doesn't work for me either. Is there another way to work around it? Thanks, Marcus From owner-freebsd-current@FreeBSD.ORG Thu Apr 16 23:25:46 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 CFA74106566C for ; Thu, 16 Apr 2009 23:25:45 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 85E748FC17 for ; Thu, 16 Apr 2009 23:25:45 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n3GNPjnD015851 for current@freebsd.org; Thu, 16 Apr 2009 16:25:45 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id vmf7yndvyyasujzukbn9bvrqya; for current@freebsd.org; Thu, 16 Apr 2009 16:25:45 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <49E7BE78.6000802@freebsd.org> Date: Thu, 16 Apr 2009 16:25:44 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090409 SeaMonkey/1.1.15 MIME-Version: 1.0 To: "'current@FreeBSD.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Weird warnings from lots of applications X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 16 Apr 2009 23:25:47 -0000 Here's a sample of the warnings I'm seeing whenever I start up emacs. This is -CURRENT from about two weeks ago with all ports upgraded within the last week: :1: error: scanner: digit is beyond radix - e.g. `style' :1: error: unexpected character `\222', expected character `=' :1: error: unexpected character `{', expected keyword - e.g. `style' I've seen this with other applications as well (firefox3, gimp), so it's not an emacs-specific issue. From ktrace, it looks like someone is getting confused trying to read the current directory (the current directory at this point is /home/tim/t/foo/barfoo): 43423 initial thread CALL open(0x864ca80,O_RDONLY,0) 43423 initial thread NAMI "/home/tim/t/foo/barfoo" 43423 initial thread RET open 6 43423 initial thread CALL read(0x6,0x864e000,0xfa0) 43423 initial thread GIO fd 6 read 512 bytes 0x0000 7b4b 9200 0c00 0401 2e00 0000 754b 9200 0c00 ... 43423 initial thread RET read 512/0x200 43423 initial thread CALL write(0x2,0xbfbfd180,0x4) 43423 initial thread GIO fd 2 wrote 4 bytes ":1: " 43423 initial thread RET write 4 43423 initial thread CALL write(0x2,0x28a56d9d,0x7) 43423 initial thread GIO fd 2 wrote 7 bytes "error: " 43423 initial thread RET write 7 43423 initial thread CALL write(0x2,0xbfbfd180,0x3a) 43423 initial thread GIO fd 2 wrote 58 bytes "unexpected character `{', expected keyword - e.g. `style' " Note that the character being warned about is exactly the first byte in the directory. This also matches the obvservation that the exact error message varies depending on the current directory. My current theory is that some library is trying to read and parse an initialization file and opening the wrong thing, but I'm not having much luck narrowing the exact library responsible. Has anyone else managed to narrow this down? Tim From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 00:39: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 032BE1065745 for ; Fri, 17 Apr 2009 00:39:57 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by mx1.freebsd.org (Postfix) with ESMTP id ADDE98FC16 for ; Fri, 17 Apr 2009 00:39:56 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk20 with SMTP id 20so1949786gxk.19 for ; Thu, 16 Apr 2009 17:39:56 -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=jnIcE0gjDguc/AszrF0LdWJwR2DcXOFB/xmp3lLneZQ=; b=FldIYLP0MmKBYkAIdrC76Xqus3rZFVbBV38tVekKx9qx/FR0KvYL2Gb1iMyJwt4DDJ opHQEHFSIn0u4VyXKUX5koPn8WUvD8DSv7Z5m7MdAh83o2EMFpWLvRLGV4tE+ONkyc2e TU+KtfQMFHa3pZP7gxmebKwJKntYbUyq1w9bY= 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=Og9nVqCJjQE3hF1xfllIHcQMhLlBQLxzxVIBOrOPk1dkrZOHtmRLdn35Ok2I71ySS6 TW9cbHO2pGhiX/a0jfUFmRMJlSrapsMFA4OGMxFmSJEI/TlBucXVK0Qmap2MHUeVbZmG yvrYgPacvfGjHG3522v7vbVvP/0qwTu2uGg7M= MIME-Version: 1.0 Received: by 10.90.117.17 with SMTP id p17mr2422928agc.30.1239928796111; Thu, 16 Apr 2009 17:39:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Apr 2009 17:39:56 -0700 Message-ID: From: Maksim Yevmenkin To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: core dump with bluetooth device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 00:39:57 -0000 On Thu, Apr 16, 2009 at 12:59 PM, Alexander Best wrote: > hi there, > > i'm running r191076M. when i try to send files from my mobile phone to my > computer via bt the core dumps. here's a backtrace: > > Unread portion of the kernel message buffer: > sblastmbufchk: sb_mb 0xc8d54d00 sb_mbtail 0 last 0xc8d54d00 > packet tree: > =A0 =A0 =A0 =A00xc8d54d00 > panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:797 > cpuid =3D 0 are you, by change, have "options SOCKBUF_DEBUG" in your kernel? thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 01:30: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 7FA49106566B for ; Fri, 17 Apr 2009 01:30:24 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1B4F28FC15 for ; Fri, 17 Apr 2009 01:30:23 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n3H1ULo9033189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Apr 2009 01:30:21 GMT (envelope-from ben@wanderview.com) Message-Id: <7DEF7288-1304-4A64-8A23-BB03349653EA@wanderview.com> From: Ben Kelly To: Artem Belevich 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 v930.3) Date: Thu, 16 Apr 2009 21:30:21 -0400 References: <49C2CFF6.8070608@egr.msu.edu> <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> X-Mailer: Apple Mail (2.930.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: freebsd-current@freebsd.org Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 01:30:24 -0000 On Apr 15, 2009, at 12:35 AM, Artem Belevich wrote: > I'll give it a try in a few days. I'll let you know how it went. Just FYI, I was able to reproduce some of the failures with the original patch using an SMP vmware image. The new patch seems to fix these problems and I was able to successfully mount a zfs pool. > BTW, now that you're tinkering with ZFS threads and priorities, whould > you by any chance have any idea why zfs scrub is so painfully slow on > -current? > When I start scrub on my -stable box, it pretty much runs full speed > -- I can see disks under load all the time. > However on -current scrub seems to run in small bursts. Disks get busy > for a second or so and then things get quiet for about five seconds or > so and this pattern repeats over and over. I don't know. I haven't had to scrub my devices very often. I ran a couple here locally and did not see the behavior you describe. There is a significant delay between typing zpool scrub and when it actually begins disk I/O, but after that it completes without pause. If I get a chance I'll try to look at what the scrub code is doing. Thanks again. - Ben > --Artem > > > > On Tue, Apr 14, 2009 at 7:32 PM, Ben Kelly wrote: >> On Apr 14, 2009, at 11:50 AM, Ben Kelly wrote: >>> >>> On Apr 13, 2009, at 7:36 PM, Artem Belevich wrote: >>>> >>>> Tried your patch that used PRIBIO+{1,2} for priorities with - >>>> current >>>> r191008 and the kernel died with "spinlock held too long" panic. >>>> Actually, there apparently were two instances of panic on different >>>> cores.. >>>> >>>> Here's output of "alltrace" and "ps" after the crash: >>>> http://pastebin.com/f140f4596 >>>> >>>> I've reverted the change and kernel booted just fine. >>>> >>>> The box is quad-core with two ZFS pools -- one single-disk and >>>> another >>>> one is a two-disk mirror. Freebsd is installed on UFS partitions, >>>> ZFS >>>> is used for user stuff only. >>> >>> Thanks for the report! >>> >>> I don't have a lot of time to look at this today, but it appears >>> that >>> there is a race condition on SMP machines when setting the priority >>> immediately after the kproc is spawned. As a quick hack I tried >>> adding a >>> pause between the kproc_create() and the sched_prio(). Can you >>> try this >>> patch? >>> >>> >>> http://www.wanderview.com/svn/public/misc/zfs_livelock/zfs_thread_priority.diff >>> >>> I'll try to take a closer look at this later in the week. >> >> Sorry for replying to my own e-mail, but I've updated the patch >> again with a >> less hackish approach. (At the same URL above.) I added a new >> kproc_create_priority() function to set the priority of the new >> thread >> before its first scheduled. This should avoid any SMP races with >> setting >> the priority from an external thread. >> >> If you would be willing to try the test again with this new patch I >> would >> appreciate it. >> >> Thanks! >> >> - Ben >> From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 01:32: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 848C31065675 for ; Fri, 17 Apr 2009 01:32:48 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 283CC8FC08 for ; Fri, 17 Apr 2009 01:32:47 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n3H1WjUm033207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Apr 2009 01:32:45 GMT (envelope-from ben@wanderview.com) Message-Id: From: Ben Kelly To: Peter Schuller In-Reply-To: <20090416132302.GA86096@hyperion.scode.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 21:32:45 -0400 References: <49C2CFF6.8070608@egr.msu.edu> <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> <20090416132302.GA86096@hyperion.scode.org> X-Mailer: Apple Mail (2.930.3) X-Spam-Score: -1.44 () ALL_TRUSTED,AWL X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: freebsd-current@freebsd.org, Artem Belevich Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 01:32:48 -0000 On Apr 16, 2009, at 9:23 AM, Peter Schuller wrote: >> BTW, now that you're tinkering with ZFS threads and priorities, >> whould >> you by any chance have any idea why zfs scrub is so painfully slow on >> -current? >> When I start scrub on my -stable box, it pretty much runs full speed >> -- I can see disks under load all the time. >> However on -current scrub seems to run in small bursts. Disks get >> busy >> for a second or so and then things get quiet for about five seconds >> or >> so and this pattern repeats over and over. > > This is intentional. The newer ZFS code has, if I remember correctly, > something like "spend at most 1/5 of the time doing scrub for each > underlying vdev". I could be wrong on the details and I don't have > source refs off-hand, by I looked into this when I wanted to see if I > could tweak this (while I definitely like it rate limited, I would > have liked to up the threshold a bit). My conclusion at the time was > that there was no way to tweak it other than recompiling the kernel. I find it odd that they would pause for up to 5 seconds, though. I would expect the throttling to occur over a much smaller time span. Do you see similarly large pauses in disk I/O during a scrub? - Ben From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 02:22: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 C457B106566B for ; Fri, 17 Apr 2009 02:22:15 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 8019F8FC24 for ; Fri, 17 Apr 2009 02:22:15 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so440271yxm.13 for ; Thu, 16 Apr 2009 19:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=YFhx5AzRInjdmCVENtTpWbHj8bvRbg5BqpRqGFkLOPA=; b=OuOe1qeL08qB8gr3agcjkWo/x7PmqH6zN19Pg3vso6bkkO3DiHO11SRfXQ4kP+vW5E n63YfYmjOFZ5uMnicYbx2xT1kNyOzHatwSvhNYtQtJ0IiCwcj5lQur7N7HPJnBqGCxdq meC6dOaCTXvsvrnDwHCYcwBevbvlPfHTkZoHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Bs3RUtNjLgtDjf4XNXiCGwHyY5IKVp8FGUFzSnPSIEPZn3XyW0tdTvEQ6eFdpNIWF6 zG3ciz4jAH6rlbfx/8RrCZD66J72VKZyc1mDl856DEwtqYKvWtZp4IhlRnsXXNC2h7R1 68P5zxOThnnqj1TZyCh9C7H8rONC0PjodHSz0= MIME-Version: 1.0 Received: by 10.90.96.1 with SMTP id t1mr2498148agb.61.1239934934726; Thu, 16 Apr 2009 19:22:14 -0700 (PDT) Date: Thu, 16 Apr 2009 19:22:14 -0700 Message-ID: From: Maksim Yevmenkin To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best Subject: possible bug in the sbappendrecord_locked()? (Was: Re: core dump with bluetooth device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 02:22:16 -0000 On Thu, Apr 16, 2009 at 5:39 PM, Maksim Yevmenkin wrote: > On Thu, Apr 16, 2009 at 12:59 PM, Alexander Best > wrote: >> hi there, >> >> i'm running r191076M. when i try to send files from my mobile phone to m= y >> computer via bt the core dumps. here's a backtrace: >> >> Unread portion of the kernel message buffer: >> sblastmbufchk: sb_mb 0xc8d54d00 sb_mbtail 0 last 0xc8d54d00 >> packet tree: >> =A0 =A0 =A0 =A00xc8d54d00 >> panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:797 >> cpuid =3D 0 > > are you, by change, have "options =A0SOCKBUF_DEBUG" in your kernel? ok, there is something strange going on in the sbappendrecord_locked(). consider the following initial conditions: 1) sockbuf sb is empty, i.e. sb_mb =3D=3D sb_mbtail =3D=3D sb_lastrecord = =3D=3D NULL 2) sbappendrecord_locked() is given mbuf m0 with has exactly one mbuf, i.e. m0->m_next =3D=3D NULL so void sbappendrecord_locked(struct sockbuf *sb, struct mbuf *m0) { struct mbuf *m; SOCKBUF_LOCK_ASSERT(sb); if (m0 =3D=3D 0) return; m =3D sb->sb_mb; if (m) while (m->m_nextpkt) m =3D m->m_nextpkt; --> m is still NULL at this point /* * Put the first mbuf on the queue. Note this permits zero length * records. */ sballoc(sb, m0); SBLASTRECORDCHK(sb); --> passed successfully, because sb_mb =3D=3D sb_lastrecord =3D=3D NULL (i.= e. sockbuf is empty) SBLINKRECORD(sb, m0); --> at this point sb_mb =3D=3D sb_lastrecord =3D=3D m0, _but_ sb_mtail =3D= =3D NULL if (m) m->m_nextpkt =3D m0; else sb->sb_mb =3D m0; --> not sure about those lines above, didn't SBLINKRECORD(sb, m0) take care of it already? --> in any case, still, sb_mb =3D=3D sb_lastrecord =3D=3D m0 _and_ still sb_mtail =3D=3D NULL m =3D m0->m_next; m0->m_next =3D 0; --> m is still NULL here if (m && (m0->m_flags & M_EOR)) { m0->m_flags &=3D ~M_EOR; m->m_flags |=3D M_EOR; } --> sbcompress() is called with m =3D=3D NULL, which is triggers the panic (read below) sbcompress(sb, m, m0); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D void sbcompress(struct sockbuf *sb, struct mbuf *m, struct mbuf *n) { int eor =3D 0; struct mbuf *o; SOCKBUF_LOCK_ASSERT(sb); while (m) { --> lots of code that never gets executed because m =3D=3D NULL } if (eor) { KASSERT(n !=3D NULL, ("sbcompress: eor && n =3D=3D NULL")); n->m_flags |=3D eor; } --> this where panic happens, because sb_mbtail is still NULL, but sockbuf now contains exactly one record SBLASTMBUFCHK(sb); } so, it looks like, sbcompress() should only be called when m !=3D NULL. also, when m =3D=3D NULL, m0 should be marked as EOR. comments anyone? thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 02: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 068D41065673 for ; Fri, 17 Apr 2009 02:41:04 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id B0A148FC20 for ; Fri, 17 Apr 2009 02:41:03 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so442820yxm.13 for ; Thu, 16 Apr 2009 19:41:03 -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=/etj/X+t1/a8ja+IQReP5ZkmbcnQCWOjloECQPSqV7k=; b=IWlWQHHMoMnyHXU3kK/eOOIUSGEYKt9ZqFZgvEmNp2Qfd1cn+pzdn8TQJNREgz5J8D SCU3tQnM5q72aTjK8WxPFshAlwLAiGJPuYOLZwVNfhv+m2d3AVRXnqB971TXD7hFsIKW BAPxjPZh7BmLE+hiA0XPeyWbvijcVD31x4vw0= 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=rcN4o53auXtLUPy+84EJ9dgEMGVR02j5GaNPiLThElTD1a4o+4JXUC02+OrpgSybf6 7O+dZVMtbYJ9D5zxeHrTlggquo5dq0W9bUUyjaZjRClKeD+kFO0gn/Gzqkc7gpaIY924 rMWTyUsX39r3TM/Wg5dsOA4sBXALlCDV9ca4o= MIME-Version: 1.0 Received: by 10.90.105.6 with SMTP id d6mr2549298agc.1.1239936063012; Thu, 16 Apr 2009 19:41:03 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Apr 2009 19:41:02 -0700 Message-ID: From: Maksim Yevmenkin To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best Subject: Re: possible bug in the sbappendrecord_locked()? (Was: Re: core dump with bluetooth device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 02:41:04 -0000 On Thu, Apr 16, 2009 at 7:22 PM, Maksim Yevmenkin wrote: > On Thu, Apr 16, 2009 at 5:39 PM, Maksim Yevmenkin > wrote: >> On Thu, Apr 16, 2009 at 12:59 PM, Alexander Best >> wrote: >>> hi there, >>> >>> i'm running r191076M. when i try to send files from my mobile phone to = my >>> computer via bt the core dumps. here's a backtrace: >>> >>> Unread portion of the kernel message buffer: >>> sblastmbufchk: sb_mb 0xc8d54d00 sb_mbtail 0 last 0xc8d54d00 >>> packet tree: >>> =A0 =A0 =A0 =A00xc8d54d00 >>> panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:797 >>> cpuid =3D 0 >> >> are you, by change, have "options =A0SOCKBUF_DEBUG" in your kernel? > > ok, there is something strange going on in the > sbappendrecord_locked(). consider the following initial conditions: > > 1) sockbuf sb is empty, i.e. sb_mb =3D=3D sb_mbtail =3D=3D sb_lastrecord = =3D=3D NULL > > 2) sbappendrecord_locked() is given mbuf m0 with has exactly one mbuf, > i.e. m0->m_next =3D=3D NULL > > so > > void > sbappendrecord_locked(struct sockbuf *sb, struct mbuf *m0) > { > =A0 =A0 =A0 =A0struct mbuf *m; > > =A0 =A0 =A0 =A0SOCKBUF_LOCK_ASSERT(sb); > > =A0 =A0 =A0 =A0if (m0 =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; > =A0 =A0 =A0 =A0m =3D sb->sb_mb; > > =A0 =A0 =A0 =A0if (m) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0while (m->m_nextpkt) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m =3D m->m_nextpkt; > > --> m is still NULL at this point > > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 * Put the first mbuf on the queue. =A0Note this permits z= ero length > =A0 =A0 =A0 =A0 * records. > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0sballoc(sb, m0); > =A0 =A0 =A0 =A0SBLASTRECORDCHK(sb); > > --> passed successfully, because sb_mb =3D=3D sb_lastrecord =3D=3D NULL (= i.e. > sockbuf is empty) > > =A0 =A0 =A0 =A0SBLINKRECORD(sb, m0); > > --> at this point sb_mb =3D=3D sb_lastrecord =A0=3D=3D m0, _but_ sb_mtail= =3D=3D NULL > > =A0 =A0 =A0 =A0if (m) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m->m_nextpkt =3D m0; > =A0 =A0 =A0 =A0else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sb->sb_mb =3D m0; > > --> not sure about those lines above, didn't SBLINKRECORD(sb, m0) take > care of it already? > --> in any case, still, sb_mb =3D=3D sb_lastrecord =3D=3D m0 _and_ still > sb_mtail =3D=3D NULL > > =A0 =A0 =A0 =A0m =3D m0->m_next; > =A0 =A0 =A0 =A0m0->m_next =3D 0; > > --> m is still NULL here > > =A0 =A0 =A0 =A0if (m && (m0->m_flags & M_EOR)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m0->m_flags &=3D ~M_EOR; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m->m_flags |=3D M_EOR; > =A0 =A0 =A0 =A0} > > --> sbcompress() is called with m =3D=3D NULL, which is triggers the pani= c > (read below) > > =A0 =A0 =A0 =A0sbcompress(sb, m, m0); > } > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > void > sbcompress(struct sockbuf *sb, struct mbuf *m, struct mbuf *n) > { > =A0 =A0 =A0 =A0int eor =3D 0; > =A0 =A0 =A0 =A0struct mbuf *o; > > =A0 =A0 =A0 =A0SOCKBUF_LOCK_ASSERT(sb); > > =A0 =A0 =A0 =A0while (m) { > > --> lots of code that never gets executed because m =3D=3D NULL > > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0if (eor) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0KASSERT(n !=3D NULL, ("sbcompress: eor && = n =3D=3D NULL")); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0n->m_flags |=3D eor; > =A0 =A0 =A0 =A0} > > --> this where panic happens, because sb_mbtail is still NULL, but > sockbuf now contains exactly one record > > =A0 =A0 =A0 =A0SBLASTMBUFCHK(sb); > } > > so, it looks like, sbcompress() should only be called when m !=3D NULL. > also, when m =3D=3D NULL, m0 should be marked as EOR. actually, no, EOR should be set (or not set already). > comments anyone? i think there is also something strange going on in sbappendaddr_locked(), basically, int sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa, struct mbuf *m0, struct mbuf *control) { struct mbuf *m, *n, *nlast; int space =3D asa->sa_len; SOCKBUF_LOCK_ASSERT(sb); if (m0 && (m0->m_flags & M_PKTHDR) =3D=3D 0) panic("sbappendaddr_locked"); if (m0) space +=3D m0->m_pkthdr.len; space +=3D m_length(control, &n); if (space > sbspace(sb)) return (0); #if MSIZE <=3D 256 if (asa->sa_len > MLEN) return (0); #endif MGET(m, M_DONTWAIT, MT_SONAME); if (m =3D=3D 0) return (0); m->m_len =3D asa->sa_len; bcopy(asa, mtod(m, caddr_t), asa->sa_len); --> at this point n is not initialized, or at least i do not see where it was initialized. shouldn't be compiler giving a warning here? if (n) n->m_next =3D m0; /* concatenate data to control */ else control =3D m0; am i missing something obvious here? thanks max From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 02:45: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 2AC241065673 for ; Fri, 17 Apr 2009 02:45:05 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by mx1.freebsd.org (Postfix) with ESMTP id D66E18FC15 for ; Fri, 17 Apr 2009 02:45:04 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk20 with SMTP id 20so2035350gxk.19 for ; Thu, 16 Apr 2009 19:45: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 :content-transfer-encoding; bh=ms8gQG+rMOCkNoKgq58gNOt46Fbacceab4KVRDNOG+U=; b=W1XNiu5Z3ePJyCATIfuMZ0zY/AcqM2jV23P7GoTQcOHEIDly0QdjCwFSMMRBwGH2z0 FXfiPbuuIW8+V6PcckuawGaVhTOsKhZPfM5Jy6FwiNvFkaxj2/0Y83H8blZUiT1/9m+/ uWYmTUB0QgBRXkLOXwYxM6/6VSA4y3s1z5QsQ= 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=wdc6TipxfoBA4OrtC8rttAuPd/MWju84Dj0kL9H5Ow+KC5G8vsfEX0/nI3aIgG7pjM XVaMii9OVZyDS96juNlqgSdYSJ+fvpVMjzFYSePns6hBhGu92lBs6TW5PxQHkl3sl9Ly 9JN1TwjuFcDddI2FZP2D1idIEkRChr5uARZM4= MIME-Version: 1.0 Received: by 10.90.73.17 with SMTP id v17mr1886458aga.116.1239936304116; Thu, 16 Apr 2009 19:45:04 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Apr 2009 19:45:04 -0700 Message-ID: From: Maksim Yevmenkin To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best Subject: Re: possible bug in the sbappendrecord_locked()? (Was: Re: core dump with bluetooth device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 02:45:05 -0000 On Thu, Apr 16, 2009 at 7:41 PM, Maksim Yevmenkin wrote: > On Thu, Apr 16, 2009 at 7:22 PM, Maksim Yevmenkin > wrote: >> On Thu, Apr 16, 2009 at 5:39 PM, Maksim Yevmenkin >> wrote: >>> On Thu, Apr 16, 2009 at 12:59 PM, Alexander Best >>> wrote: >>>> hi there, >>>> >>>> i'm running r191076M. when i try to send files from my mobile phone to= my >>>> computer via bt the core dumps. here's a backtrace: >>>> >>>> Unread portion of the kernel message buffer: >>>> sblastmbufchk: sb_mb 0xc8d54d00 sb_mbtail 0 last 0xc8d54d00 >>>> packet tree: >>>> =A0 =A0 =A0 =A00xc8d54d00 >>>> panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:797 >>>> cpuid =3D 0 >>> >>> are you, by change, have "options =A0SOCKBUF_DEBUG" in your kernel? >> >> ok, there is something strange going on in the >> sbappendrecord_locked(). consider the following initial conditions: >> >> 1) sockbuf sb is empty, i.e. sb_mb =3D=3D sb_mbtail =3D=3D sb_lastrecord= =3D=3D NULL >> >> 2) sbappendrecord_locked() is given mbuf m0 with has exactly one mbuf, >> i.e. m0->m_next =3D=3D NULL >> >> so >> >> void >> sbappendrecord_locked(struct sockbuf *sb, struct mbuf *m0) >> { >> =A0 =A0 =A0 =A0struct mbuf *m; >> >> =A0 =A0 =A0 =A0SOCKBUF_LOCK_ASSERT(sb); >> >> =A0 =A0 =A0 =A0if (m0 =3D=3D 0) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; >> =A0 =A0 =A0 =A0m =3D sb->sb_mb; >> >> =A0 =A0 =A0 =A0if (m) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0while (m->m_nextpkt) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m =3D m->m_nextpkt; >> >> --> m is still NULL at this point >> >> =A0 =A0 =A0 =A0/* >> =A0 =A0 =A0 =A0 * Put the first mbuf on the queue. =A0Note this permits = zero length >> =A0 =A0 =A0 =A0 * records. >> =A0 =A0 =A0 =A0 */ >> =A0 =A0 =A0 =A0sballoc(sb, m0); >> =A0 =A0 =A0 =A0SBLASTRECORDCHK(sb); >> >> --> passed successfully, because sb_mb =3D=3D sb_lastrecord =3D=3D NULL = (i.e. >> sockbuf is empty) >> >> =A0 =A0 =A0 =A0SBLINKRECORD(sb, m0); >> >> --> at this point sb_mb =3D=3D sb_lastrecord =A0=3D=3D m0, _but_ sb_mtai= l =3D=3D NULL >> >> =A0 =A0 =A0 =A0if (m) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m->m_nextpkt =3D m0; >> =A0 =A0 =A0 =A0else >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sb->sb_mb =3D m0; >> >> --> not sure about those lines above, didn't SBLINKRECORD(sb, m0) take >> care of it already? >> --> in any case, still, sb_mb =3D=3D sb_lastrecord =3D=3D m0 _and_ still >> sb_mtail =3D=3D NULL >> >> =A0 =A0 =A0 =A0m =3D m0->m_next; >> =A0 =A0 =A0 =A0m0->m_next =3D 0; >> >> --> m is still NULL here >> >> =A0 =A0 =A0 =A0if (m && (m0->m_flags & M_EOR)) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m0->m_flags &=3D ~M_EOR; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m->m_flags |=3D M_EOR; >> =A0 =A0 =A0 =A0} >> >> --> sbcompress() is called with m =3D=3D NULL, which is triggers the pan= ic >> (read below) >> >> =A0 =A0 =A0 =A0sbcompress(sb, m, m0); >> } >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> void >> sbcompress(struct sockbuf *sb, struct mbuf *m, struct mbuf *n) >> { >> =A0 =A0 =A0 =A0int eor =3D 0; >> =A0 =A0 =A0 =A0struct mbuf *o; >> >> =A0 =A0 =A0 =A0SOCKBUF_LOCK_ASSERT(sb); >> >> =A0 =A0 =A0 =A0while (m) { >> >> --> lots of code that never gets executed because m =3D=3D NULL >> >> =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0if (eor) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0KASSERT(n !=3D NULL, ("sbcompress: eor &&= n =3D=3D NULL")); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0n->m_flags |=3D eor; >> =A0 =A0 =A0 =A0} >> >> --> this where panic happens, because sb_mbtail is still NULL, but >> sockbuf now contains exactly one record >> >> =A0 =A0 =A0 =A0SBLASTMBUFCHK(sb); >> } >> >> so, it looks like, sbcompress() should only be called when m !=3D NULL. >> also, when m =3D=3D NULL, m0 should be marked as EOR. > > actually, no, EOR should be set (or not set already). > >> comments anyone? > > i think there is also something strange going on in > sbappendaddr_locked(), basically, > > int > sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa, > =A0 =A0struct mbuf *m0, struct mbuf *control) > { > =A0 =A0 =A0 =A0struct mbuf *m, *n, *nlast; > =A0 =A0 =A0 =A0int space =3D asa->sa_len; > > =A0 =A0 =A0 =A0SOCKBUF_LOCK_ASSERT(sb); > > =A0 =A0 =A0 =A0if (m0 && (m0->m_flags & M_PKTHDR) =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0panic("sbappendaddr_locked"); > =A0 =A0 =A0 =A0if (m0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0space +=3D m0->m_pkthdr.len; > =A0 =A0 =A0 =A0space +=3D m_length(control, &n); > > =A0 =A0 =A0 =A0if (space > sbspace(sb)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); > #if MSIZE <=3D 256 > =A0 =A0 =A0 =A0if (asa->sa_len > MLEN) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); > #endif > =A0 =A0 =A0 =A0MGET(m, M_DONTWAIT, MT_SONAME); > =A0 =A0 =A0 =A0if (m =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); > =A0 =A0 =A0 =A0m->m_len =3D asa->sa_len; > =A0 =A0 =A0 =A0bcopy(asa, mtod(m, caddr_t), asa->sa_len); > > --> at this point n is not initialized, or at least i do not see where > it was initialized. shouldn't be compiler giving a warning here? > > =A0 =A0 =A0 =A0if (n) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0n->m_next =3D m0; =A0 =A0 =A0 =A0 /* conca= tenate data to control */ > =A0 =A0 =A0 =A0else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0control =3D m0; > > am i missing something obvious here? ignore the last one :) i missed m_length(control, &n). ok, need to get away from the screen :) thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 02:57:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92118106566C; Fri, 17 Apr 2009 02:57:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 58F7E8FC12; Fri, 17 Apr 2009 02:57:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H2vSaU071676; Thu, 16 Apr 2009 22:57:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H2vSlX068664; Thu, 16 Apr 2009 22:57:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C9AD87302F; Thu, 16 Apr 2009 22:57:28 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090417025728.C9AD87302F@freebsd-current.sentex.ca> Date: Thu, 16 Apr 2009 22:57:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on 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: Fri, 17 Apr 2009 02:57:32 -0000 TB --- 2009-04-17 01:55:45 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-17 01:55:45 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-04-17 01:55:45 - cleaning the object tree TB --- 2009-04-17 01:56:21 - cvsupping the source tree TB --- 2009-04-17 01:56:21 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-04-17 01:56:32 - building world TB --- 2009-04-17 01:56:32 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-17 01:56:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-17 01:56:32 - TARGET=sun4v TB --- 2009-04-17 01:56:32 - TARGET_ARCH=sparc64 TB --- 2009-04-17 01:56:32 - TZ=UTC TB --- 2009-04-17 01:56:32 - __MAKE_CONF=/dev/null TB --- 2009-04-17 01:56:32 - cd /src TB --- 2009-04-17 01:56:32 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 17 01:56:33 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/sun4v/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x10dc): In function `archive_write_mtree_data': : undefined reference to `SHA384_Update' /obj/sun4v/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x15dc): In function `archive_write_mtree_header': : undefined reference to `SHA512_Init' /obj/sun4v/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1874): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' /obj/sun4v/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x18bc): In function `archive_write_mtree_header': : undefined reference to `SHA384_Init' *** Error code 1 Stop in /obj/sun4v/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-17 02:57:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-17 02:57:28 - ERROR: failed to build world TB --- 2009-04-17 02:57:28 - 3119.58 user 318.08 system 3703.55 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 03:57:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57DBF1065672; Fri, 17 Apr 2009 03:57:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id F327F8FC1C; Fri, 17 Apr 2009 03:57:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H3vM0U078801; Thu, 16 Apr 2009 23:57:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H3vMB7095971; Thu, 16 Apr 2009 23:57:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 27A817302F; Thu, 16 Apr 2009 23:57:22 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090417035722.27A817302F@freebsd-current.sentex.ca> Date: Thu, 16 Apr 2009 23:57:22 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 03:57:26 -0000 TB --- 2009-04-17 03:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-17 03:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-04-17 03:00:00 - cleaning the object tree TB --- 2009-04-17 03:00:42 - cvsupping the source tree TB --- 2009-04-17 03:00:42 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-04-17 03:00:55 - building world TB --- 2009-04-17 03:00:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-17 03:00:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-17 03:00:55 - TARGET=arm TB --- 2009-04-17 03:00:55 - TARGET_ARCH=arm TB --- 2009-04-17 03:00:55 - TZ=UTC TB --- 2009-04-17 03:00:55 - __MAKE_CONF=/dev/null TB --- 2009-04-17 03:00:55 - cd /src TB --- 2009-04-17 03:00:55 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 17 03:01:00 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 [...] /obj/arm/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xd2c): In function `$a': : undefined reference to `SHA512_Update' /obj/arm/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1308): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' /obj/arm/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1408): In function `archive_write_mtree_header': : undefined reference to `SHA384_Init' /obj/arm/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1448): In function `archive_write_mtree_header': : undefined reference to `SHA512_Init' *** Error code 1 Stop in /obj/arm/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-17 03:57:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-17 03:57:21 - ERROR: failed to build world TB --- 2009-04-17 03:57:21 - 2614.54 user 331.42 system 3441.38 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 04:11: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 3AE47106566B; Fri, 17 Apr 2009 04:11:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id F21458FC0C; Fri, 17 Apr 2009 04:11:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H4BuLQ079619; Fri, 17 Apr 2009 00:11:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H4BuRo026708; Fri, 17 Apr 2009 00:11:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E77097302F; Fri, 17 Apr 2009 00:11:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090417041155.E77097302F@freebsd-current.sentex.ca> Date: Fri, 17 Apr 2009 00:11:55 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on 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: Fri, 17 Apr 2009 04:11:59 -0000 TB --- 2009-04-17 03:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-17 03:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-04-17 03:00:00 - cleaning the object tree TB --- 2009-04-17 03:01:20 - cvsupping the source tree TB --- 2009-04-17 03:01:20 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-04-17 03:01:30 - building world TB --- 2009-04-17 03:01:30 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-17 03:01:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-17 03:01:30 - TARGET=amd64 TB --- 2009-04-17 03:01:30 - TARGET_ARCH=amd64 TB --- 2009-04-17 03:01:30 - TZ=UTC TB --- 2009-04-17 03:01:30 - __MAKE_CONF=/dev/null TB --- 2009-04-17 03:01:30 - cd /src TB --- 2009-04-17 03:01:30 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 17 03:01:32 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 [...] /obj/amd64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xf0a): In function `archive_write_mtree_data': : undefined reference to `SHA384_Update' /obj/amd64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x13e4): In function `archive_write_mtree_header': : undefined reference to `SHA512_Init' /obj/amd64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1418): In function `archive_write_mtree_header': : undefined reference to `SHA384_Init' /obj/amd64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x14d8): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' *** Error code 1 Stop in /obj/amd64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-17 04:11:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-17 04:11:55 - ERROR: failed to build world TB --- 2009-04-17 04:11:55 - 3297.12 user 346.25 system 4315.39 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 04:19:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A9BE106566C for ; Fri, 17 Apr 2009 04:19:34 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-bw0-f165.google.com (mail-bw0-f165.google.com [209.85.218.165]) by mx1.freebsd.org (Postfix) with ESMTP id C622A8FC15 for ; Fri, 17 Apr 2009 04:19:33 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: by bwz9 with SMTP id 9so125379bwz.43 for ; Thu, 16 Apr 2009 21:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=jljJSa/qKPem9McApape++rF6lxdqGbawiAiN4rAqqM=; b=ovyPxELME6PhInaZkEnWa76MOYT01GmSXzCxU7n/OJMc+Mvpe/DU3/LXYlQavy81Tm 11ZwU6bi1BnVPUqJWdKMrffHt7mKg0+SyKqCWFWxWZ2274904jFJtcW7Hd/o+Vs5RQcm /FcMZw8rd8q/FGTICjmvr3tu/Dl8fI7+fV6QY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=GlulyzRqMYe+AoKcrkstj8LNvC9IHjdR47aW0VOWIMjTY3prOUHmI8tsOaAT5EHDTi CcpzzD6DeU4cLfCN9ukZ3SJn9oFYfTSoK4QzbKMcm/Jm1oQMbb2SVuh7wJe4lsy68tXs u277Ab8rU1xFB+o0B67iEL2vCT9SJgsPFreBw= Received: by 10.103.92.8 with SMTP id u8mr1111166mul.34.1239940731074; Thu, 16 Apr 2009 20:58:51 -0700 (PDT) Received: from ?157.181.96.136? (quark.teteny.elte.hu [157.181.96.136]) by mx.google.com with ESMTPS id 23sm4299860mum.23.2009.04.16.20.58.50 (version=SSLv3 cipher=RC4-MD5); Thu, 16 Apr 2009 20:58:50 -0700 (PDT) Message-ID: <49E7FED0.9090708@gmail.com> Date: Fri, 17 Apr 2009 06:00:16 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49E6ACEE.6080301@gmail.com> <200904161116.58094.jhb@freebsd.org> <1239913234.1991.1.camel@balrog.2hip.net> In-Reply-To: <1239913234.1991.1.camel@balrog.2hip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 04:19:34 -0000 Robert Noland wrote: > On Thu, 2009-04-16 at 11:16 -0400, John Baldwin wrote: >> On Wednesday 15 April 2009 11:58:38 pm deeptech71@gmail.com wrote: >>> I can reliably (~40%) reproduce a freeze, which I think is related. >>> >>> Using the GENERIC debug kernel built from SVN HEAD: >>> >>> # cd /usr/obj/usr/src/sys/GENERIC/ >>> # kgdb kernel.debug /var/crash/vmcore.0 >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and you are >>> welcome to change it and/or distribute copies of it under certain >>> conditions. >>> Type "show copying" to see the conditions. >>> >>> There is absolutely no warranty for GDB. Type "show warranty" for >>> details. >>> This GDB was configured as "i386-marcel-freebsd"... >> [ snipped lots of stuff ] >> >>> Kernel page fault with the following non-sleepable locks held: >>> >>> exclusive sleep mutex drmdev (drmdev) r = 0 (0xc373f860) locked @ >>> /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:777 >>> >>> KDB: stack backtrace: >>> >>> calltrap() at calltrap+0x6 >>> >>> --- trap 0xc, eip = 0xc0b611b6, esp = 0xd67d4a98, ebp = 0xd67d4b48 --- >>> >>> slow_copyin(c373f800,c4103300,c42e64e0,d67d4b64,0,...) at >>> slow_copyin+0x6 >>> radeon_cp_texture(c373f800,c42e64e0,c4103300,309,c0c26218,...) at >>> radeon_cp_texture+0x199 >>> >>> drm_ioctl(c39d4e00,c018644e,c42e64e0,3,c40afaf0,...) at drm_ioctl+0x356 >>> >> The drm code is doing a copyin() while holding a mutex (which is not allowed). > > Ok, the quick and dirty fix for this is > http://people.freebsd.org/~rnoland/drm_radeon_state-copyin-fix.patch > > I think there may be other places of concern though and a more proper > fix is needed. I still get the same lockup :( From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 04:48: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 95F391065673 for ; Fri, 17 Apr 2009 04:48:23 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 22D6A8FC13 for ; Fri, 17 Apr 2009 04:48:22 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fxm11 with SMTP id 11so729121fxm.43 for ; Thu, 16 Apr 2009 21:48:22 -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=jNmkPxql8ihugZn/iP2/eaaMSqdouBX+LBHuto/R2+E=; b=tm/vXMogpY1p4/3+6Muble4y2DuxOF9eJxWFhApyB9Bw7ZPae5BvGSLrMA3cFU/hEO Q0zEFCDueW/FKaQylUKzl6fbv25FCnmSndPK9jydRVrDx5kjCa5VMQ6qYFLfDFBgeL1A ee77zWbdSNF67lcy28jmpPPDxXZ1M9ELYmNUM= 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=KHGE+vMoV1eirmfLfZzPO0+VD6ABlhGmHq7cJ6DJ2hgzYWsqfPMx2dXU0PFof8i4n+ pUrrT3Gxg54NGpPvca84/zuKSy6Zwfc5zyNirdZc08K2UcwgDMMG1p7e3FPHxnIs2FK+ 7wTI80un+mIhos1Y/+GFo4ieR2nNSclLYX6Kg= MIME-Version: 1.0 Received: by 10.103.222.1 with SMTP id z1mr1124290muq.51.1239943702052; Thu, 16 Apr 2009 21:48:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Apr 2009 08:48:22 +0400 Message-ID: From: pluknet To: Maksim Yevmenkin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: possible bug in the sbappendrecord_locked()? (Was: Re: core dump with bluetooth device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 04:48:24 -0000 Sorry for top-posting. This is a fairly old bug. See my investigation http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019345.html 2009/4/17 Maksim Yevmenkin : > On Thu, Apr 16, 2009 at 7:41 PM, Maksim Yevmenkin > wrote: >> On Thu, Apr 16, 2009 at 7:22 PM, Maksim Yevmenkin >> wrote: >>> On Thu, Apr 16, 2009 at 5:39 PM, Maksim Yevmenkin >>> wrote: >>>> On Thu, Apr 16, 2009 at 12:59 PM, Alexander Best >>>> wrote: >>>>> hi there, >>>>> >>>>> i'm running r191076M. when i try to send files from my mobile phone to my >>>>> computer via bt the core dumps. here's a backtrace: >>>>> >>>>> Unread portion of the kernel message buffer: >>>>> sblastmbufchk: sb_mb 0xc8d54d00 sb_mbtail 0 last 0xc8d54d00 >>>>> packet tree: >>>>> 0xc8d54d00 >>>>> panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:797 >>>>> cpuid = 0 >>>> >>>> are you, by change, have "options SOCKBUF_DEBUG" in your kernel? >>> >>> ok, there is something strange going on in the >>> sbappendrecord_locked(). consider the following initial conditions: >>> >>> 1) sockbuf sb is empty, i.e. sb_mb == sb_mbtail == sb_lastrecord == NULL >>> >>> 2) sbappendrecord_locked() is given mbuf m0 with has exactly one mbuf, >>> i.e. m0->m_next == NULL >>> >>> so >>> >>> void >>> sbappendrecord_locked(struct sockbuf *sb, struct mbuf *m0) >>> { >>> struct mbuf *m; >>> >>> SOCKBUF_LOCK_ASSERT(sb); >>> >>> if (m0 == 0) >>> return; >>> m = sb->sb_mb; >>> >>> if (m) >>> while (m->m_nextpkt) >>> m = m->m_nextpkt; >>> >>> --> m is still NULL at this point >>> >>> /* >>> * Put the first mbuf on the queue. Note this permits zero length >>> * records. >>> */ >>> sballoc(sb, m0); >>> SBLASTRECORDCHK(sb); >>> >>> --> passed successfully, because sb_mb == sb_lastrecord == NULL (i.e. >>> sockbuf is empty) >>> >>> SBLINKRECORD(sb, m0); >>> >>> --> at this point sb_mb == sb_lastrecord == m0, _but_ sb_mtail == NULL >>> >>> if (m) >>> m->m_nextpkt = m0; >>> else >>> sb->sb_mb = m0; >>> >>> --> not sure about those lines above, didn't SBLINKRECORD(sb, m0) take >>> care of it already? >>> --> in any case, still, sb_mb == sb_lastrecord == m0 _and_ still >>> sb_mtail == NULL >>> >>> m = m0->m_next; >>> m0->m_next = 0; >>> >>> --> m is still NULL here >>> >>> if (m && (m0->m_flags & M_EOR)) { >>> m0->m_flags &= ~M_EOR; >>> m->m_flags |= M_EOR; >>> } >>> >>> --> sbcompress() is called with m == NULL, which is triggers the panic >>> (read below) >>> >>> sbcompress(sb, m, m0); >>> } >>> >>> =========== >>> >>> void >>> sbcompress(struct sockbuf *sb, struct mbuf *m, struct mbuf *n) >>> { >>> int eor = 0; >>> struct mbuf *o; >>> >>> SOCKBUF_LOCK_ASSERT(sb); >>> >>> while (m) { >>> >>> --> lots of code that never gets executed because m == NULL >>> >>> } >>> if (eor) { >>> KASSERT(n != NULL, ("sbcompress: eor && n == NULL")); >>> n->m_flags |= eor; >>> } >>> >>> --> this where panic happens, because sb_mbtail is still NULL, but >>> sockbuf now contains exactly one record >>> >>> SBLASTMBUFCHK(sb); >>> } >>> >>> so, it looks like, sbcompress() should only be called when m != NULL. >>> also, when m == NULL, m0 should be marked as EOR. >> >> actually, no, EOR should be set (or not set already). >> >>> comments anyone? >> >> i think there is also something strange going on in >> sbappendaddr_locked(), basically, >> >> int >> sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa, >> struct mbuf *m0, struct mbuf *control) >> { >> struct mbuf *m, *n, *nlast; >> int space = asa->sa_len; >> >> SOCKBUF_LOCK_ASSERT(sb); >> >> if (m0 && (m0->m_flags & M_PKTHDR) == 0) >> panic("sbappendaddr_locked"); >> if (m0) >> space += m0->m_pkthdr.len; >> space += m_length(control, &n); >> >> if (space > sbspace(sb)) >> return (0); >> #if MSIZE <= 256 >> if (asa->sa_len > MLEN) >> return (0); >> #endif >> MGET(m, M_DONTWAIT, MT_SONAME); >> if (m == 0) >> return (0); >> m->m_len = asa->sa_len; >> bcopy(asa, mtod(m, caddr_t), asa->sa_len); >> >> --> at this point n is not initialized, or at least i do not see where >> it was initialized. shouldn't be compiler giving a warning here? >> >> if (n) >> n->m_next = m0; /* concatenate data to control */ >> else >> control = m0; >> >> am i missing something obvious here? > > ignore the last one :) i missed m_length(control, &n). ok, need to get > away from the screen :) > > thanks, > max > _______________________________________________ > 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" > -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 05:05:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F14751065672; Fri, 17 Apr 2009 05:05:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE308FC14; Fri, 17 Apr 2009 05:05:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H55tX6083665; Fri, 17 Apr 2009 01:05:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H55tZ3039710; Fri, 17 Apr 2009 01:05:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 439397302F; Fri, 17 Apr 2009 01:05:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090417050555.439397302F@freebsd-current.sentex.ca> Date: Fri, 17 Apr 2009 01:05:55 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:05:59 -0000 TB --- 2009-04-17 03:57:22 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-17 03:57:22 - starting HEAD tinderbox run for i386/i386 TB --- 2009-04-17 03:57:22 - cleaning the object tree TB --- 2009-04-17 03:57:52 - cvsupping the source tree TB --- 2009-04-17 03:57:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-04-17 03:58:04 - building world TB --- 2009-04-17 03:58:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-17 03:58:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-17 03:58:04 - TARGET=i386 TB --- 2009-04-17 03:58:04 - TARGET_ARCH=i386 TB --- 2009-04-17 03:58:04 - TZ=UTC TB --- 2009-04-17 03:58:04 - __MAKE_CONF=/dev/null TB --- 2009-04-17 03:58:04 - cd /src TB --- 2009-04-17 03:58:04 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 17 03:58:06 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 [...] /obj/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x11dd): In function `archive_write_mtree_data': : undefined reference to `SHA384_Update' /obj/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1637): In function `archive_write_mtree_header': : undefined reference to `SHA512_Init' /obj/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1667): In function `archive_write_mtree_header': : undefined reference to `SHA384_Init' /obj/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1724): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' *** Error code 1 Stop in /obj/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-17 05:05:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-17 05:05:55 - ERROR: failed to build world TB --- 2009-04-17 05:05:55 - 3232.54 user 326.52 system 4112.87 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 05:20:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0232A106564A; Fri, 17 Apr 2009 05:20:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id A473F8FC14; Fri, 17 Apr 2009 05:20:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H5KXJp035593; Fri, 17 Apr 2009 01:20:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H5KXm7090470; Fri, 17 Apr 2009 01:20:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6232C7302F; Fri, 17 Apr 2009 01:20:33 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090417052033.6232C7302F@freebsd-current.sentex.ca> Date: Fri, 17 Apr 2009 01:20:33 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:20:36 -0000 TB --- 2009-04-17 04:11:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-17 04:11:56 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-04-17 04:11:56 - cleaning the object tree TB --- 2009-04-17 04:12:25 - cvsupping the source tree TB --- 2009-04-17 04:12:25 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-04-17 04:12:33 - building world TB --- 2009-04-17 04:12:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-17 04:12:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-17 04:12:33 - TARGET=pc98 TB --- 2009-04-17 04:12:33 - TARGET_ARCH=i386 TB --- 2009-04-17 04:12:33 - TZ=UTC TB --- 2009-04-17 04:12:33 - __MAKE_CONF=/dev/null TB --- 2009-04-17 04:12:33 - cd /src TB --- 2009-04-17 04:12:33 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 17 04:12:35 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 [...] /obj/pc98/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x11dd): In function `archive_write_mtree_data': : undefined reference to `SHA384_Update' /obj/pc98/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1637): In function `archive_write_mtree_header': : undefined reference to `SHA512_Init' /obj/pc98/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1667): In function `archive_write_mtree_header': : undefined reference to `SHA384_Init' /obj/pc98/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1724): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' *** Error code 1 Stop in /obj/pc98/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-17 05:20:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-17 05:20:33 - ERROR: failed to build world TB --- 2009-04-17 05:20:33 - 3226.27 user 340.19 system 4117.21 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 05:39: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 0E454106567E for ; Fri, 17 Apr 2009 05:39:25 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id 91E598FC18 for ; Fri, 17 Apr 2009 05:39:24 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.40,202,1238968800"; d="scan'208";a="213194801" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 17 Apr 2009 07:39:22 +0200 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id AAAFB1B0765; Fri, 17 Apr 2009 07:39:22 +0200 (CEST) Date: Fri, 17 Apr 2009 07:39:22 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Maksim Yevmenkin Subject: Re: core dump with bluetooth device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:39:28 -0000 damn. you're right. i just browsed my kernel conf and realised that i have SOCKBUF_DEBUG in there. i should have really checked my kernel conf before asking. i was actually the one who submitted the problem report describing that SOCKBUF_DEBUG makes ng_ubt crash. :( (http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/126742) sorry. i'll remvove that line from my kernel conf. that should actually fix the problem. would be nice however if someone could take care of the proble= m. cheers. Maksim Yevmenkin schrieb am 2009-04-17: > On Thu, Apr 16, 2009 at 12:59 PM, Alexander Best > wrote: > > hi there, > > i'm running r191076M. when i try to send files from my mobile phone > > to my > > computer via bt the core dumps. here's a backtrace: > > Unread portion of the kernel message buffer: > > sblastmbufchk: sb_mb 0xc8d54d00 sb_mbtail 0 last 0xc8d54d00 > > packet tree: > > =A0 =A0 =A0 =A00xc8d54d00 > > panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:797 > > cpuid =3D 0 > are you, by change, have "options SOCKBUF_DEBUG" in your kernel? > thanks, > max From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 05:46: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 4DC5F1065701 for ; Fri, 17 Apr 2009 05:46:27 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id 28FDF8FC0A for ; Fri, 17 Apr 2009 05:46:26 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: by mx1.synetsystems.com (Postfix, from userid 66) id 9D5F8CE1; Fri, 17 Apr 2009 01:46:26 -0400 (EDT) Received: from rmtodd by servalan.servalan.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lufe3-000HDR-T7; Thu, 16 Apr 2009 23:25:43 -0500 To: John Baldwin References: <49BD117B.2080706@163.com> <20090416144251.GA1605@plebeian.afflictions.org> <200904161624.51920.jhb@freebsd.org> From: Richard Todd Date: Thu, 16 Apr 2009 23:25:43 -0500 In-Reply-To: (John Baldwin's message of "Thu, 16 Apr 2009 16:24:51 -0400") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.22 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 05:46:27 -0000 John Baldwin writes: > Can you please try http://www.FreeBSD.org/~jhb/patches/dma_pg.patch? This > lines up with your analysis in that it fixes a problem in the bounce buffer > code that was introduced with the new USB stack (and only triggers when the > USB code has to use a bounce buffer). I'll try to get this tested this weekend. (Although, in my experience, the bug is fairly intermittent, so it may take a while to show up if this bug doesn't fix it. On the other hand, I don't usually do large-scale data transfers to USB/umass devices like the other guy does, so that might be a good thing for me to try to test this. Hmmm.) Richard From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 06:22: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 823CB106566C; Fri, 17 Apr 2009 06:22:01 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.tele2.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id E1E498FC13; Fri, 17 Apr 2009 06:22:00 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=LvuvDqMzrUsA:10 a=jRiCUZqTDZ8A:10 a=j+k/Ze5hWUCaCztCgEjzDQ==:17 a=Ufx53kvaBBv-GnOLGPEA:9 a=LIekR4zw-QblQMPA7YSkbeVu7cIA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO laptop) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1057704174; Fri, 17 Apr 2009 08:21:59 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 17 Apr 2009 08:24:31 +0200 User-Agent: KMail/1.9.7 References: <49BD117B.2080706@163.com> <200904161804.42399.jhb@freebsd.org> <49E7AC43.8050901@samsco.org> In-Reply-To: <49E7AC43.8050901@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904170824.32184.hselasky@c2i.net> Cc: Richard Todd , Damian Gerow Subject: Re: ZFS checksum errors on umass(4) insertion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 06:22:01 -0000 On Friday 17 April 2009, Scott Long wrote: > > It could, and if that's happening, then some proactive measures should > be taken by the usb code to generate buffers that won't bounce. It > would suck to have to go through the bounce code for every single > keystroke or mouse movement. I haven't looked at the new usb code, > though, and I thought that the old code did a contigmalloc of some > sort to avoid this. USB uses an alignment of 1-byte for its data buffers. It should only bounce when the page the data buffer is residing on is above 4GB. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 06:31: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 6F570106564A; Fri, 17 Apr 2009 06:31:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1B8168FC12; Fri, 17 Apr 2009 06:31:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H6VC2A089830; Fri, 17 Apr 2009 02:31:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H6VC9S026074; Fri, 17 Apr 2009 02:31:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4AA9D7302F; Fri, 17 Apr 2009 02:31:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090417063112.4AA9D7302F@freebsd-current.sentex.ca> Date: Fri, 17 Apr 2009 02:31:12 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on 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: Fri, 17 Apr 2009 06:31:16 -0000 TB --- 2009-04-17 05:05:55 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-17 05:05:55 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-04-17 05:05:55 - cleaning the object tree TB --- 2009-04-17 05:06:28 - cvsupping the source tree TB --- 2009-04-17 05:06:28 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-04-17 05:06:38 - building world TB --- 2009-04-17 05:06:38 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-17 05:06:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-17 05:06:38 - TARGET=ia64 TB --- 2009-04-17 05:06:38 - TARGET_ARCH=ia64 TB --- 2009-04-17 05:06:38 - TZ=UTC TB --- 2009-04-17 05:06:38 - __MAKE_CONF=/dev/null TB --- 2009-04-17 05:06:38 - cd /src TB --- 2009-04-17 05:06:38 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 17 05:06:41 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 [...] /obj/ia64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x22b2): In function `archive_write_mtree_data': : undefined reference to `SHA384_Update' /obj/ia64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x28a2): In function `archive_write_mtree_header': : undefined reference to `SHA512_Init' /obj/ia64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x2942): In function `archive_write_mtree_header': : undefined reference to `SHA384_Init' /obj/ia64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x2bc2): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' *** Error code 1 Stop in /obj/ia64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-17 06:31:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-17 06:31:12 - ERROR: failed to build world TB --- 2009-04-17 06:31:12 - 4165.10 user 341.71 system 5116.71 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 06:36: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 2351C1065673 for ; Fri, 17 Apr 2009 06:36:46 +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 EB4AA8FC19 for ; Fri, 17 Apr 2009 06:36:45 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 05D3F7E818 for ; Thu, 16 Apr 2009 22:36:43 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Fri, 17 Apr 2009 08:36:33 +0200 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.2; i386; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904170836.36239.mel.flynn+fbsd.current@mailing.thruhere.net> Subject: Proper procedure to update hal on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 06:36:46 -0000 Hi, Given: http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004871.html and the fact that I've got devel/libusb deps forced on me (x11/kdebase4- workspace for example), what would be the proper procedure to upgrade HAL. Right now I'm using a +IGNOREME with portmaster, but I'm sure this will break stuff in the not so far future. Do I need to temporarily uninstall devel/libusb (it doesn't build now anyway, but maybe upgrading to today's current will fix that) then reinstall it? Any chance some BROKEN vars can be set based on FreeBSD_Version? -- Mel From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 06:43: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 F0DBE1065672 for ; Fri, 17 Apr 2009 06:43:31 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id C114C8FC0A for ; Fri, 17 Apr 2009 06:43:31 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from feathers.peganest.com (feathers.peganest.com [78.33.110.3]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n3H6hTuR021014 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Apr 2009 06:43:30 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: freebsd-current@freebsd.org Date: Fri, 17 Apr 2009 06:43:28 +0000 User-Agent: KMail/1.11.2 (FreeBSD/8.0-CURRENT; KDE/4.2.2; amd64; ; ) References: <7DEF7288-1304-4A64-8A23-BB03349653EA@wanderview.com> In-Reply-To: <7DEF7288-1304-4A64-8A23-BB03349653EA@wanderview.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904170643.28862.ken@mthelicon.com> Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 06:43:32 -0000 On Friday 17 April 2009 01:30:21 Ben Kelly wrote: > On Apr 15, 2009, at 12:35 AM, Artem Belevich wrote: > > I'll give it a try in a few days. I'll let you know how it went. > > Just FYI, I was able to reproduce some of the failures with the > original patch using an SMP vmware image. The new patch seems to fix > these problems and I was able to successfully mount a zfs pool. > > > BTW, now that you're tinkering with ZFS threads and priorities, whould > > you by any chance have any idea why zfs scrub is so painfully slow on > > -current? > > When I start scrub on my -stable box, it pretty much runs full speed > > -- I can see disks under load all the time. > > However on -current scrub seems to run in small bursts. Disks get busy > > for a second or so and then things get quiet for about five seconds or > > so and this pattern repeats over and over. > > I don't know. I haven't had to scrub my devices very often. I ran a > couple here locally and did not see the behavior you describe. There > is a significant delay between typing zpool scrub and when it actually > begins disk I/O, but after that it completes without pause. If I get > a chance I'll try to look at what the scrub code is doing. Hi Ben, I saw the same pausing of of a scrub on my machine as Artem is. It may be coincidence, but I had disabled the zil and prefetch. After I re-enabled the zil and prefetch, the pausing stopped and the scrub would complete without any stalling. I never disabled the zil and prefetch to see if this was the true cause or not.. Peg From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 07:29: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 85FFC106566B for ; Fri, 17 Apr 2009 07:29:22 +0000 (UTC) (envelope-from igor4ml@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 189948FC18 for ; Fri, 17 Apr 2009 07:29:21 +0000 (UTC) (envelope-from igor4ml@gmail.com) Received: by fg-out-1718.google.com with SMTP id 19so35570fgg.12 for ; Fri, 17 Apr 2009 00:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=rjohySJ4m6cIHK+J8hBxioBKe02l6D/yAcn9Vu7Sdlo=; b=KkPesQS+C6o0DeEkD0nroUbbVJc4F1tnpADjX4dVGBGomLdfEw4dEsjckZWYG0bOEY +cK0MdUvDsY009yyC83AsMw5+i72bToTO5xzA9opr/JmkWtYnDkuLEL1ywUIvRII7e7E qf6pNbcFf4rJ57WvFV6ZK/Ec8WXrZel14nMMQ= 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=rDFGqU74+i0s14FMliisChwDpkpViulOu5yXDs3QgdzWzXRMGfbrmIPGDwllbdO32a 35+viGKC1A8E+3qnZBsRC6g65kGojgNycEc/YwlTppnLVxR0qevXK1He+epiqe00TAy5 lBDY1gd70NL6zBF2gRmqfJCaAEYxF/J++5+BI= MIME-Version: 1.0 Received: by 10.86.86.10 with SMTP id j10mr1793472fgb.37.1239952079271; Fri, 17 Apr 2009 00:07:59 -0700 (PDT) In-Reply-To: <49E7BE78.6000802@freebsd.org> References: <49E7BE78.6000802@freebsd.org> Date: Fri, 17 Apr 2009 11:07:59 +0400 Message-ID: From: Igor R To: "current@FreeBSD.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Weird warnings from lots of applications X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 07:29:22 -0000 > =A0 =A0 =A0 "unexpected character `{', expected keyword - e.g. `style' Looks like GTK? > Has anyone else managed to narrow this down? From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 07:43: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 8FE9C106566C; Fri, 17 Apr 2009 07:43:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3B6FB8FC15; Fri, 17 Apr 2009 07:43:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H7hk4Q096022; Fri, 17 Apr 2009 03:43:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H7hkOG077035; Fri, 17 Apr 2009 03:43:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C2C187302F; Fri, 17 Apr 2009 03:43:46 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090417074346.C2C187302F@freebsd-current.sentex.ca> Date: Fri, 17 Apr 2009 03:43:46 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 07:43:50 -0000 TB --- 2009-04-17 06:27:03 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-17 06:27:03 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-04-17 06:27:03 - cleaning the object tree TB --- 2009-04-17 06:27:26 - cvsupping the source tree TB --- 2009-04-17 06:27:26 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-04-17 06:27:36 - building world TB --- 2009-04-17 06:27:36 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-17 06:27:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-17 06:27:36 - TARGET=powerpc TB --- 2009-04-17 06:27:36 - TARGET_ARCH=powerpc TB --- 2009-04-17 06:27:36 - TZ=UTC TB --- 2009-04-17 06:27:36 - __MAKE_CONF=/dev/null TB --- 2009-04-17 06:27:36 - cd /src TB --- 2009-04-17 06:27:36 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 17 06:27:38 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 [...] /obj/powerpc/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xfa8): In function `archive_write_mtree_data': : undefined reference to `SHA384_Update' /obj/powerpc/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x14a0): In function `archive_write_mtree_header': : undefined reference to `SHA512_Init' /obj/powerpc/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x15f0): In function `archive_write_mtree_header': : undefined reference to `SHA384_Init' /obj/powerpc/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1628): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' *** Error code 1 Stop in /obj/powerpc/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-17 07:43:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-17 07:43:46 - ERROR: failed to build world TB --- 2009-04-17 07:43:46 - 3363.90 user 334.83 system 4603.62 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 07:45:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5461C1065674; Fri, 17 Apr 2009 07:45:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0019D8FC1B; Fri, 17 Apr 2009 07:45:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H7j7Bv096110; Fri, 17 Apr 2009 03:45:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3H7j702068561; Fri, 17 Apr 2009 03:45:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B77DB7302F; Fri, 17 Apr 2009 03:45:07 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090417074507.B77DB7302F@freebsd-current.sentex.ca> Date: Fri, 17 Apr 2009 03:45:07 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on 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: Fri, 17 Apr 2009 07:45:14 -0000 TB --- 2009-04-17 06:31:12 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-17 06:31:12 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-04-17 06:31:12 - cleaning the object tree TB --- 2009-04-17 06:31:55 - cvsupping the source tree TB --- 2009-04-17 06:31:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-04-17 06:32:03 - building world TB --- 2009-04-17 06:32:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-17 06:32:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-17 06:32:03 - TARGET=sparc64 TB --- 2009-04-17 06:32:03 - TARGET_ARCH=sparc64 TB --- 2009-04-17 06:32:03 - TZ=UTC TB --- 2009-04-17 06:32:03 - __MAKE_CONF=/dev/null TB --- 2009-04-17 06:32:03 - cd /src TB --- 2009-04-17 06:32:03 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 17 06:32:04 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 [...] /obj/sparc64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x10dc): In function `archive_write_mtree_data': : undefined reference to `SHA384_Update' /obj/sparc64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x15dc): In function `archive_write_mtree_header': : undefined reference to `SHA512_Init' /obj/sparc64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1874): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' /obj/sparc64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x18bc): In function `archive_write_mtree_header': : undefined reference to `SHA384_Init' *** Error code 1 Stop in /obj/sparc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-17 07:45:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-17 07:45:07 - ERROR: failed to build world TB --- 2009-04-17 07:45:07 - 3136.53 user 330.22 system 4435.23 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 08:35:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 072641065672 for ; Fri, 17 Apr 2009 08:35:42 +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 C9BF28FC14 for ; Fri, 17 Apr 2009 08:35:41 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id A8CC07E821; Fri, 17 Apr 2009 00:35:40 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Fri, 17 Apr 2009 10:35:39 +0200 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.2; i386; ; ) References: <200904170836.36239.mel.flynn+fbsd.current@mailing.thruhere.net> <542798610904170031w44e51957gd342eadf747a4e97@mail.gmail.com> In-Reply-To: <542798610904170031w44e51957gd342eadf747a4e97@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904171035.39259.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Johannes Dieterich Subject: Re: Proper procedure to update hal on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:35:42 -0000 Hi Johannes, On Friday 17 April 2009 09:31:46 Johannes Dieterich wrote: > > Do I need to temporarily uninstall devel/libusb (it doesn't build now > > anyway, > > but maybe upgrading to today's current will fix that) then reinstall it? > > My procedure was to deinstall devel/libusb, then I also encountered the > same kind of mising dependencies as you do but for me a pkgdb -F afterwards > would fix them. Then hal would also build for me. :-) Ah, this relies on ldconfig -r finding /usr/lib/libusb and thus not installing devel/libusb. Gotcha. > See the procedure in ports/UPDATING, entry 20090309. (somebody needs to look at pkg_updating -d option as it showed me phonon entry + 20090319 entry) -- Mel From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 08:44: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 7E88B106566B; Fri, 17 Apr 2009 08:44:49 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from mail.pica.nl (mail.pica.nl [192.87.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 1B8F48FC18; Fri, 17 Apr 2009 08:44:48 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from rebelion.Sisis.de ([10.0.1.29]) by mail.pica.nl with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 10:44:48 +0200 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n3H8ikgn004173; Fri, 17 Apr 2009 10:44:46 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Fri, 17 Apr 2009 10:44:46 +0200 From: Matthias Apitz To: freebsd-mobile@freebsd.org, freebsd-current@freebsd.org Message-ID: <20090417084446.GA3929@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) X-OriginalArrivalTime: 17 Apr 2009 08:44:48.0166 (UTC) FILETIME=[C3D99460:01C9BF38] Cc: Subject: CURRENT+xorg-7.4 on eeePC 900 && X crashes on shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:44:49 -0000 Hello, I've installed today morning 8.0-CURRENT on my eeePC: # uname -a FreeBSD tiny 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Mar 23 23:47:06 CET 2009 guru@vm-naranja.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 and xorg-7.4 from the ports collection (compiled on some faster host): # cd /PKGDIR-CURRENT # pkg_add xorg-7.4.tbz # pkg_add kde-3.5.10_1.tbz # Xorg -configure added the line: Option "AllowEmptyInput" "false" to the Section "ServerLayout" in /root/xorg.conf.new and merged in as well the Monitor section (saved from the Xandros Linux): Section "Monitor" Identifier "Monitor0" VendorName "ASUS" ModelName "Eee PC P900" Modeline "1024x600" 48.96 1024 1064 1168 1312 600 601 604 622 -HSync +Vsync EndSection the X server starts fine and mouse is working; on stopping X with ctrl-alt-backspace (or kill) the server crashes and let the display in unusable state; a second/third/... start of X (from a SSH session) brings the display up again, but on any stop it crashes and does not switch back to alpha-mode; any idea about? I could provide the /var/log/Xorg.0.log if this would help; Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 09:32:03 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 825D71065679 for ; Fri, 17 Apr 2009 09:32:03 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by mx1.freebsd.org (Postfix) with ESMTP id E0BAE8FC13 for ; Fri, 17 Apr 2009 09:32:02 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id n3H9Km1k092282 for ; Fri, 17 Apr 2009 11:20:48 +0200 (CEST) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 17 Apr 2009 11:20:46 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB5DE72E@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: buildworld fails. Thread-Index: Acm/Pcoro7AKGaEdT6G9FDPR+JPTig== From: "Johan Hendriks" To: X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: buildworld fails. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 09:32:04 -0000 Hello all on my current system my buildworld fails. Here is the error message /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.= o)(.text+0x96c): In function `archive_write_mtree_finish_entry': : undefined reference to `SHA512_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.= o)(.text+0x9a7): In function `archive_write_mtree_finish_entry': : undefined reference to `SHA384_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.= o)(.text+0xabb): In function `archive_write_mtree_finish_entry': : undefined reference to `MD5_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.= o)(.text+0xe38): In function `archive_write_mtree_data': : undefined reference to `SHA512_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.= o)(.text+0xe52): In function `archive_write_mtree_data': : undefined reference to `MD5_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.= o)(.text+0xee6): In function `archive_write_mtree_data': : undefined reference to `SHA384_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.= o)(.text+0x1321): In function `archive_write_mtree_header': : undefined reference to `SHA512_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.= o)(.text+0x134e): In function `archive_write_mtree_header': : undefined reference to `SHA384_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.= o)(.text+0x1408): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' *** Error code 1 =20 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 =20 Stop in /usr/src/rescue. *** Error code 1 =20 Stop in /usr/src. *** Error code 1 =20 Stop in /usr/src. *** Error code 1 =20 Stop in /usr/src. =20 =20 Regards, Johan Hendriks =20 From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 09:49: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 5FCB5106566B for ; Fri, 17 Apr 2009 09:49:30 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1A3758FC12 for ; Fri, 17 Apr 2009 09:49:30 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (hyperion.scode.org [85.17.42.115]) by hyperion.scode.org (Postfix) with ESMTPS id 20FAB23C42F; Fri, 17 Apr 2009 11:49:29 +0200 (CEST) Date: Fri, 17 Apr 2009 11:49:28 +0200 From: Peter Schuller To: Ben Kelly Message-ID: <20090417094927.GA38912@hyperion.scode.org> References: <49C2CFF6.8070608@egr.msu.edu> <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> <20090416132302.GA86096@hyperion.scode.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org, Artem Belevich Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 09:49:30 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > I find it odd that they would pause for up to 5 seconds, though. I =20 > would expect the throttling to occur over a much smaller time span. =20 > Do you see similarly large pauses in disk I/O during a scrub? It was 1 second bursts, one per 5 second transaction commit period yes. My memory is too fuzzy on the details, but it was consistent with my interpretation of the source.=20 --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknoUKcACgkQDNor2+l1i33ydwCglLWPbp4ZEaU1rTWSaDBOk0Cj aMYAnjRynOzS9vnAZ0xTYLmV+saK697E =HL2O -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 10:30: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 707B01065670; Fri, 17 Apr 2009 10:30:10 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: from mail-bw0-f165.google.com (mail-bw0-f165.google.com [209.85.218.165]) by mx1.freebsd.org (Postfix) with ESMTP id 7400F8FC1E; Fri, 17 Apr 2009 10:30:09 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: by bwz9 with SMTP id 9so229152bwz.43 for ; Fri, 17 Apr 2009 03:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=d/53trs3SdHfNdMlbLCzxnxAKn6DetuZZMIXrGuRFLs=; b=k3R2zm4Pdz/npQXtWSshiNKAoEYFMtU24z4Jr8S1iM1O75j3SwAEN4PVA6bf2EOUcJ Gtja01VoTkYcjxgIkAnSgm5Xf6PQnZ3KDIQ5KNJHLRqDIMWfFnFTPjdC4ZOGsaTvig7/ ZqZPPhvkP/q46JG6pGbpSJRUiHnLolf0FMQWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ONSmjn/Czuhvpd4q7LLhE3bpxAy5dArdav8bf1BU9wNi+ABcEN843b6Q/Tdwj7ciwm +DimfGZ/+nOhrPhsYNbL/7TOPNKOZoUgn/UfTbOjUJDoq4Vm3UHIpa4+Ui1POMG5nPJJ 7P4kSDBVQnguxzlq0C54wDm+yCCLtz2CnIeeE= MIME-Version: 1.0 Received: by 10.223.126.203 with SMTP id d11mr681750fas.8.1239964208374; Fri, 17 Apr 2009 03:30:08 -0700 (PDT) Date: Fri, 17 Apr 2009 12:30:08 +0200 Message-ID: <83e5fb980904170330g7828a0f7nbea2548233dfd950@mail.gmail.com> From: Diego Depaoli To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: disklablel/gpart [Was: AMD 780G chipset major issues 3/3 (btx)] [SOLVED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 10:30:10 -0000 On Thu, Apr 16, 2009 at 10:58 PM, Diego Depaoli wrote= : >> Seriously, I must say you should back it up first if the data is >> important. =A0When I got my current laptop, I had to reinstall all OSes >> several times in different orders to make all OS loaders agree with >> an MBR. :-( > > Many thanks to all. > I wiped a slice on the 2nd drive, now I begin to backup data. > If you read about a brutally murdered husband, then something gone wrong. Solved! Dealing with disklabel, gpart, dump and restore I moved my intallation to a new slice then system boots with ahci enabled. To @andry. Some point of your gpart micro howto didn't worked as expected, but surely was my fault. Gpart is a great tool which I didn't know at all, I hope it become soon the standard way to manage disks in FreeBSD installation. Many thanks again. --=20 Diego Depaoli From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 10:36: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 3727D1065677 for ; Fri, 17 Apr 2009 10:36:40 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay2-v.mail.gandi.net (relay2-v.mail.gandi.net [217.70.178.76]) by mx1.freebsd.org (Postfix) with ESMTP id BCEA28FC16 for ; Fri, 17 Apr 2009 10:36:39 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from plebeian.afflictions.org (CPE0021296fd1ec-CM0019475d4056.cpe.net.cable.rogers.com [99.241.164.229]) by relay2-v.mail.gandi.net (Postfix) with ESMTP id 4E356135EB for ; Fri, 17 Apr 2009 12:36:38 +0200 (CEST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id 17BF631F0; Fri, 17 Apr 2009 06:36:35 -0400 (EDT) Date: Fri, 17 Apr 2009 06:36:34 -0400 From: Damian Gerow To: freebsd-current@freebsd.org Message-ID: <20090417103634.GD1186@plebeian.afflictions.org> References: <200904161336.18557.jhb@freebsd.org> <20090416184738.GA60409@wep4035.physik.uni-wuerzburg.de> <200904161558.56919.jhb@freebsd.org> <49E79F49.6000606@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E79F49.6000606@samsco.org> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: [PATCH] Possible fix to recent data corruption on HEAD since 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: Fri, 17 Apr 2009 10:36:40 -0000 Scott Long wrote: : John Baldwin wrote: : > On Thursday 16 April 2009 2:47:38 pm Alexey Shuvaev wrote: : >> On Thu, Apr 16, 2009 at 01:36:18PM -0400, John Baldwin wrote: : >>> Due to some good sleuthing by avg@, : >>> there is a patch that might fix the recent : >>> reports of data corruption on current. It would explain some of the recent : >>> reports where a file that was read would have missing gaps of bytes. The : >>> problem is with the BUS_DMA_KEEP_PG_OFFSET changes to bus_dma. When a bounce : >>> page was used by USB2, the changes to bus_dma would actually change the : >>> starting virtual and physical addresses of the bounce page. When the bounce : >>> page was no longer needed it was left in this bogus state. Later if another : >>> device used the same bounce page for DMA it would use the wrong offset and : >>> address. The issue there is if the second device was doing a full page of : >>> I/O. In that case the DMA from the device would actually spill over into the : >>> next page which could in theory be used by another DMA request. It could : >>> also break alignment assumptions (since the previous PG_OFFSET may not be : >>> aligned and the bus_dma code assumes bounce pages for the !PG_OFFSET case are : >>> page aligned). The quick fix is to always restore the bounce page to the : >>> normal state when a PG_OFFSET DMA request is finished. I'd actually prefer : >>> not ever touching the page's starting addresses, but those changes would be : >>> more invasive I believe. : >>> : >>> http://www.FreeBSD.org/~jhb/patches/dma_sg.patch : >>> : >> Am I right that hardware prerequisite in order to observe these problems : >> is amd64 + 4Gb or more of RAM? : > : > Well, i386 with PAE would do it as well. Basically, you need USB + one other : > device that use bounce pages and the other device ends up with corruption. : > : >> Is it possible to fabricate some (artificial) test case to stress this : >> particular situation (interleaved use of bounce pages by USB and some other : >> device (?HDD?))? : > : > I haven't constructed one though it might be possible to do so. : > : >> Asking because as I understand the data corruption is silent : >> and affected consumer (of bounce pages) should have some mechanism : >> of detecting this (e.g. zfs' CRCs). : >> In my case stess testing unpatched system till UFS filesystems are dead : >> is no fun... : > : > Understood. I know some other folks are going to test this and if there is : > early success that may make the risk easier to take. : > : : I have pretty high confidence that John and Andriy found the problem and : fixed it with this patch. It'll be good to get it tested, but I think : that the risk to tester will be pretty low. Having been running the patch for sixteen hours now, I can safely say that it fixes my issues. - Damian From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 08:00: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 817591065677 for ; Fri, 17 Apr 2009 08:00:12 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id C5B5F8FC1B for ; Fri, 17 Apr 2009 08:00:11 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: by fxm11 with SMTP id 11so775399fxm.43 for ; Fri, 17 Apr 2009 01:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=C7iOPgErszkX0WKBLGUP9qFnDXSeHvljnyyPkG1sGjY=; b=wTAYKQkP3QekJYdurIPHsF7kjQ+1slFQ5qB7VmIh3OxBo8KtkD7OSZYgiGb8QG989Q y2BlqUsC10Fra76Xn0kklCPYPNfpgwHuI39SlJOOL2HP9Ofv/QbTurzvWSGFTuk0W7GV ypnMhzR5uWZALOAqJnn55MOOLqD2+/FbMj2OU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bhcRqKFr0Mgvaum2GNOrfjxuc3vUHT+BYcJn5jJfv98SChERFk+IyuC9PWqMcuK2TF o6+XGYHItwzO6B+6MDN2TiCwdHi47kJmMTMpmo1159uzk6tGxz/PmNvoMIp0tCHV02P4 /fz1b2wekF/ezC5bezcKYGL+PEcqjphcMrN8Y= MIME-Version: 1.0 Received: by 10.204.102.15 with SMTP id e15mr1984476bko.196.1239953506792; Fri, 17 Apr 2009 00:31:46 -0700 (PDT) In-Reply-To: <200904170836.36239.mel.flynn+fbsd.current@mailing.thruhere.net> References: <200904170836.36239.mel.flynn+fbsd.current@mailing.thruhere.net> Date: Fri, 17 Apr 2009 09:31:46 +0200 Message-ID: <542798610904170031w44e51957gd342eadf747a4e97@mail.gmail.com> From: Johannes Dieterich To: Mel Flynn X-Mailman-Approved-At: Fri, 17 Apr 2009 11:47:53 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Proper procedure to update hal on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:00:13 -0000 Hi Mel, On Fri, Apr 17, 2009 at 8:36 AM, Mel Flynn < mel.flynn+fbsd.current@mailing.thruhere.net > wrote: > Hi, > > Given: > http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004871.html > > and the fact that I've got devel/libusb deps forced on me (x11/kdebase4- > workspace for example), what would be the proper procedure to upgrade HAL. > Right now I'm using a +IGNOREME with portmaster, but I'm sure this will > break > stuff in the not so far future. > > Do I need to temporarily uninstall devel/libusb (it doesn't build now > anyway, > but maybe upgrading to today's current will fix that) then reinstall it? My procedure was to deinstall devel/libusb, then I also encountered the same kind of mising dependencies as you do but for me a pkgdb -F afterwards would fix them. Then hal would also build for me. :-) See the procedure in ports/UPDATING, entry 20090309. Hope this helps, Johannes > > > Any chance some BROKEN vars can be set based on FreeBSD_Version? > -- > Mel > From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 11:23: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 115BD106564A for ; Fri, 17 Apr 2009 11:23:26 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from mail.pica.nl (mail.pica.nl [192.87.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id A46248FC14 for ; Fri, 17 Apr 2009 11:23:25 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from rebelion.Sisis.de ([10.0.1.29]) by mail.pica.nl with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 13:23:24 +0200 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n3HBNJYH008670 for freebsd-current@freebsd.org; Fri, 17 Apr 2009 13:23:19 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Fri, 17 Apr 2009 13:23:19 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20090417112318.GA8258@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) X-OriginalArrivalTime: 17 Apr 2009 11:23:24.0416 (UTC) FILETIME=[EBFA1800:01C9BF4E] Subject: CURRENT && USB network device, cdce X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 11:23:26 -0000 Hello, In my installed CURRENT my USB network device does not bring up the interface cdce0 anymore; the cdce is in kernel and all u*.ko modules are loaded but it only says on device attach: Apr 17 13:16:44 tiny kernel: ugen1.2: at usbus1 Apr 17 13:16:44 tiny root: Unknown USB device: vendor 0x1457 product 0x5122 bus uhub1 on my RELENG_7 laptop is says: Apr 17 13:20:14 rebelion root: Unknown USB device: vendor 0x1457 product 0x5122 bus uhub0 Apr 17 13:20:14 rebelion kernel: cdce0: on uhub0 Apr 17 13:20:14 rebelion kernel: cdce0: faking MAC address Apr 17 13:20:14 rebelion kernel: cdce0: Ethernet address: 2a:ed:f2:e3:00:00 Apr 17 13:20:14 rebelion kernel: cdce0: if_start running deferred for Giant I've checked /usr/src/UPDATING and Google, but can't see what I'm missing; thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 13:06:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66B3F1065674; Fri, 17 Apr 2009 13:06:11 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 18AD98FC08; Fri, 17 Apr 2009 13:06:11 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2CE6F.dip.t-dialin.net [217.226.206.111]) by redbull.bpaserver.net (Postfix) with ESMTP id 946162E1FE; Fri, 17 Apr 2009 14:50:33 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 37FE4C45FA; Fri, 17 Apr 2009 14:50:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1239972628; bh=QtyPvoJKtsu/Ftw9hNgW3aVEbmjdcncPb azcBUlFnXs=; h=Message-ID:Date:From:To:Cc:Subject:MIME-Version: Content-Type:Content-Transfer-Encoding; b=3gXL7MGtITMJxpMCu49Q7mIb o+PY0HIGf7Ev4BQo51P1OvLWeRAQDheDFbAb8sgdGOke/ewwKMyvBb8gg9ptaK1Z5tG 2+DQQgcDtH4LXI+yjtw2DyfNc+F4mCDhPbZNHB3zAzI3j4iyaD5mVDwdQStu2dcCrV5 Oc6XR3gH3URHK+hpMR5bvD1E3Y/mDGJVEGThcBxuffoqVEC5zzCDpbpI4oVydBf4sbV k8r4bZfSn7HPVvBdeSMsfD5PMwMSRgOByhHwppCkLLiN2pfO9womm5qXihe2H+05Vyc xK6fDdM9HS3FduB8TsYiYCyUf9cDt892pJuUu4RuL0VRAbw5bg== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n3HCoP1o013531; Fri, 17 Apr 2009 14:50:25 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 17 Apr 2009 14:50:24 +0200 Message-ID: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 17 Apr 2009 14:50:24 +0200 From: Alexander Leidinger To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 946162E1FE.1BFC8 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.9, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: fs@freebsd.org Subject: ZFS: unlimited arc cache growth? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 13:06:11 -0000 Hi, to fs@, please CC me, as I'm not subscribed. I monitored (by hand) a while the sysctls kstat.zfs.misc.arcstats.size =20 and kstat.zfs.misc.arcstats.hdr_size. Both grow way higher (at some =20 point I've seen more than 500M) than what I have configured in =20 vfs.zfs.arc_max (40M). After a while FS operations (e.g. pkgdb -F with about 900 packages... =20 my specific workload is the fixup of gnome packages after the removal =20 of the obsolete libusb port) get very slow (in my specific example I =20 let the pkgdb run several times over night and it still is not =20 finished). The big problem with this is, that at some point in time the machine =20 reboots (panic, page fault, page not present, during a fork1). I have =20 the impression (beware, I have a watchdog configured, as I don't know =20 if a triggered WD would cause the same panic, the following is just a =20 guess) that I run out of memory of some kind (I have 1G RAM, i386, max =20 kmem size 700M). I restarted pkgdb several times after a reboot, and =20 it continues to process the libusb removal, but hey, this is anoying. Does someone see something similar to what I describe (mainly the =20 growth of the arc cache way beyond what is configured)? Anyone with =20 some ideas what to try? Bye, Alexander. --=20 When you go out to buy, don't show your silver. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 13:13: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 002C61065670; Fri, 17 Apr 2009 13:13:08 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 385F48FC1E; Fri, 17 Apr 2009 13:13:07 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so876680ewy.43 for ; Fri, 17 Apr 2009 06:13:07 -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=ac71/RS8d/BqU9G8IposlobQXsdIrQ53QDTyihd9KTU=; b=NEexKEo4kexlkLMOAZ+DTJRY9jT4ScJOd40dFdsrnJ61NMw1LncWj4UXvsvD1oo4cm pXPOIzP+J9FzokOywcOifWSolQalivilFZpT7bAltMt1auDodKNV7ouDBJOVNAG7HhKm 5lKdbcS9StsgMLnXfCXykiX8YunOJKv0+5Mzs= 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=Ie1dzFoSnotbQs4zouSkzUs4O5yNPGqVlER7U2wVDL9twyN3edlOKx72DmvKaKKXaS tI10yvaT22HtQRNwRGMrMYSpk8qtQ8wtgnzurXQ7VdTlgMObCF4+94ZvXGo7ecKG62fL w6Xr6iGU5PKGwSWeU3O4IzIxiG2CyUxItbAN4= MIME-Version: 1.0 Received: by 10.210.35.5 with SMTP id i5mr2712191ebi.52.1239973987047; Fri, 17 Apr 2009 06:13:07 -0700 (PDT) In-Reply-To: <20090417084446.GA3929@rebelion.Sisis.de> References: <20090417084446.GA3929@rebelion.Sisis.de> Date: Fri, 17 Apr 2009 15:13:06 +0200 Message-ID: <3a142e750904170613s63f6445el7adab4f74ab3dbf5@mail.gmail.com> From: "Paul B. Mahol" To: Matthias Apitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: CURRENT+xorg-7.4 on eeePC 900 && X crashes on shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 13:13:10 -0000 On 4/17/09, Matthias Apitz wrote: > > > Hello, > > I've installed today morning 8.0-CURRENT on my eeePC: > > # uname -a > FreeBSD tiny 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Mar 23 23:47:06 CET > 2009 guru@vm-naranja.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 > > and xorg-7.4 from the ports collection (compiled on some faster host): > > # cd /PKGDIR-CURRENT > # pkg_add xorg-7.4.tbz > # pkg_add kde-3.5.10_1.tbz > > # Xorg -configure > > added the line: > > Option "AllowEmptyInput" "false" > > to the Section "ServerLayout" in /root/xorg.conf.new and merged in as well > the Monitor section (saved from the Xandros Linux): > > Section "Monitor" > Identifier "Monitor0" > VendorName "ASUS" > ModelName "Eee PC P900" > Modeline "1024x600" 48.96 1024 1064 1168 1312 600 601 604 > 622 -HSync +Vsync > EndSection > > > the X server starts fine and mouse is working; on stopping X with > ctrl-alt-backspace (or kill) the server crashes and let the display in > unusable state; a second/third/... start of X (from a SSH session) > brings the display up again, but on any stop it crashes and does not > switch back to alpha-mode; > > any idea about? I could provide the /var/log/Xorg.0.log if this would > help; Usefull info is missing, what xserver version, which video driver and what version of it are you using. I had same behaviour with intel but issue got fixed for me with latest Mesa and Xorg from ports. -- Paul From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 13:36: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 B67AE106567B for ; Fri, 17 Apr 2009 13:36:44 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3C15E8FC1D for ; Fri, 17 Apr 2009 13:36:43 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LuoFE-0004qT-Fp for freebsd-current@freebsd.org; Fri, 17 Apr 2009 13:36:40 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Apr 2009 13:36:40 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Apr 2009 13:36:40 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Fri, 17 Apr 2009 15:36:25 +0200 Lines: 58 Message-ID: References: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF636F2BEAD87C797405E3AD2" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) In-Reply-To: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: ZFS: unlimited arc cache growth? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 13:36:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF636F2BEAD87C797405E3AD2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alexander Leidinger wrote: > Hi, >=20 > to fs@, please CC me, as I'm not subscribed. >=20 > I monitored (by hand) a while the sysctls kstat.zfs.misc.arcstats.size > and kstat.zfs.misc.arcstats.hdr_size. Both grow way higher (at some > point I've seen more than 500M) than what I have configured in > vfs.zfs.arc_max (40M). >=20 > After a while FS operations (e.g. pkgdb -F with about 900 packages... m= y > specific workload is the fixup of gnome packages after the removal of > the obsolete libusb port) get very slow (in my specific example I let > the pkgdb run several times over night and it still is not finished). >=20 > The big problem with this is, that at some point in time the machine > reboots (panic, page fault, page not present, during a fork1). I have > the impression (beware, I have a watchdog configured, as I don't know i= f > a triggered WD would cause the same panic, the following is just a > guess) that I run out of memory of some kind (I have 1G RAM, i386, max > kmem size 700M). I restarted pkgdb several times after a reboot, and i= t > continues to process the libusb removal, but hey, this is anoying. >=20 > Does someone see something similar to what I describe (mainly the growt= h > of the arc cache way beyond what is configured)? Anyone with some ideas= > what to try? What you've come across is probably *the* single most important problem with ZFS - unfortunately not yet resolved. If ARC could be constrained or removed, other issues would probably be forgivable :) --------------enigF636F2BEAD87C797405E3AD2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ6IXfldnAQVacBcgRAiCHAJ0S00oDz8k8dV6sr08gWZ42bL6VYACfX0sP 4V08WCXPUTwI4CCYSVimH2c= =WAkT -----END PGP SIGNATURE----- --------------enigF636F2BEAD87C797405E3AD2-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 13:48: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 E371C106566C for ; Fri, 17 Apr 2009 13:48:35 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.tele2.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 79D9D8FC21 for ; Fri, 17 Apr 2009 13:48:35 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=jPOeBrYq1qMA:10 a=TfRnIpFLtOQQcsU8CFYA:9 a=UYagl9-2RhFYgrUPN4121EjE-qoA:4 a=X6edkTLVFFrP1-mB:21 a=WasjmaJkWCJDRd-F:21 Received: from [81.191.55.181] (account mc467741@c2i.net HELO [10.36.2.183]) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 483072166; Fri, 17 Apr 2009 15:48:33 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, Matthias Apitz Date: Fri, 17 Apr 2009 15:51:05 +0200 User-Agent: KMail/1.9.7 References: <20090417112318.GA8258@rebelion.Sisis.de> In-Reply-To: <20090417112318.GA8258@rebelion.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904171551.06614.hselasky@c2i.net> Cc: Subject: Re: CURRENT && USB network device, cdce X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 13:48:36 -0000 On Friday 17 April 2009, Matthias Apitz wrote: > Hello, > > In my installed CURRENT my USB network device does not bring up the > interface cdce0 anymore; the cdce is in kernel and all u*.ko modules are > loaded but it only says on device attach: > > Apr 17 13:16:44 tiny kernel: ugen1.2: at usbus1 > Apr 17 13:16:44 tiny root: Unknown USB device: vendor 0x1457 product 0x5122 > bus uhub1 > > on my RELENG_7 laptop is says: > > Apr 17 13:20:14 rebelion root: Unknown USB device: vendor 0x1457 product > 0x5122 bus uhub0 Apr 17 13:20:14 rebelion kernel: cdce0: 2.6.24/s3c2410_udc RNDIS/Ethernet Gadget, class 2/0, rev 2.00/2.12, addr 2> > on uhub0 Apr 17 13:20:14 rebelion kernel: cdce0: faking MAC address > Apr 17 13:20:14 rebelion kernel: cdce0: Ethernet address: 2a:ed:f2:e3:00:00 > Apr 17 13:20:14 rebelion kernel: cdce0: if_start running deferred for Giant > > I've checked /usr/src/UPDATING and Google, but can't see what I'm > missing; thx > > matthias Ethernet devices have been renamed! I think it was "ueX" See "ifconfig" output. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 13: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 1FB23106567A for ; Fri, 17 Apr 2009 13:50:22 +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 AA2098FC32 for ; Fri, 17 Apr 2009 13:50:15 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=jPOeBrYq1qMA:10 a=_Uh9GKgQ2PHkIrQf38kA:9 a=q597cPXhv6zUdNvDGikTXgUpbOsA:4 Received: from [81.191.55.181] (account mc467741@c2i.net HELO [10.36.2.183]) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1230312065; Fri, 17 Apr 2009 15:50:14 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, Matthias Apitz Date: Fri, 17 Apr 2009 15:52:47 +0200 User-Agent: KMail/1.9.7 References: <20090417112318.GA8258@rebelion.Sisis.de> In-Reply-To: <20090417112318.GA8258@rebelion.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904171552.47772.hselasky@c2i.net> Cc: Subject: Re: CURRENT && USB network device, cdce X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 13:50:22 -0000 On Friday 17 April 2009, Matthias Apitz wrote: > Hello, > > In my installed CURRENT my USB network device does not bring up the > interface cdce0 anymore; the cdce is in kernel and all u*.ko modules are > loaded but it only says on device attach: > > Apr 17 13:16:44 tiny kernel: ugen1.2: at usbus1 > Apr 17 13:16:44 tiny root: Unknown USB device: vendor 0x1457 product 0x5122 > bus uhub1 > You have to run: usbconfig -u 1 -a 2 set_config 1 Because the FreeBSD kernel does not have a device driver for RNDIS! Numbers after "-u" and "-a" must match the ones on dmesg for your device. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 13:51: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 317921065672 for ; Fri, 17 Apr 2009 13:51:43 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id E3A838FC0C for ; Fri, 17 Apr 2009 13:51:42 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 3FD4E245401; Fri, 17 Apr 2009 14:51:46 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Fri, 17 Apr 2009 14:51:46 +0000 (GMT) Date: Fri, 17 Apr 2009 14:51:37 +0100 From: Bruce Cran To: Matthias Apitz Message-ID: <20090417145137.0ea386d9@gluon.draftnet> In-Reply-To: <20090417112318.GA8258@rebelion.Sisis.de> References: <20090417112318.GA8258@rebelion.Sisis.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CURRENT && USB network device, cdce X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 13:51:43 -0000 On Fri, 17 Apr 2009 13:23:19 +0200 Matthias Apitz wrote: > > Hello, > > In my installed CURRENT my USB network device does not bring up the > interface cdce0 anymore; the cdce is in kernel and all u*.ko modules > are loaded but it only says on device attach: > > Apr 17 13:16:44 tiny kernel: ugen1.2: at > usbus1 Apr 17 13:16:44 tiny root: Unknown USB device: vendor 0x1457 > product 0x5122 bus uhub1 > > on my RELENG_7 laptop is says: > > Apr 17 13:20:14 rebelion root: Unknown USB device: vendor 0x1457 > product 0x5122 bus uhub0 Apr 17 13:20:14 rebelion kernel: cdce0: > 2.00/2.12, addr 2> on uhub0 Apr 17 13:20:14 rebelion kernel: cdce0: > faking MAC address Apr 17 13:20:14 rebelion kernel: cdce0: Ethernet > address: 2a:ed:f2:e3:00:00 Apr 17 13:20:14 rebelion kernel: cdce0: > if_start running deferred for Giant > > I've checked /usr/src/UPDATING and Google, but can't see what I'm > missing; thx The GTA02 (I'm presuming that's what it is) has an RNDIS interface at configuration 0 and CDCE is at configuration 1 so you'll need to run: usbconfig -u 1 -a 2 set_config 1 The parameters to -a and -u will vary depending on which ugen device it gets detected as. Mine's often ugen3.2 but changes depending on which other USB devices I've plugged in. You should then see the kernel messages relating to cdce and be able to assign an IP address to ue0 (what was cdce0 in 7.x is now ue0). -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 14:20:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CD9D1065674; Fri, 17 Apr 2009 14:20:14 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id A6CCB8FC1C; Fri, 17 Apr 2009 14:20:13 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n3HE4FBX003074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Apr 2009 14:04:15 GMT (envelope-from ben@wanderview.com) From: Ben Kelly To: Alexander Leidinger In-Reply-To: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> X-Priority: 3 (Normal) References: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 10:04:15 -0400 X-Mailer: Apple Mail (2.930.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: current@freebsd.org, fs@freebsd.org Subject: Re: ZFS: unlimited arc cache growth? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 14:20:15 -0000 On Apr 17, 2009, at 8:50 AM, Alexander Leidinger wrote: > to fs@, please CC me, as I'm not subscribed. > > I monitored (by hand) a while the sysctls > kstat.zfs.misc.arcstats.size and kstat.zfs.misc.arcstats.hdr_size. > Both grow way higher (at some point I've seen more than 500M) than > what I have configured in vfs.zfs.arc_max (40M). > > After a while FS operations (e.g. pkgdb -F with about 900 > packages... my specific workload is the fixup of gnome packages > after the removal of the obsolete libusb port) get very slow (in my > specific example I let the pkgdb run several times over night and it > still is not finished). > > The big problem with this is, that at some point in time the machine > reboots (panic, page fault, page not present, during a fork1). I > have the impression (beware, I have a watchdog configured, as I > don't know if a triggered WD would cause the same panic, the > following is just a guess) that I run out of memory of some kind (I > have 1G RAM, i386, max kmem size 700M). I restarted pkgdb several > times after a reboot, and it continues to process the libusb > removal, but hey, this is anoying. > > Does someone see something similar to what I describe (mainly the > growth of the arc cache way beyond what is configured)? Anyone with > some ideas what to try? Can you provide the rest of the arcstats from sysctl? Also, does your arc_reclaim_thread process get any cycles when this problem occurs? What happens if you kill the pkgdb -F manually before it completes? Does the arc cache size come back down or is it stuck at the abnormally high level? At first glance it looks like the tunable limits the value of the arc_c target value, but that appears to only be a soft limit. There is code in there to shrink an ARC that has exceeded its arc_c value. It looks like that code is supposed to run from the arc_reclaim_thread. - Ben From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 14:36:02 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F089106577B; Fri, 17 Apr 2009 14:36:02 +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 120CD8FC13; Fri, 17 Apr 2009 14:36:01 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n3HEIKtw047958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Apr 2009 16:18:20 +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 n3HEIHqp018223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Apr 2009 16:18:17 +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 n3HEIH5U015759; Fri, 17 Apr 2009 16:18:17 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n3HEIHiI015758; Fri, 17 Apr 2009 16:18:17 +0200 (CEST) (envelope-from ticso) Date: Fri, 17 Apr 2009 16:18:17 +0200 From: Bernd Walter To: Alexander Leidinger Message-ID: <20090417141817.GR11551@cicely7.cicely.de> References: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> 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.000, 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: current@freebsd.org, fs@freebsd.org Subject: Re: ZFS: unlimited arc cache growth? 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: Fri, 17 Apr 2009 14:36:05 -0000 On Fri, Apr 17, 2009 at 02:50:24PM +0200, Alexander Leidinger wrote: > Hi, > > to fs@, please CC me, as I'm not subscribed. > > I monitored (by hand) a while the sysctls kstat.zfs.misc.arcstats.size > and kstat.zfs.misc.arcstats.hdr_size. Both grow way higher (at some > point I've seen more than 500M) than what I have configured in > vfs.zfs.arc_max (40M). My understanding about this is the following: vfs.zfs.arc_min/max are not used as min max values. They are used as high/low watermarks. If arc is more than max the arc a thread is triggered to reduce the arc cache until min, but in the meantime other threads can still grow arc so there is a race between them. > After a while FS operations (e.g. pkgdb -F with about 900 packages... > my specific workload is the fixup of gnome packages after the removal > of the obsolete libusb port) get very slow (in my specific example I > let the pkgdb run several times over night and it still is not > finished). I've seen many workloads were prefetching can saturate disks without ever being used. You might want to try disabling prefetch. Of course prefetching also grows arc. > The big problem with this is, that at some point in time the machine > reboots (panic, page fault, page not present, during a fork1). I have > the impression (beware, I have a watchdog configured, as I don't know > if a triggered WD would cause the same panic, the following is just a > guess) that I run out of memory of some kind (I have 1G RAM, i386, max > kmem size 700M). I restarted pkgdb several times after a reboot, and > it continues to process the libusb removal, but hey, this is anoying. With just 700M kmem you should set arc values extremly small and avoid anything which can quickly grow it. Unfortunately accessing many small files is a know arc filling workload. Activating vfs.zfs.cache_flush_disable can help speeding up arc decreasing, with the obvous risks of course... > Does someone see something similar to what I describe (mainly the > growth of the arc cache way beyond what is configured)? Anyone with > some ideas what to try? In my opinion the watermark mechanism can work as it is, but there should be a forced max - currently there is no garantied limit at all. Nevertheless it is up for the people which know the code to decide. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 14:47: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 2D5F81065722 for ; Fri, 17 Apr 2009 14:47: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 B79F58FC1B for ; Fri, 17 Apr 2009 14:47:11 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [77.73.25.202] (port=57361 helo=[192.168.130.164]) by hosting.lissyara.su with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LupLS-000Ggn-1G for freebsd-current@freebsd.org; Fri, 17 Apr 2009 18:47:10 +0400 Message-ID: <49E895CB.2040407@lissyara.su> Date: Fri, 17 Apr 2009 18:44:27 +0400 From: Alex Keda User-Agent: Thunderbird 2.0.0.19 (X11/20090205) MIME-Version: 1.0 To: freebsd-current@freebsd.org 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: new usb stack - boot problem from usb hdd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 14:47:14 -0000 After boot, before mount, disk da0 lost, or some partition lost/uninitialised mobile-hdd$ uname -a FreeBSD mobile-hdd 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Apr 13 22:55:22 MSD 2009 lissyara@HP.lissyara.su:/usr/obj/i386/usr/src/sys/GENERIC i386 dmesg part: pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcc7ff,0xcc800-0xcd7ff 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 Timecounter "TSC" frequency 2261008423 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 WARNING: WITNESS option enabled, expect reduced performance. ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered Root mount waiting for: usbus4 usb2_set_config_index:490: could not read device status: USB_ERR_SHORT_XFER ugen4.2: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus4 umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) Trying to mount root from ufs:/dev/da0s1a Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ? List of GEOM managed disk devices: fd0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:fd0 Trying to mount root from ufs:fd0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ? List of GEOM managed disk devices: da0 fd0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:fd0 Trying to mount root from ufs:fd0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ? List of GEOM managed disk devices: da0 fd0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:da0s1a Trying to mount root from ufs:da0s1a Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ? List of GEOM managed disk devices: da0 fd0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:da0 Trying to mount root from ufs:da0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ? List of GEOM managed disk devices: da0s1 da0 fd0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:da0 Trying to mount root from ufs:da0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ? List of GEOM managed disk devices: da0s2 da0s1 da0 fd0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:da0 Trying to mount root from ufs:da0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ? List of GEOM managed disk devices: da0s1a da0s2 da0s1 da0 fd0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:da0d\^H \^Hs1a Trying to mount root from ufs:da0s1a GEOM_LABEL: Label for provider da0s1a is ufsid/49e5c6c95ad61dbf. GEOM_LABEL: Label ufsid/49e5c6c95ad61dbf removed. GEOM_LABEL: Label for provider da0s1a is ufsid/49e5c6c95ad61dbf. GEOM_LABEL: Label ufsid/49e5c6c95ad61dbf removed. WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. cryptosoft0: on motherboard From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 15:17: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 5C4F7106566B for ; Fri, 17 Apr 2009 15:17:07 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from mail.pica.nl (mail.pica.nl [192.87.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id ECDBF8FC0A for ; Fri, 17 Apr 2009 15:17:06 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from rebelion.Sisis.de ([10.49.96.10]) by mail.pica.nl with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 17:17:04 +0200 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n3HFH3sP004641; Fri, 17 Apr 2009 17:17:03 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Fri, 17 Apr 2009 17:17:03 +0200 From: Matthias Apitz To: Bruce Cran Message-ID: <20090417151703.GA4452@rebelion.Sisis.de> References: <20090417112318.GA8258@rebelion.Sisis.de> <20090417145137.0ea386d9@gluon.draftnet> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090417145137.0ea386d9@gluon.draftnet> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) X-OriginalArrivalTime: 17 Apr 2009 15:17:05.0215 (UTC) FILETIME=[91063CF0:01C9BF6F] Cc: freebsd-current@freebsd.org Subject: Re: CURRENT && USB network device, cdce X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 15:17:07 -0000 El día Friday, April 17, 2009 a las 02:51:37PM +0100, Bruce Cran escribió: > The GTA02 (I'm presuming that's what it is) has an RNDIS interface at Yes, it is the FR :-) nice toy, isn't it; > configuration 0 and CDCE is at configuration 1 so you'll need to run: > > usbconfig -u 1 -a 2 set_config 1 > > The parameters to -a and -u will vary depending on which ugen device it > gets detected as. Mine's often ugen3.2 but changes depending on which > other USB devices I've plugged in. > > You should then see the kernel messages relating to cdce and be able to > assign an IP address to ue0 (what was cdce0 in 7.x is now ue0). thanks; this did the trick; My EeePC gives on left USB slot ugen0.2 and on right slot ugen1.2 and I see that I have to use the above command after device attach and depending on the ugenN.M values; in RELENG_7 I did the ifconfig stuff in a devd-hook, will try to figure out how to do that now; thx again matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 15:27: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 ED97D1065672 for ; Fri, 17 Apr 2009 15:27:30 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 7B5198FC1E for ; Fri, 17 Apr 2009 15:27:30 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by ewy19 with SMTP id 19so936340ewy.43 for ; Fri, 17 Apr 2009 08:27:29 -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=AMl5ILVOOOGoi26cMwBVFPk1sH/lLQb0gfgcIOVCzlA=; b=bXEshxPJM0VFnJgpwWVI89hVsbOT886Pu5I6dEkp1xOiIcaB6HUK4NgzZd3RapRzRm 7GyFoS5iRDGU1+vhHeneOZvFprWpwxrsNzmBp/73IjTXVAzLuRX/Pu/EI4EsmrykBKME dtWCwSI7fOMTzg6zXbAbVK1STwFKqhAcK7o6g= 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=pBLCx1wIl1/8/5gc7zrmJ1mfvP0kELe1cT4hTEKe3zBvAaqqKQGoae4zl13+CfuJJR stB3KreClK11ED/yf2B8gwGIR60MIMKI2bMqrjdKlSB+RAdLT/Ce3blEukzhwZkDd74P L99AXloLOovz9LbBFkwSueVeO4Ix4tnD7F33o= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.210.22.16 with SMTP id 16mr758153ebv.74.1239982049586; Fri, 17 Apr 2009 08:27:29 -0700 (PDT) In-Reply-To: <200904170643.28862.ken@mthelicon.com> References: <7DEF7288-1304-4A64-8A23-BB03349653EA@wanderview.com> <200904170643.28862.ken@mthelicon.com> Date: Fri, 17 Apr 2009 08:27:29 -0700 X-Google-Sender-Auth: c9d941494213518c Message-ID: From: Artem Belevich To: Pegasus Mc Cleaft Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [patch] zfs livelock and thread priorities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 15:27:31 -0000 > =A0 =A0 =A0 =A0I saw the same pausing of of a scrub on my machine as Arte= m is. It may be > coincidence, but I had disabled the zil and prefetch. After I re-enabled = the Ah! I have zil disabled (kernel used to eventually lock up under load) but prefetch is still on. I'll give zil another try. --Artem From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 15: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 807EA106566C for ; Fri, 17 Apr 2009 15:55:08 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by mx1.freebsd.org (Postfix) with ESMTP id 3648B8FC1D for ; Fri, 17 Apr 2009 15:55:07 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk20 with SMTP id 20so2565187gxk.19 for ; Fri, 17 Apr 2009 08:55:07 -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=bMXqutEYzC6jDXLkfVpzQlR/0RWNhPyZNoXiBsWYSOs=; b=o7IIbGQJh4lFIAYB+WMaflhapJkL+0PX+8nex9Twop1dvDMOszWPuT4wPru2Q/UcZW 1MdbJJBAKiPMNESsYMfgKYlGgsb2HWUUHH0DMIQWqA9illPoUUOsOwdNeC1UFlJJ7pqm 3geaEK61cidw/3lSlyugl+0bh/mP7f7jcAfpQ= 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=Kz4+ouw3PKo66henBLARoc/X6FAxcM5klFntaSLZCl2iPr2QZ/TYqk3yW7sqAvjE6S LA21FISt4d7IhkgXV4xeA1YA7Hz0n9KB/UeYeAXPPDmChn9yvWpvjKgOM9CgLlpXVty2 PaBeAVoPFmIPZHt/YISRp3sneYIHD7O1OfJs0= MIME-Version: 1.0 Received: by 10.90.31.8 with SMTP id e8mr3328935age.65.1239983707017; Fri, 17 Apr 2009 08:55:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Apr 2009 08:55:06 -0700 Message-ID: From: Maksim Yevmenkin To: pluknet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: possible bug in the sbappendrecord_locked()? (Was: Re: core dump with bluetooth device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 15:55:09 -0000 On Thu, Apr 16, 2009 at 9:48 PM, pluknet wrote: > Sorry for top-posting. > > This is a fairly old bug. > See my investigation > http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019345.html ahh, i see. thanks for the pointer. please read below. >>>>> wrote: >>>>>> hi there, >>>>>> >>>>>> i'm running r191076M. when i try to send files from my mobile phone to my >>>>>> computer via bt the core dumps. here's a backtrace: >>>>>> >>>>>> Unread portion of the kernel message buffer: >>>>>> sblastmbufchk: sb_mb 0xc8d54d00 sb_mbtail 0 last 0xc8d54d00 >>>>>> packet tree: >>>>>> 0xc8d54d00 >>>>>> panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:797 >>>>>> cpuid = 0 >>>>> >>>>> are you, by change, have "options SOCKBUF_DEBUG" in your kernel? >>>> >>>> ok, there is something strange going on in the >>>> sbappendrecord_locked(). consider the following initial conditions: >>>> >>>> 1) sockbuf sb is empty, i.e. sb_mb == sb_mbtail == sb_lastrecord == NULL >>>> >>>> 2) sbappendrecord_locked() is given mbuf m0 with has exactly one mbuf, >>>> i.e. m0->m_next == NULL >>>> >>>> so >>>> >>>> void >>>> sbappendrecord_locked(struct sockbuf *sb, struct mbuf *m0) >>>> { >>>> struct mbuf *m; >>>> >>>> SOCKBUF_LOCK_ASSERT(sb); >>>> >>>> if (m0 == 0) >>>> return; >>>> m = sb->sb_mb; >>>> >>>> if (m) >>>> while (m->m_nextpkt) >>>> m = m->m_nextpkt; >>>> >>>> --> m is still NULL at this point >>>> >>>> /* >>>> * Put the first mbuf on the queue. Note this permits zero length >>>> * records. >>>> */ >>>> sballoc(sb, m0); >>>> SBLASTRECORDCHK(sb); >>>> >>>> --> passed successfully, because sb_mb == sb_lastrecord == NULL (i.e. >>>> sockbuf is empty) >>>> >>>> SBLINKRECORD(sb, m0); >>>> >>>> --> at this point sb_mb == sb_lastrecord == m0, _but_ sb_mtail == NULL >>>> >>>> if (m) >>>> m->m_nextpkt = m0; >>>> else >>>> sb->sb_mb = m0; >>>> >>>> --> not sure about those lines above, didn't SBLINKRECORD(sb, m0) take >>>> care of it already? >>>> --> in any case, still, sb_mb == sb_lastrecord == m0 _and_ still >>>> sb_mtail == NULL >>>> >>>> m = m0->m_next; >>>> m0->m_next = 0; >>>> >>>> --> m is still NULL here >>>> >>>> if (m && (m0->m_flags & M_EOR)) { >>>> m0->m_flags &= ~M_EOR; >>>> m->m_flags |= M_EOR; >>>> } >>>> >>>> --> sbcompress() is called with m == NULL, which is triggers the panic >>>> (read below) >>>> >>>> sbcompress(sb, m, m0); >>>> } >>>> >>>> =========== >>>> >>>> void >>>> sbcompress(struct sockbuf *sb, struct mbuf *m, struct mbuf *n) >>>> { >>>> int eor = 0; >>>> struct mbuf *o; >>>> >>>> SOCKBUF_LOCK_ASSERT(sb); >>>> >>>> while (m) { >>>> >>>> --> lots of code that never gets executed because m == NULL >>>> >>>> } >>>> if (eor) { >>>> KASSERT(n != NULL, ("sbcompress: eor && n == NULL")); >>>> n->m_flags |= eor; >>>> } >>>> >>>> --> this where panic happens, because sb_mbtail is still NULL, but >>>> sockbuf now contains exactly one record >>>> >>>> SBLASTMBUFCHK(sb); >>>> } >>>> >>>> so, it looks like, sbcompress() should only be called when m != NULL. >>>> also, when m == NULL, m0 should be marked as EOR. >>> >>> actually, no, EOR should be set (or not set already). >>> >>>> comments anyone? ok, this is completely untested, so be warned :) would something like the following work? am i missing something? > svn diff Index: uipc_sockbuf.c =================================================================== --- uipc_sockbuf.c (revision 191012) +++ uipc_sockbuf.c (working copy) @@ -577,10 +577,6 @@ if (m0 == 0) return; - m = sb->sb_mb; - if (m) - while (m->m_nextpkt) - m = m->m_nextpkt; /* * Put the first mbuf on the queue. Note this permits zero length * records. @@ -588,17 +584,17 @@ sballoc(sb, m0); SBLASTRECORDCHK(sb); SBLINKRECORD(sb, m0); - if (m) - m->m_nextpkt = m0; - else - sb->sb_mb = m0; + sb->sb_mbtail = m0; m = m0->m_next; m0->m_next = 0; - if (m && (m0->m_flags & M_EOR)) { - m0->m_flags &= ~M_EOR; - m->m_flags |= M_EOR; + if (m != NULL) { + if (m0->m_flags & M_EOR) { + m0->m_flags &= ~M_EOR; + m->m_flags |= M_EOR; + } + + sbcompress(sb, m, m0); } - sbcompress(sb, m, m0); } /* == thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 16:28: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 4DE101065675 for ; Fri, 17 Apr 2009 16:28:51 +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 1009B8FC26 for ; Fri, 17 Apr 2009 16:28:50 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 0326A7E821; Fri, 17 Apr 2009 08:28:49 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Fri, 17 Apr 2009 18:28:45 +0200 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.2; i386; ; ) References: <200904170836.36239.mel.flynn+fbsd.current@mailing.thruhere.net> <542798610904170031w44e51957gd342eadf747a4e97@mail.gmail.com> <200904171035.39259.mel.flynn+fbsd.current@mailing.thruhere.net> In-Reply-To: <200904171035.39259.mel.flynn+fbsd.current@mailing.thruhere.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904171828.46222.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: kde@freebsd.org, Johannes Dieterich Subject: Re: Proper procedure to update hal on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 16:28:51 -0000 On Friday 17 April 2009 10:35:39 Mel Flynn wrote: > Hi Johannes, > > On Friday 17 April 2009 09:31:46 Johannes Dieterich wrote: > > > Do I need to temporarily uninstall devel/libusb (it doesn't build now > > > anyway, > > > but maybe upgrading to today's current will fix that) then reinstall > > > it? > > > > My procedure was to deinstall devel/libusb, then I also encountered the > > same kind of mising dependencies as you do but for me a pkgdb -F > > afterwards would fix them. Then hal would also build for me. :-) > > Ah, this relies on ldconfig -r finding /usr/lib/libusb and thus not > installing devel/libusb. Gotcha. Actually, it don't :( and libusb marked as IGNORE, portmaster complaints and downhill there. Hence the patch below. Whether this patch disables usb features, I don't know. Will have to dig into cmake and find out where it stores "what is enabled/disabled". Index: x11/kdebase4-workspace/Makefile =================================================================== RCS file: /home/ncvs/ports/x11/kdebase4-workspace/Makefile,v retrieving revision 1.220 diff -u -r1.220 Makefile --- x11/kdebase4-workspace/Makefile 16 Apr 2009 05:05:56 -0000 1.220 +++ x11/kdebase4-workspace/Makefile 17 Apr 2009 16:22:14 -0000 @@ -17,8 +17,7 @@ MAINTAINER= kde@FreeBSD.org COMMENT= Basic applications for the KDE system -LIB_DEPENDS= usb-0.1.8:${PORTSDIR}/devel/libusb \ - qimageblitz.4:${PORTSDIR}/x11/qimageblitz\ +LIB_DEPENDS= qimageblitz.4:${PORTSDIR}/x11/qimageblitz\ dbus-1.3:${PORTSDIR}/devel/dbus \ hal.1:${PORTSDIR}/sysutils/hal \ xklavier.12:${PORTSDIR}/x11/libxklavier @@ -55,6 +54,11 @@ #Xmms and Googlegadgets could be enabled, #QEdje has not been ported yet. +.include +.if ${OSVERSION} < 800069 +LIB_DEPENDS+=usb-0.1.8:${PORTSDIR}/devel/libusb +.endif + post-extract: ${MKDIR} ${WRKSRC} @@ -77,4 +81,4 @@ @${MV} ${PREFIX}/lib/kde4/libexec/kdm_greet ${PREFIX}/lib/kde4/libexec/kdm-bin_greet @${INSTALL_SCRIPT} ${WRKDIR}/kdm ${PREFIX}/bin -.include +.include -- Mel From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 16:58: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 A3C88106564A; Fri, 17 Apr 2009 16:58:32 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id DB9B18FC15; Fri, 17 Apr 2009 16:58:31 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: by fxm11 with SMTP id 11so1004188fxm.43 for ; Fri, 17 Apr 2009 09:58:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.116.69 with SMTP id l5mr2456841bkq.102.1239985709072; Fri, 17 Apr 2009 09:28:29 -0700 (PDT) In-Reply-To: <20090417141817.GR11551@cicely7.cicely.de> References: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> <20090417141817.GR11551@cicely7.cicely.de> Date: Fri, 17 Apr 2009 18:28:29 +0200 Message-ID: From: =?ISO-8859-1?Q?Marius_N=FCnnerich?= To: ticso@cicely.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Leidinger , current@freebsd.org, fs@freebsd.org Subject: Re: ZFS: unlimited arc cache growth? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 16:58:33 -0000 On Fri, Apr 17, 2009 at 16:18, Bernd Walter wrote= : > On Fri, Apr 17, 2009 at 02:50:24PM +0200, Alexander Leidinger wrote: >> Hi, >> >> to fs@, please CC me, as I'm not subscribed. >> >> I monitored (by hand) a while the sysctls kstat.zfs.misc.arcstats.size >> and kstat.zfs.misc.arcstats.hdr_size. Both grow way higher (at some >> point I've seen more than 500M) than what I have configured in >> vfs.zfs.arc_max (40M). > > My understanding about this is the following: > vfs.zfs.arc_min/max are not used as min max values. > They are used as high/low watermarks. > If arc is more than max the arc a thread is triggered to reduce the > arc cache until min, but in the meantime other threads can still grow > arc so there is a race between them. Hmm, if this is true the ARC size should go down to arc_min once it did grow past arc_max and no new data is coming along but I do not observe such a thing here. It simply stays near but below arc_max here all the time. I have only /home on ZFS with moderate load. > >> After a while FS operations (e.g. pkgdb -F with about 900 packages... >> my specific workload is the fixup of gnome packages after the removal >> of the obsolete libusb port) get very slow (in my specific example I >> let the pkgdb run several times over night and it still is not >> finished). > > I've seen many workloads were prefetching can saturate disks without > ever being used. > You might want to try disabling prefetch. > Of course prefetching also grows arc. > >> The big problem with this is, that at some point in time the machine >> reboots (panic, page fault, page not present, during a fork1). I have >> the impression (beware, I have a watchdog configured, as I don't know >> if a triggered WD would cause the same panic, the following is just a >> guess) that I run out of memory of some kind (I have 1G RAM, i386, max >> kmem size 700M). I restarted =A0pkgdb several times after a reboot, and >> it continues to process the libusb removal, but hey, this is anoying. > > With just 700M kmem you should set arc values extremly small and > avoid anything which can quickly grow it. > Unfortunately accessing many small files is a know arc filling workload. > Activating vfs.zfs.cache_flush_disable can help speeding up arc decreasin= g, > with the obvous risks of course... > >> Does someone see something similar to what I describe (mainly the >> growth of the arc cache way beyond what is configured)? Anyone with >> some ideas what to try? > > In my opinion the watermark mechanism can work as it is, but there should > be a forced max - currently there is no garantied limit at all. > Nevertheless it is up for the people which know the code to decide. > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > _______________________________________________ > 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 Apr 17 17:24: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 0EC1510656BF for ; Fri, 17 Apr 2009 17:24:28 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by mx1.freebsd.org (Postfix) with ESMTP id AFEB58FC32 for ; Fri, 17 Apr 2009 17:24:27 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk20 with SMTP id 20so2655354gxk.19 for ; Fri, 17 Apr 2009 10:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x0BR4Xd/YxioPAXWl/KbeL8569yPk5z6k30c7Oq4hso=; b=dD6n3neijzijdYoOEjLk4xTxAXGCIQpZpf/4fxJiHsB6RGWapiVCrSsTRxOwwDkRI1 zZ2dX0lomQgdJmFLTrpBzH7LZcTa0t1sa5alRq5dlxKMJtnXZBHl6A6Og5qnseOelknN RYn8HVV1KTr0gADKCgtgLTmFu6X8O7TTxWWD8= 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=mJM6K256uLwH+iOVIG3mw2f5YDEZ5BJaYU/fPxC986wMRIcF/SlPZMv0yY8F+5+OdW VmVfR2XkdQnE27oaeoqgJ4L0qItNNIhUbMEEZAPtaHNv0yoxAnpbCKyUM3sHf5/TRPFs fs4lBEg8TF4Ih/TtedHubB853D9ndVd1lWVQ4= MIME-Version: 1.0 Received: by 10.90.55.3 with SMTP id d3mr3421208aga.100.1239989066907; Fri, 17 Apr 2009 10:24:26 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Apr 2009 10:24:26 -0700 Message-ID: From: Maksim Yevmenkin To: pluknet , Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: possible bug in the sbappendrecord_locked()? (Was: Re: core dump with bluetooth device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 17:24:29 -0000 On Fri, Apr 17, 2009 at 8:55 AM, Maksim Yevmenkin wrote: > On Thu, Apr 16, 2009 at 9:48 PM, pluknet wrote: >> Sorry for top-posting. >> >> This is a fairly old bug. >> See my investigation >> http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019345.html > > ahh, i see. thanks for the pointer. please read below. > >>>>>> wrote: >>>>>>> hi there, >>>>>>> >>>>>>> i'm running r191076M. when i try to send files from my mobile phone to my >>>>>>> computer via bt the core dumps. here's a backtrace: >>>>>>> >>>>>>> Unread portion of the kernel message buffer: >>>>>>> sblastmbufchk: sb_mb 0xc8d54d00 sb_mbtail 0 last 0xc8d54d00 >>>>>>> packet tree: >>>>>>> 0xc8d54d00 >>>>>>> panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:797 >>>>>>> cpuid = 0 >>>>>> >>>>>> are you, by change, have "options SOCKBUF_DEBUG" in your kernel? >>>>> >>>>> ok, there is something strange going on in the >>>>> sbappendrecord_locked(). consider the following initial conditions: >>>>> >>>>> 1) sockbuf sb is empty, i.e. sb_mb == sb_mbtail == sb_lastrecord == NULL >>>>> >>>>> 2) sbappendrecord_locked() is given mbuf m0 with has exactly one mbuf, >>>>> i.e. m0->m_next == NULL >>>>> >>>>> so >>>>> >>>>> void >>>>> sbappendrecord_locked(struct sockbuf *sb, struct mbuf *m0) >>>>> { >>>>> struct mbuf *m; >>>>> >>>>> SOCKBUF_LOCK_ASSERT(sb); >>>>> >>>>> if (m0 == 0) >>>>> return; >>>>> m = sb->sb_mb; >>>>> >>>>> if (m) >>>>> while (m->m_nextpkt) >>>>> m = m->m_nextpkt; >>>>> >>>>> --> m is still NULL at this point >>>>> >>>>> /* >>>>> * Put the first mbuf on the queue. Note this permits zero length >>>>> * records. >>>>> */ >>>>> sballoc(sb, m0); >>>>> SBLASTRECORDCHK(sb); >>>>> >>>>> --> passed successfully, because sb_mb == sb_lastrecord == NULL (i.e. >>>>> sockbuf is empty) >>>>> >>>>> SBLINKRECORD(sb, m0); >>>>> >>>>> --> at this point sb_mb == sb_lastrecord == m0, _but_ sb_mtail == NULL >>>>> >>>>> if (m) >>>>> m->m_nextpkt = m0; >>>>> else >>>>> sb->sb_mb = m0; >>>>> >>>>> --> not sure about those lines above, didn't SBLINKRECORD(sb, m0) take >>>>> care of it already? >>>>> --> in any case, still, sb_mb == sb_lastrecord == m0 _and_ still >>>>> sb_mtail == NULL >>>>> >>>>> m = m0->m_next; >>>>> m0->m_next = 0; >>>>> >>>>> --> m is still NULL here >>>>> >>>>> if (m && (m0->m_flags & M_EOR)) { >>>>> m0->m_flags &= ~M_EOR; >>>>> m->m_flags |= M_EOR; >>>>> } >>>>> >>>>> --> sbcompress() is called with m == NULL, which is triggers the panic >>>>> (read below) >>>>> >>>>> sbcompress(sb, m, m0); >>>>> } >>>>> >>>>> =========== >>>>> >>>>> void >>>>> sbcompress(struct sockbuf *sb, struct mbuf *m, struct mbuf *n) >>>>> { >>>>> int eor = 0; >>>>> struct mbuf *o; >>>>> >>>>> SOCKBUF_LOCK_ASSERT(sb); >>>>> >>>>> while (m) { >>>>> >>>>> --> lots of code that never gets executed because m == NULL >>>>> >>>>> } >>>>> if (eor) { >>>>> KASSERT(n != NULL, ("sbcompress: eor && n == NULL")); >>>>> n->m_flags |= eor; >>>>> } >>>>> >>>>> --> this where panic happens, because sb_mbtail is still NULL, but >>>>> sockbuf now contains exactly one record >>>>> >>>>> SBLASTMBUFCHK(sb); >>>>> } >>>>> >>>>> so, it looks like, sbcompress() should only be called when m != NULL. >>>>> also, when m == NULL, m0 should be marked as EOR. >>>> >>>> actually, no, EOR should be set (or not set already). >>>> >>>>> comments anyone? > > > ok, this is completely untested, so be warned :) would something like > the following work? am i missing something? > >> svn diff > Index: uipc_sockbuf.c > =================================================================== > --- uipc_sockbuf.c (revision 191012) > +++ uipc_sockbuf.c (working copy) > @@ -577,10 +577,6 @@ > > if (m0 == 0) > return; > - m = sb->sb_mb; > - if (m) > - while (m->m_nextpkt) > - m = m->m_nextpkt; > /* > * Put the first mbuf on the queue. Note this permits zero length > * records. > @@ -588,17 +584,17 @@ > sballoc(sb, m0); > SBLASTRECORDCHK(sb); > SBLINKRECORD(sb, m0); > - if (m) > - m->m_nextpkt = m0; > - else > - sb->sb_mb = m0; > + sb->sb_mbtail = m0; > m = m0->m_next; > m0->m_next = 0; > - if (m && (m0->m_flags & M_EOR)) { > - m0->m_flags &= ~M_EOR; > - m->m_flags |= M_EOR; > + if (m != NULL) { > + if (m0->m_flags & M_EOR) { > + m0->m_flags &= ~M_EOR; > + m->m_flags |= M_EOR; > + } > + > + sbcompress(sb, m, m0); > } > - sbcompress(sb, m, m0); > } > > /* > > == the patch seems to work for me. i do not see any crashes. please try it and let me know if you still have crashes with SOCKBUF_DEBUG thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 17:52:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A3BF1065672 for ; Fri, 17 Apr 2009 17:52:42 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0A6728FC08 for ; Fri, 17 Apr 2009 17:52:41 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n3HHqbNL027195; Fri, 17 Apr 2009 10:52:37 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id fu4mw4a77kr7d9vpnpzuaatbve; Fri, 17 Apr 2009 10:52:36 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <49E8C1E4.8050608@freebsd.org> Date: Fri, 17 Apr 2009 10:52:36 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090409 SeaMonkey/1.1.15 MIME-Version: 1.0 To: Johan Hendriks References: <57200BF94E69E54880C9BB1AF714BBCB5DE72E@w2003s01.double-l.local> In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB5DE72E@w2003s01.double-l.local> Content-Type: text/plain; charset=windows-1250; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: buildworld fails. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 17:52:42 -0000 This should be fixed in SVN r191196 by my update to lib/libarchive/config_freebsd.h, which disabled the crypto references here until I can sort out some other issues. If you're seeing problems after that, please let me know. Tim Johan Hendriks wrote: > Hello all on my current system my buildworld fails. > > Here is the error message > > /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x96c): In function `archive_write_mtree_finish_entry': > > : undefined reference to `SHA512_Final' > > /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x9a7): In function `archive_write_mtree_finish_entry': > > : undefined reference to `SHA384_Final' > > /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xabb): In function `archive_write_mtree_finish_entry': > > : undefined reference to `MD5_Final' > > /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe38): In function `archive_write_mtree_data': > > : undefined reference to `SHA512_Update' > > /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe52): In function `archive_write_mtree_data': > > : undefined reference to `MD5_Update' > > /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xee6): In function `archive_write_mtree_data': > > : undefined reference to `SHA384_Update' > > /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1321): In function `archive_write_mtree_header': > > : undefined reference to `SHA512_Init' > > /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x134e): In function `archive_write_mtree_header': > > : undefined reference to `SHA384_Init' > > /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1408): In function `archive_write_mtree_header': > > : undefined reference to `MD5_Init' > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/rescue/rescue. > > *** Error code 1 > > > > Stop in /usr/src/rescue/rescue. > *** Error code 1 > > > > Stop in /usr/src/rescue. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > > > > > Regards, > > Johan Hendriks > > > > _______________________________________________ > 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 Apr 17 19:05: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 31283106566B; Fri, 17 Apr 2009 19:05:58 +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 95F608FC16; Fri, 17 Apr 2009 19:05:57 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n3HJ5tmF063212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Apr 2009 21:05:56 +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 n3HJ5q2p027708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Apr 2009 21:05:52 +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 n3HJ5qJX016460; Fri, 17 Apr 2009 21:05:52 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n3HJ5qeY016459; Fri, 17 Apr 2009 21:05:52 +0200 (CEST) (envelope-from ticso) Date: Fri, 17 Apr 2009 21:05:52 +0200 From: Bernd Walter To: Marius =?iso-8859-1?Q?N=FCnnerich?= Message-ID: <20090417190551.GT11551@cicely7.cicely.de> References: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> <20090417141817.GR11551@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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.000, 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: Alexander Leidinger , ticso@cicely.de, fs@freebsd.org, current@freebsd.org Subject: Re: ZFS: unlimited arc cache growth? 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: Fri, 17 Apr 2009 19:05:58 -0000 On Fri, Apr 17, 2009 at 06:28:29PM +0200, Marius Nünnerich wrote: > On Fri, Apr 17, 2009 at 16:18, Bernd Walter wrote: > > On Fri, Apr 17, 2009 at 02:50:24PM +0200, Alexander Leidinger wrote: > >> Hi, > >> > >> to fs@, please CC me, as I'm not subscribed. > >> > >> I monitored (by hand) a while the sysctls kstat.zfs.misc.arcstats.size > >> and kstat.zfs.misc.arcstats.hdr_size. Both grow way higher (at some > >> point I've seen more than 500M) than what I have configured in > >> vfs.zfs.arc_max (40M). > > > > My understanding about this is the following: > > vfs.zfs.arc_min/max are not used as min max values. > > They are used as high/low watermarks. > > If arc is more than max the arc a thread is triggered to reduce the > > arc cache until min, but in the meantime other threads can still grow > > arc so there is a race between them. > > Hmm, if this is true the ARC size should go down to arc_min once it > did grow past arc_max and no new data is coming along but I do not > observe such a thing here. It simply stays near but below arc_max here > all the time. I have only /home on ZFS with moderate load. I had a few ideas why this could be, but scanning complete sys showed no point at all where arc_min is used. There are formular to set this value, but that's all I find. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 19:07: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 A450D106566C for ; Fri, 17 Apr 2009 19:07:20 +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 708768FC14 for ; Fri, 17 Apr 2009 19:07:20 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 022D97E818; Fri, 17 Apr 2009 11:07:18 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Fri, 17 Apr 2009 21:07:15 +0200 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.2; i386; ; ) References: <57200BF94E69E54880C9BB1AF714BBCB5DE72E@w2003s01.double-l.local> <49E8C1E4.8050608@freebsd.org> In-Reply-To: <49E8C1E4.8050608@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904172107.15616.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Tim Kientzle , Johan Hendriks Subject: Re: buildworld fails. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 19:07:21 -0000 On Friday 17 April 2009 19:52:36 Tim Kientzle wrote: > This should be fixed in SVN r191196 by my update to > lib/libarchive/config_freebsd.h, which disabled the > crypto references here until I can sort out some > other issues. It's fixed. What should we be looking for (if anything) that's now broken with crypto references disabled? -- Mel From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 19:29: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 8DFCE1065672 for ; Fri, 17 Apr 2009 19:29:46 +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 4E9358FC22 for ; Fri, 17 Apr 2009 19:29:45 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-16-27.bna.bellsouth.net [70.156.16.27]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3HJTe8c035688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Apr 2009 15:29:40 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: deeptech71@gmail.com In-Reply-To: <49E7FED0.9090708@gmail.com> References: <49E6ACEE.6080301@gmail.com> <200904161116.58094.jhb@freebsd.org> <1239913234.1991.1.camel@balrog.2hip.net> <49E7FED0.9090708@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-P92RlnQWBqcFZVDCj7++" Organization: FreeBSD Date: Fri, 17 Apr 2009 14:28:37 -0500 Message-Id: <1239996517.24514.1.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 19:29:47 -0000 --=-P92RlnQWBqcFZVDCj7++ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-04-17 at 06:00 +0200, deeptech71@gmail.com wrote: > Robert Noland wrote: > > On Thu, 2009-04-16 at 11:16 -0400, John Baldwin wrote: > >> On Wednesday 15 April 2009 11:58:38 pm deeptech71@gmail.com wrote: > >>> I can reliably (~40%) reproduce a freeze, which I think is related. > >>> > >>> Using the GENERIC debug kernel built from SVN HEAD: > >>> > >>> # cd /usr/obj/usr/src/sys/GENERIC/ > >>> # kgdb kernel.debug /var/crash/vmcore.0 > >>> GNU gdb 6.1.1 [FreeBSD] > >>> Copyright 2004 Free Software Foundation, Inc. > >>> GDB is free software, covered by the GNU General Public License, and = you are > >>> welcome to change it and/or distribute copies of it under certain=20 > >>> conditions. > >>> Type "show copying" to see the conditions.=20 > >>> > >>> There is absolutely no warranty for GDB. Type "show warranty" for=20 > >>> details. > >>> This GDB was configured as "i386-marcel-freebsd"...=20 > >> [ snipped lots of stuff ] > >> > >>> Kernel page fault with the following non-sleepable locks held:=20 > >>> > >>> exclusive sleep mutex drmdev (drmdev) r =3D 0 (0xc373f860) locked @=20 > >>> /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:777=20 > >>> > >>> KDB: stack backtrace:=20 > >>> > >>> calltrap() at calltrap+0x6=20 > >>> > >>> --- trap 0xc, eip =3D 0xc0b611b6, esp =3D 0xd67d4a98, ebp =3D 0xd67d4= b48 ---=20 > >>> > >>> slow_copyin(c373f800,c4103300,c42e64e0,d67d4b64,0,...) at=20 > >>> slow_copyin+0x6 > >>> radeon_cp_texture(c373f800,c42e64e0,c4103300,309,c0c26218,...) at=20 > >>> radeon_cp_texture+0x199=20 > >>> > >>> drm_ioctl(c39d4e00,c018644e,c42e64e0,3,c40afaf0,...) at drm_ioctl+0x3= 56=20 > >>> > >> The drm code is doing a copyin() while holding a mutex (which is not a= llowed). > >=20 > > Ok, the quick and dirty fix for this is > > http://people.freebsd.org/~rnoland/drm_radeon_state-copyin-fix.patch > >=20 > > I think there may be other places of concern though and a more proper > > fix is needed. >=20 > I still get the same lockup :( It can't be the same backtrace though... I'll get a more complete patch put together shortly. robert. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-P92RlnQWBqcFZVDCj7++ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkno2GUACgkQM4TrQ4qfROOWwQCbBicVAG6Pv2ahD9t9/DtsK4un atMAnAlnIYGTFJWePfLfNyk15a0UU49F =RHSV -----END PGP SIGNATURE----- --=-P92RlnQWBqcFZVDCj7++-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 19:41: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 24E231065672 for ; Fri, 17 Apr 2009 19:41:10 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id E8D5F8FC15 for ; Fri, 17 Apr 2009 19:41:09 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n3HJf5oE028475; Fri, 17 Apr 2009 12:41:05 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id 8va6eq3ppv6486ey9gq9ua9mxe; Fri, 17 Apr 2009 12:41:05 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <49E8DB50.2060606@freebsd.org> Date: Fri, 17 Apr 2009 12:41:04 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090409 SeaMonkey/1.1.15 MIME-Version: 1.0 To: Mel Flynn References: <57200BF94E69E54880C9BB1AF714BBCB5DE72E@w2003s01.double-l.local> <49E8C1E4.8050608@freebsd.org> <200904172107.15616.mel.flynn+fbsd.current@mailing.thruhere.net> In-Reply-To: <200904172107.15616.mel.flynn+fbsd.current@mailing.thruhere.net> Content-Type: text/plain; charset=windows-1250; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Johan Hendriks Subject: Re: buildworld fails. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 19:41:10 -0000 Mel Flynn wrote: > On Friday 17 April 2009 19:52:36 Tim Kientzle wrote: >> This should be fixed in SVN r191196 by my update to >> lib/libarchive/config_freebsd.h, which disabled the >> crypto references here until I can sort out some >> other issues. > > It's fixed. What should we be looking for (if anything) that's now broken with > crypto references disabled? Specifically, I (temporarily) disabled libarchive's ability to generate cryptographic hashes when writing mtree format. This is a new feature that nobody knows about, so I doubt it will affect you. ;-) When I re-enable it, you should be able to: tar -cf - --format=mtree --options=sha512 . and generate an mtree file with sha512 checksums. No big deal, of course, since mtree does this even better. Here's something mtree can't do, though: tar -cf - --format=mtree --options=sha512 @file.tgz to generate an mtree file (with sha512 checksum info) of the contents of a tar file. Of course, libarchive's mtree support is mostly for developers to use in building new tools that use mtree format in innovative ways. Exposing it through tar is primarily to make it easier to test. Tim P.S. I just realized that I probably broke WITHOUT_OPENSSL builds as well. I'm running a series of buildworlds today to try to verify all of this; I hope to have it all settled within 24 hours. Apologies for the turmoil. From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 19:51: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 465F81065702 for ; Fri, 17 Apr 2009 19:51:07 +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 198B88FC17 for ; Fri, 17 Apr 2009 19:51:06 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-16-27.bna.bellsouth.net [70.156.16.27]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3HJoxbH035832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Apr 2009 15:50:59 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Damian Gerow In-Reply-To: <20090417103634.GD1186@plebeian.afflictions.org> References: <200904161336.18557.jhb@freebsd.org> <20090416184738.GA60409@wep4035.physik.uni-wuerzburg.de> <200904161558.56919.jhb@freebsd.org> <49E79F49.6000606@samsco.org> <20090417103634.GD1186@plebeian.afflictions.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Pa7/Zu/6E/eJPJ7ski+p" Organization: FreeBSD Date: Fri, 17 Apr 2009 14:49:57 -0500 Message-Id: <1239997797.24514.6.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] Possible fix to recent data corruption on HEAD since 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: Fri, 17 Apr 2009 19:51:08 -0000 --=-Pa7/Zu/6E/eJPJ7ski+p Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-04-17 at 06:36 -0400, Damian Gerow wrote: > Scott Long wrote: > : John Baldwin wrote: > : > On Thursday 16 April 2009 2:47:38 pm Alexey Shuvaev wrote: > : >> On Thu, Apr 16, 2009 at 01:36:18PM -0400, John Baldwin wrote: > : >>> Due to some good sleuthing by avg@, > : >>> there is a patch that might fix the recent=20 > : >>> reports of data corruption on current. It would explain some of th= e recent=20 > : >>> reports where a file that was read would have missing gaps of bytes= . The=20 > : >>> problem is with the BUS_DMA_KEEP_PG_OFFSET changes to bus_dma. Whe= n a bounce=20 > : >>> page was used by USB2, the changes to bus_dma would actually change= the=20 > : >>> starting virtual and physical addresses of the bounce page. When t= he bounce=20 > : >>> page was no longer needed it was left in this bogus state. Later i= f another=20 > : >>> device used the same bounce page for DMA it would use the wrong off= set and=20 > : >>> address. The issue there is if the second device was doing a full = page of=20 > : >>> I/O. In that case the DMA from the device would actually spill ove= r into the=20 > : >>> next page which could in theory be used by another DMA request. It= could=20 > : >>> also break alignment assumptions (since the previous PG_OFFSET may = not be=20 > : >>> aligned and the bus_dma code assumes bounce pages for the !PG_OFFSE= T case are=20 > : >>> page aligned). The quick fix is to always restore the bounce page = to the=20 > : >>> normal state when a PG_OFFSET DMA request is finished. I'd actual= ly prefer=20 > : >>> not ever touching the page's starting addresses, but those changes = would be=20 > : >>> more invasive I believe. > : >>> > : >>> http://www.FreeBSD.org/~jhb/patches/dma_sg.patch > : >>> > : >> Am I right that hardware prerequisite in order to observe these prob= lems > : >> is amd64 + 4Gb or more of RAM? > : >=20 > : > Well, i386 with PAE would do it as well. Basically, you need USB + o= ne other > : > device that use bounce pages and the other device ends up with corrup= tion. > : >=20 > : >> Is it possible to fabricate some (artificial) test case to stress th= is > : >> particular situation (interleaved use of bounce pages by USB and som= e other > : >> device (?HDD?))? > : >=20 > : > I haven't constructed one though it might be possible to do so. > : >=20 > : >> Asking because as I understand the data corruption is silent > : >> and affected consumer (of bounce pages) should have some mechanism > : >> of detecting this (e.g. zfs' CRCs). > : >> In my case stess testing unpatched system till UFS filesystems are d= ead > : >> is no fun... > : >=20 > : > Understood. I know some other folks are going to test this and if th= ere is > : > early success that may make the risk easier to take. > : >=20 > :=20 > : I have pretty high confidence that John and Andriy found the problem an= d > : fixed it with this patch. It'll be good to get it tested, but I think > : that the risk to tester will be pretty low. >=20 > Having been running the patch for sixteen hours now, I can safely say tha= t > it fixes my issues. I think that I agree... I crashed my amd64 box a few times last night and haven't had massive damage, which is refreshing... I haven't been brave enough to panic with more than usb keyboard though... robert. > - Damian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-Pa7/Zu/6E/eJPJ7ski+p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEUEABECAAYFAkno3WUACgkQM4TrQ4qfROMX4wCeJU/Z6Xu9IlQk1r9TpEc2el3L a40AmLViDHujdB2CSw9DN9C643q7nq0= =oVgP -----END PGP SIGNATURE----- --=-Pa7/Zu/6E/eJPJ7ski+p-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 21:13: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 D504110657A2 for ; Fri, 17 Apr 2009 21:13:02 +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 AB7408FC15 for ; Fri, 17 Apr 2009 21:13:02 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-16-27.bna.bellsouth.net [70.156.16.27]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3HLCuE9036412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Apr 2009 17:12:57 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: deeptech71@gmail.com In-Reply-To: <49E7FED0.9090708@gmail.com> References: <49E6ACEE.6080301@gmail.com> <200904161116.58094.jhb@freebsd.org> <1239913234.1991.1.camel@balrog.2hip.net> <49E7FED0.9090708@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-TJNrBp/OJBJ3m4zPnVw9" Organization: FreeBSD Date: Fri, 17 Apr 2009 16:11:54 -0500 Message-Id: <1240002714.24514.13.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 21:13:03 -0000 --=-TJNrBp/OJBJ3m4zPnVw9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-04-17 at 06:00 +0200, deeptech71@gmail.com wrote: > Robert Noland wrote: > > On Thu, 2009-04-16 at 11:16 -0400, John Baldwin wrote: > >> On Wednesday 15 April 2009 11:58:38 pm deeptech71@gmail.com wrote: > >>> I can reliably (~40%) reproduce a freeze, which I think is related. > >>> > >>> Using the GENERIC debug kernel built from SVN HEAD: > >>> > >>> # cd /usr/obj/usr/src/sys/GENERIC/ > >>> # kgdb kernel.debug /var/crash/vmcore.0 > >>> GNU gdb 6.1.1 [FreeBSD] > >>> Copyright 2004 Free Software Foundation, Inc. > >>> GDB is free software, covered by the GNU General Public License, and = you are > >>> welcome to change it and/or distribute copies of it under certain=20 > >>> conditions. > >>> Type "show copying" to see the conditions.=20 > >>> > >>> There is absolutely no warranty for GDB. Type "show warranty" for=20 > >>> details. > >>> This GDB was configured as "i386-marcel-freebsd"...=20 > >> [ snipped lots of stuff ] > >> > >>> Kernel page fault with the following non-sleepable locks held:=20 > >>> > >>> exclusive sleep mutex drmdev (drmdev) r =3D 0 (0xc373f860) locked @=20 > >>> /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:777=20 > >>> > >>> KDB: stack backtrace:=20 > >>> > >>> calltrap() at calltrap+0x6=20 > >>> > >>> --- trap 0xc, eip =3D 0xc0b611b6, esp =3D 0xd67d4a98, ebp =3D 0xd67d4= b48 ---=20 > >>> > >>> slow_copyin(c373f800,c4103300,c42e64e0,d67d4b64,0,...) at=20 > >>> slow_copyin+0x6 > >>> radeon_cp_texture(c373f800,c42e64e0,c4103300,309,c0c26218,...) at=20 > >>> radeon_cp_texture+0x199=20 > >>> > >>> drm_ioctl(c39d4e00,c018644e,c42e64e0,3,c40afaf0,...) at drm_ioctl+0x3= 56=20 > >>> > >> The drm code is doing a copyin() while holding a mutex (which is not a= llowed). > >=20 > > Ok, the quick and dirty fix for this is > > http://people.freebsd.org/~rnoland/drm_radeon_state-copyin-fix.patch > >=20 > > I think there may be other places of concern though and a more proper > > fix is needed. >=20 > I still get the same lockup :( Ok, try this one... It should address all of the copyin/copyout paths in radeon. the r300_cmdbuf.c bits worry me a little, but I'm running this way now.... http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch robert. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-TJNrBp/OJBJ3m4zPnVw9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkno8JoACgkQM4TrQ4qfROPluQCeNJE+xl9/di9QK4+VYp1LdM9F 36QAniDeVo1PZy8bsR+090jHiak8LwFm =uNeJ -----END PGP SIGNATURE----- --=-TJNrBp/OJBJ3m4zPnVw9-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 21:13: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 EB5C4106566B for ; Fri, 17 Apr 2009 21:13:58 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 9B9BE8FC17 for ; Fri, 17 Apr 2009 21:13:58 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id n3HKxwIo072138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Apr 2009 15:59:59 -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 n3HKxw3j099656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Apr 2009 15:59:58 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n3HKxtlu099641; Fri, 17 Apr 2009 15:59:55 -0500 (CDT) (envelope-from dan) Date: Fri, 17 Apr 2009 15:59:55 -0500 From: Dan Nelson To: ticso@cicely.de Message-ID: <20090417205955.GK90152@dan.emsphone.com> References: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> <20090417141817.GR11551@cicely7.cicely.de> <20090417190551.GT11551@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090417190551.GT11551@cicely7.cicely.de> X-OS: FreeBSD 7.1-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Fri, 17 Apr 2009 15:59:59 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: Alexander Leidinger , Marius =?utf-8?Q?N=C3=BCnnerich?= , current@freebsd.org, fs@freebsd.org Subject: Re: ZFS: unlimited arc cache growth? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 21:14:00 -0000 In the last episode (Apr 17), Bernd Walter said: > On Fri, Apr 17, 2009 at 06:28:29PM +0200, Marius Nünnerich wrote: > > On Fri, Apr 17, 2009 at 16:18, Bernd Walter wrote: > > > On Fri, Apr 17, 2009 at 02:50:24PM +0200, Alexander Leidinger wrote: > > >> I monitored (by hand) a while the sysctls > > >> kstat.zfs.misc.arcstats.size and kstat.zfs.misc.arcstats.hdr_size. > > >> Both grow way higher (at some point I've seen more than 500M) than > > >> what I have configured in vfs.zfs.arc_max (40M). > > > > > > My understanding about this is the following: vfs.zfs.arc_min/max are > > > not used as min max values. They are used as high/low watermarks. If > > > arc is more than max the arc a thread is triggered to reduce the arc > > > cache until min, but in the meantime other threads can still grow arc > > > so there is a race between them. > > > > Hmm, if this is true the ARC size should go down to arc_min once it did > > grow past arc_max and no new data is coming along but I do not observe > > such a thing here. It simply stays near but below arc_max here all the > > time. I have only /home on ZFS with moderate load. > > I had a few ideas why this could be, but scanning complete sys showed no > point at all where arc_min is used. There are formular to set this value, > but that's all I find. zfs_arc_{min,max} are just tunables. The real variables arc_c_{min,max} get autosized and then capped to {min,max} in uts/common/fs/zfs/arc.c:arc_init() . -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 21:40: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 7C27610656EF for ; Fri, 17 Apr 2009 21:40:25 +0000 (UTC) (envelope-from rohit.trip@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 39E938FC18 for ; Fri, 17 Apr 2009 21:40:25 +0000 (UTC) (envelope-from rohit.trip@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so136448yxl.13 for ; Fri, 17 Apr 2009 14:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=J00xT4+dNoKryiwzfoEfgymyrRerwZj+fhUofBlW2Rk=; b=L7/t1NxGo6kJbc9HCKVtPJ0S4nTCMaSwc4FKb09FqpXvHH7Wir14PEvvXL3G5HBII1 /jadxm1+I7vRUFYKFtD7Zj6lzcpYEmvzmMOEN/cjjl39BS0i89EWoFoA9Bhpm9lqeUqA J28tYBB3o22mmPpWRJPtBfrO38AqO/HQqMCP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Y95q5W6FzsINnysRwBhbhzc4rx5iyZRFEoSAUJOT9LkDr8pNVJm/sQAOtsYHjCdlbn SuunbfZ8iwLxlaxIZW0EiqbFoLON88CnR2Vb/tjqSKD8T1wzHwsfvfar1+hP64+shrd3 TorcB19Q/wSi/0SZcvV4yGehSo9l77zYcxQ9E= MIME-Version: 1.0 Received: by 10.90.86.9 with SMTP id j9mr3381429agb.85.1240004424523; Fri, 17 Apr 2009 14:40:24 -0700 (PDT) Date: Fri, 17 Apr 2009 16:40:23 -0500 Message-ID: <33615c8e0904171440w44227486k5a339b9253329c74@mail.gmail.com> From: Rohit Tripathi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: latest xscreensaver-gnome-hacks build fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 21:40:25 -0000 When building from ports: gmake[1]: Entering directory `/usr/ports/x11/xscreensaver-gnome-hacks/work/xscreensaver-5.08/hacks/glx' cc -pedantic -Wall -Wstrict-prototypes -Wnested-externs -Wmissing-prototypes -Wno-overlength-strings -Wdeclaration-after -statement -std=c89 -U__STRICT_ANSI__ -c -I. -I. -I./../../utils -I./.. -I../.. -D_THREAD_SAFE -I/usr/local/include/gtk -2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/pango -1.0 -I/usr/local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/libxml2 -I/usr/local/include/libglade-2.0 -I/usr/local/include/gtk -2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -DSTANDALONE -DUSE_GL -DHAVE _CONFIG_H -O -pipe -march=prescott -I/usr/local/include -I/usr/local/include klein.c In file included from ./../xlockmore.h:39, from klein.c:18: /usr/local/include/GL/glu.h:287: warning: function declaration isn't a prototype klein.c: In function 'draw_klein': klein.c:399: internal compiler error: in assign_386_stack_local, at config/i386/i386.c:13484 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[1]: *** [klein.o] Error 1 gmake[1]: Leaving directory `/usr/ports/x11/xscreensaver-gnome-hacks/work/xscreensaver-5.08/hacks/glx' gmake: *** [all] Error 5 *** Error code 1 Stop in /usr/ports/x11/xscreensaver-gnome-hacks. *** Error code 1 Stop in /usr/ports/x11/xscreensaver-gnome-hacks. *** Error code 1 Stop in /usr/ports/x11/gnome-screensaver. *** Error code 1 Stop in /usr/ports/x11/gnome-screensaver. *** Error code 1 Stop in /usr/ports/x11/gnome2-lite. *** Error code 1 Stop in /usr/ports/x11/gnome2-lite. From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 21: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 4D410106564A for ; Fri, 17 Apr 2009 21:51:06 +0000 (UTC) (envelope-from grog@lemis.com) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.freebsd.org (Postfix) with ESMTP id 0DED08FC0A for ; Fri, 17 Apr 2009 21:51:05 +0000 (UTC) (envelope-from grog@lemis.com) Received: from dereel.lemis.com (ozlabs.org [203.10.76.45]) by ozlabs.org (Postfix) with ESMTP id 25251DDDF3; Sat, 18 Apr 2009 07:31:28 +1000 (EST) Received: by dereel.lemis.com (Postfix, from userid 1004) id 98342A108E; Sat, 18 Apr 2009 07:31:25 +1000 (EST) Date: Sat, 18 Apr 2009 07:31:25 +1000 From: Greg 'groggy' Lehey To: Alex Keda Message-ID: <20090417213125.GI13564@dereel.lemis.com> References: <49E895CB.2040407@lissyara.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vjQsMS/9MbKYGLq" Content-Disposition: inline In-Reply-To: <49E895CB.2040407@lissyara.su> User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-current@freebsd.org Subject: Re: new usb stack - boot problem from usb hdd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 21:51:06 -0000 --5vjQsMS/9MbKYGLq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Friday, 17 April 2009 at 18:44:27 +0400, Alex Keda wrote: > After boot, before mount, disk da0 lost, or some partition > lost/uninitialised > > ... > umass0:0:0:-1: Attached to scbus0 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers > da0: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) > Trying to mount root from ufs:/dev/da0s1a > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:da0s1a > ? List valid disk boot devices > Abort manual input FWIW, I'm experiencing a similar problem with a USB stick. I get an error 2 on the device entry (also /dev/da0s1a), followed by a panic with an incomplete stack backtrace. I'm going to try remote debugging to get more information; watch this space. Greg -- See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --5vjQsMS/9MbKYGLq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkno9S0ACgkQIubykFB6QiO7JwCfdlSahOKN7RHk5eE/5sCVFcWl AdwAnj7S9n+C7kMo16wt9zKZJgy6sKSO =+Mg5 -----END PGP SIGNATURE----- --5vjQsMS/9MbKYGLq-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 21:56: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 6CB09106564A; Fri, 17 Apr 2009 21:56:07 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 9CD418FC18; Fri, 17 Apr 2009 21:56:06 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: by fxm11 with SMTP id 11so1106904fxm.43 for ; Fri, 17 Apr 2009 14:56:05 -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 :content-transfer-encoding; bh=B2ceqMPPzL4xUFMZ6kGWcz1O9cxdjsfw2FgwFqSOz/E=; b=hhR0ZAa4okGryeUWLXs2g4JKAKFyY3rRrgS6igvzFcPE2emtPqimrV1NIS+R9ys8Zq 2Ke5y6VVIfhghMoHMmCLmA+tylxCGoHJSz2fQcpSzfp/eeANjuDATDAH3dK2y5qN3d7X I0B5VCobgOzdpvrW7iUDw5DU4g9O6+/lLAuIM= 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:content-transfer-encoding; b=vqaiQfn+W8pMIUDAUbrJmtqmw9MWa/ZnR/g2TpdeqPLaPg4gUKnbb/Okde2Cv49avI MPPrW/Oy46o2Owj1h5uXhE5z8nMhkydh3qxQqU/VVDp9c388krs/Txw7IpSxGA9fNuOk n2hebGR/uZMyBkjCB9DsR9wcykQ17pCIBolG8= Received: by 10.86.60.15 with SMTP id i15mr2336068fga.5.1240005365544; Fri, 17 Apr 2009 14:56:05 -0700 (PDT) Received: from localhost (95-24-70-84.broadband.corbina.ru [95.24.70.84]) by mx.google.com with ESMTPS id 3sm36626fge.20.2009.04.17.14.56.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 17 Apr 2009 14:56:04 -0700 (PDT) From: Anonymous To: Tim Kientzle References: <57200BF94E69E54880C9BB1AF714BBCB5DE72E@w2003s01.double-l.local> <49E8C1E4.8050608@freebsd.org> <200904172107.15616.mel.flynn+fbsd.current@mailing.thruhere.net> <49E8DB50.2060606@freebsd.org> Date: Sat, 18 Apr 2009 01:56:00 +0400 In-Reply-To: <49E8DB50.2060606@freebsd.org> (Tim Kientzle's message of "Fri, 17 Apr 2009 12:41:04 -0700") Message-ID: <86ocuvrllb.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: buildworld fails. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 21:56:08 -0000 Tim Kientzle writes: > Mel Flynn wrote: >> On Friday 17 April 2009 19:52:36 Tim Kientzle wrote: >>> This should be fixed in SVN r191196 by my update to >>> lib/libarchive/config_freebsd.h, which disabled the >>> crypto references here until I can sort out some >>> other issues. >> >> It's fixed. What should we be looking for (if anything) that's now >> broken with crypto references disabled? > > Specifically, I (temporarily) disabled libarchive's > ability to generate cryptographic hashes when writing > mtree format. > > This is a new feature that nobody knows about, so I > doubt it will affect you. ;-) When I re-enable it, > you should be able to: > > tar -cf - --format=3Dmtree --options=3Dsha512 . > > and generate an mtree file with sha512 checksums. > No big deal, of course, since mtree does this even better. > > Here's something mtree can't do, though: > > tar -cf - --format=3Dmtree --options=3Dsha512 @file.tgz > > to generate an mtree file (with sha512 checksum info) > of the contents of a tar file. > > Of course, libarchive's mtree support is mostly for > developers to use in building new tools that use > mtree format in innovative ways. Exposing it through > tar is primarily to make it easier to test. Can you document mtree writing support in libarchive=E2=80=90formats(5) ? Ah, and fix section in that file, too .Dt libarchive-formats 3 > > Tim > > P.S. I just realized that I probably broke WITHOUT_OPENSSL > builds as well. I'm running a series of buildworlds > today to try to verify all of this; I hope to > have it all settled within 24 hours. Apologies for > the turmoil. From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 22:14:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C98501065694; Fri, 17 Apr 2009 22:14:57 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [194.58.105.35]) by mx1.freebsd.org (Postfix) with ESMTP id 886A58FC0C; Fri, 17 Apr 2009 22:14:57 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.44 (FreeBSD)) id 1LuvqV-000NjA-9V; Sat, 18 Apr 2009 01:43:39 +0400 Date: Sat, 18 Apr 2009 01:43:39 +0400 From: Slawa Olhovchenkov To: current@freebsd.org Message-ID: <20090417214339.GQ10728%slw@acropolis.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Sam Leffler Subject: ath problem w/ WPA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 22:14:58 -0000 ath0: mem 0x88000000-0x8800ffff irq 16 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: AR2413 mac 7.9 RF2413 phy 4.5 After 1 hour stable working card lost all traffic. This is time of EAP reauthentication period. When using Intel card -- all works OK. With very old kernel (~ 1 year old) all works OK. I can't test intermediate kernel -- on this kernels cardbus port don't powered correctly. Last update to -current -- now. -- Slawa Olhovchenkov From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 22:23: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 3E5B81065673 for ; Fri, 17 Apr 2009 22:23:32 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id E3FB38FC1B for ; Fri, 17 Apr 2009 22:23:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n3HMNPx0026863; Fri, 17 Apr 2009 16:23:25 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49E9015D.9000404@samsco.org> Date: Fri, 17 Apr 2009 16:23:25 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: "Greg 'groggy' Lehey" References: <49E895CB.2040407@lissyara.su> <20090417213125.GI13564@dereel.lemis.com> In-Reply-To: <20090417213125.GI13564@dereel.lemis.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.6 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Alex Keda , freebsd-current@freebsd.org Subject: Re: new usb stack - boot problem from usb hdd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 22:23:32 -0000 Greg 'groggy' Lehey wrote: > On Friday, 17 April 2009 at 18:44:27 +0400, Alex Keda wrote: >> After boot, before mount, disk da0 lost, or some partition >> lost/uninitialised >> >> ... >> umass0:0:0:-1: Attached to scbus0 >> da0 at umass-sim0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-2 device >> da0: 40.000MB/s transfers >> da0: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) >> Trying to mount root from ufs:/dev/da0s1a >> >> Manual root filesystem specification: >> : Mount using filesystem >> eg. ufs:da0s1a >> ? List valid disk boot devices >> Abort manual input > > FWIW, I'm experiencing a similar problem with a USB stick. I get an > error 2 on the device entry (also /dev/da0s1a), followed by a panic > with an incomplete stack backtrace. I'm going to try remote debugging > to get more information; watch this space. > Have you followed the rest of this thread at all and seen the candidate patch and subsequent verification?? Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 22:28: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 CD6381065670; Fri, 17 Apr 2009 22:28:00 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmmtao101.cox.net (eastrmmtao101.cox.net [68.230.240.7]) by mx1.freebsd.org (Postfix) with ESMTP id 580DC8FC16; Fri, 17 Apr 2009 22:28:00 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090417220451.ZQPB1731.eastrmmtao106.cox.net@eastrmimpo01.cox.net>; Fri, 17 Apr 2009 18:04:51 -0400 Received: from localhost ([68.103.37.153]) by eastrmimpo01.cox.net with bizsmtp id gm4q1b00R3JFCbG02m4rXn; Fri, 17 Apr 2009 18:04:51 -0400 X-Authority-Analysis: v=1.0 c=1 a=MZF1LHUSSyMA:10 a=rIo8Ia4Wvf0A:10 a=XvmqBZGVAAAA:8 a=kviXuzpPAAAA:8 a=6I5d2MoRAAAA:8 a=K4q53U9RTApeiIkofGoA:9 a=3VUeG8l2miFSozPhxqYA:7 a=7cK2Ju8V_rj4RiPj8jaK6kj1mQAA:4 a=4vB-4DCPJfMA:10 a=SV7veod9ZcQA:10 X-CM-Score: 0.00 Date: Fri, 17 Apr 2009 17:05:43 -0500 To: "Mel Flynn" From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200904170836.36239.mel.flynn+fbsd.current@mailing.thruhere.net> <542798610904170031w44e51957gd342eadf747a4e97@mail.gmail.com> <200904171035.39259.mel.flynn+fbsd.current@mailing.thruhere.net> <200904171828.46222.mel.flynn+fbsd.current@mailing.thruhere.net> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <200904171828.46222.mel.flynn+fbsd.current@mailing.thruhere.net> User-Agent: Opera Mail/9.64 (Linux) Cc: freebsd-current@freebsd.org, kde@freebsd.org, Johannes Dieterich Subject: Re: Proper procedure to update hal on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 22:28:01 -0000 On Fri, 17 Apr 2009 11:28:45 -0500, Mel Flynn wrote: > On Friday 17 April 2009 10:35:39 Mel Flynn wrote: >> Hi Johannes, >> >> On Friday 17 April 2009 09:31:46 Johannes Dieterich wrote: >> > > Do I need to temporarily uninstall devel/libusb (it doesn't build >> now >> > > anyway, >> > > but maybe upgrading to today's current will fix that) then reinstall >> > > it? >> > >> > My procedure was to deinstall devel/libusb, then I also encountered >> the >> > same kind of mising dependencies as you do but for me a pkgdb -F >> > afterwards would fix them. Then hal would also build for me. :-) >> >> Ah, this relies on ldconfig -r finding /usr/lib/libusb and thus not >> installing devel/libusb. Gotcha. > > Actually, it don't :( and libusb marked as IGNORE, portmaster complaints > and > downhill there. Hence the patch below. Whether this patch disables usb > features, I don't know. Will have to dig into cmake and find out where it > stores "what is enabled/disabled". I personal would like to see USE_LIBUSB (or without LIB) add in bsd.port.mk. Cheers, Mezz -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 23:04: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 A4C8A106566B for ; Fri, 17 Apr 2009 23:04:00 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: from marklar.blazingdot.com (marklar.blazingdot.com [207.154.84.83]) by mx1.freebsd.org (Postfix) with SMTP id 73D8B8FC17 for ; Fri, 17 Apr 2009 23:04:00 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: (qmail 34033 invoked by uid 503); 17 Apr 2009 23:04:00 -0000 Date: Fri, 17 Apr 2009 16:03:59 -0700 From: Marcus Reid To: Greg 'groggy' Lehey Message-ID: <20090417230359.GA30758@blazingdot.com> References: <49E895CB.2040407@lissyara.su> <20090417213125.GI13564@dereel.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090417213125.GI13564@dereel.lemis.com> X-Coffee-Level: nearly-fatal User-Agent: Mutt/1.5.6i Cc: Alex Keda , freebsd-current@freebsd.org Subject: Re: new usb stack - boot problem from usb hdd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 23:04:01 -0000 On Sat, Apr 18, 2009 at 07:31:25AM +1000, Greg 'groggy' Lehey wrote: > On Friday, 17 April 2009 at 18:44:27 +0400, Alex Keda wrote: > > After boot, before mount, disk da0 lost, or some partition > > lost/uninitialised > > > > ... > > umass0:0:0:-1: Attached to scbus0 > > da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-2 device > > da0: 40.000MB/s transfers > > da0: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) > > Trying to mount root from ufs:/dev/da0s1a > > > > Manual root filesystem specification: > > : Mount using filesystem > > eg. ufs:da0s1a > > ? List valid disk boot devices > > Abort manual input > > FWIW, I'm experiencing a similar problem with a USB stick. I get an > error 2 on the device entry (also /dev/da0s1a), followed by a panic > with an incomplete stack backtrace. I'm going to try remote debugging > to get more information; watch this space. There's a thread from a few days ago regarding this with a subject of "Booting from usb hard disk". There is a patch that allows me to boot, but there are still problems (I have to select usb:da0s1a at the manual root filesystem prompt still.) http://people.freebsd.org/~thompsa/root_wait.diff This was committed but then backed out as a less-than-perfect solution. Someone said that setting kern.cam.scsi_delay=10000 in loader.conf (or with option 6 at the boot prompt) helped them, but that was not the case for me. Marcus From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 23:50: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 C880D1065676 for ; Fri, 17 Apr 2009 23:50:12 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id A083D8FC12 for ; Fri, 17 Apr 2009 23:50:12 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n3HNoCSS030734; Fri, 17 Apr 2009 16:50:12 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id ci4wxqcqgccrb58272hpg9b8fe; Fri, 17 Apr 2009 16:49:56 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <49E915A4.1000108@freebsd.org> Date: Fri, 17 Apr 2009 16:49:56 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090409 SeaMonkey/1.1.15 MIME-Version: 1.0 To: Igor R References: <49E7BE78.6000802@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "current@FreeBSD.org" Subject: Re: Weird warnings from lots of applications X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Apr 2009 23:50:13 -0000 Igor R wrote: >> "unexpected character `{', expected keyword - e.g. `style' > Looks like GTK? I can't find this message in the gtk20 source anywhere. I actually ran grep over /usr/local/lib and the only library that has all of these strings is libpython. Of course, according to 'ldd', none of the programs I've seen generating these warnings uses libpython. Tim From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 01:54: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 4C7061065670 for ; Sat, 18 Apr 2009 01:54:07 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id CAAAC8FC19 for ; Sat, 18 Apr 2009 01:54:06 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: by ewy19 with SMTP id 19so1104574ewy.43 for ; Fri, 17 Apr 2009 18:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=e4BLcUN66UkQzPC1RYWRvahcbEX7u8CJZd5HTH0JlCU=; b=OJDQh2j1IP+KyRJfXp9tfbIw7yU3o9vcueGCuaTlE1TytNuZ7PQXC5PQbITGvKwkeV 4fD3hq53kiSt/PJMWGu8dWDn404vGJVwSckPrW7jywT2WXDNX/MqRSfKmGZEYSovnEF0 bBWVEBhAeq7978gGo0Y157sGDTorkSJuGqf+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=O9p5OdJWWysiBjvyQupFmjbIGBdVrXjSkYExHX4VHQz+ll0Xh4v7BWHWN1dxVG+oWV wmB4zgR9rXY6EoqHWvmzAD7G5FYjySntAMwqoJsHcxF85+RdQ0WOM2uUXLAKxklYI2Oa 6F1HTnxAjgTAYDwOmlJ6xUqxqVRgjrti0RNBQ= Received: by 10.210.131.1 with SMTP id e1mr2377233ebd.41.1240019645480; Fri, 17 Apr 2009 18:54:05 -0700 (PDT) Received: from ?157.181.96.136? (quark.teteny.elte.hu [157.181.96.136]) by mx.google.com with ESMTPS id 10sm4438496eyd.23.2009.04.17.18.54.04 (version=SSLv3 cipher=RC4-MD5); Fri, 17 Apr 2009 18:54:05 -0700 (PDT) Message-ID: <49E93312.2090403@gmail.com> Date: Sat, 18 Apr 2009 03:55:30 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 MultiZilla/1.8.3.4e SeaMonkey/1.1.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49E6ACEE.6080301@gmail.com> <200904161116.58094.jhb@freebsd.org> <1239913234.1991.1.camel@balrog.2hip.net> <49E7FED0.9090708@gmail.com> <1239996517.24514.1.camel@balrog.2hip.net> In-Reply-To: <1239996517.24514.1.camel@balrog.2hip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 01:54:07 -0000 Robert Noland wrote: > On Fri, 2009-04-17 at 06:00 +0200, deeptech71@gmail.com wrote: >> Robert Noland wrote: >>> On Thu, 2009-04-16 at 11:16 -0400, John Baldwin wrote: >>>> The drm code is doing a copyin() while holding a mutex (which is not allowed). >>> Ok, the quick and dirty fix for this is >>> http://people.freebsd.org/~rnoland/drm_radeon_state-copyin-fix.patch >>> >>> I think there may be other places of concern though and a more proper >>> fix is needed. >> I still get the same lockup :( > > It can't be the same backtrace though... I'll get a more complete patch > put together shortly. Wait do I need to do a make buildworld too? I only built a patched kernel. From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 02:36: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 E9C3E106566B for ; Sat, 18 Apr 2009 02:36:37 +0000 (UTC) (envelope-from grog@lemis.com) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.freebsd.org (Postfix) with ESMTP id A8E078FC17 for ; Sat, 18 Apr 2009 02:36:37 +0000 (UTC) (envelope-from grog@lemis.com) Received: from dereel.lemis.com (ozlabs.org [203.10.76.45]) by ozlabs.org (Postfix) with ESMTP id 85AD7DDFB4; Sat, 18 Apr 2009 12:36:34 +1000 (EST) Received: by dereel.lemis.com (Postfix, from userid 1004) id D0B81A108E; Sat, 18 Apr 2009 12:36:32 +1000 (EST) Date: Sat, 18 Apr 2009 12:36:32 +1000 From: Greg 'groggy' Lehey To: Scott Long Message-ID: <20090418023632.GJ13564@dereel.lemis.com> References: <49E895CB.2040407@lissyara.su> <20090417213125.GI13564@dereel.lemis.com> <49E9015D.9000404@samsco.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kH8JNVvasRCCW1Oz" Content-Disposition: inline In-Reply-To: <49E9015D.9000404@samsco.org> User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: Alex Keda , freebsd-current@freebsd.org Subject: Re: new usb stack - boot problem from usb hdd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 02:36:38 -0000 --kH8JNVvasRCCW1Oz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Friday, 17 April 2009 at 16:23:25 -0600, Scott Long wrote: > Greg 'groggy' Lehey wrote: >> On Friday, 17 April 2009 at 18:44:27 +0400, Alex Keda wrote: >>> After boot, before mount, disk da0 lost, or some partition >>> lost/uninitialised >> >> FWIW, I'm experiencing a similar problem with a USB stick. I get an >> error 2 on the device entry (also /dev/da0s1a), followed by a panic >> with an incomplete stack backtrace. I'm going to try remote debugging >> to get more information; watch this space. > > Have you followed the rest of this thread at all and seen the candidate > patch and subsequent verification?? Yes and no. I was replying to the original message, and this thread contains neither a candidate patch nor any verification. As of now, the thread has the original message, my reply, and yours and Marcus' replies to me--see http://lists.freebsd.org/pipermail/freebsd-current/2009-April/006042.html I suspect you're thinking of the thread that Marcus referred to, which I hadn't seen. Greg -- See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --kH8JNVvasRCCW1Oz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAknpPLAACgkQIubykFB6QiOQwQCgjShJOQc93fMIQtnvIliJeATM GD0An1Hf0KxrsWDQis+02avwnCpBeUEs =g54y -----END PGP SIGNATURE----- --kH8JNVvasRCCW1Oz-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 06:08: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 2FF9D106566B for ; Sat, 18 Apr 2009 06:08:19 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 044258FC0C for ; Sat, 18 Apr 2009 06:08:18 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n3I68EcM034137; Fri, 17 Apr 2009 23:08:14 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id ncpqkgxbb52rayacevjp5usfma; Fri, 17 Apr 2009 23:08:14 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <49E96E4E.3070206@freebsd.org> Date: Fri, 17 Apr 2009 23:08:14 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090409 SeaMonkey/1.1.15 MIME-Version: 1.0 To: Mel Flynn References: <57200BF94E69E54880C9BB1AF714BBCB5DE72E@w2003s01.double-l.local> <49E8C1E4.8050608@freebsd.org> <200904172107.15616.mel.flynn+fbsd.current@mailing.thruhere.net> In-Reply-To: <200904172107.15616.mel.flynn+fbsd.current@mailing.thruhere.net> Content-Type: text/plain; charset=windows-1250; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Johan Hendriks Subject: Re: buildworld fails. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 06:08:19 -0000 Mel Flynn wrote: > On Friday 17 April 2009 19:52:36 Tim Kientzle wrote: >> This should be fixed in SVN r191196 by my update to >> lib/libarchive/config_freebsd.h, which disabled the >> crypto references here until I can sort out some >> other issues. > > It's fixed. What should we be looking for (if anything) that's now broken with > crypto references disabled? I just re-enabled this code in libarchive, after waiting all day to ensure that buildworld succeeds both WITHOUT_OPENSSL and WITH_OPENSSL. Tim From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 06:10: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 D222A106566B for ; Sat, 18 Apr 2009 06:10:00 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 7DAE78FC0C for ; Sat, 18 Apr 2009 06:10:00 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id n3I6AuOV003019; Sat, 18 Apr 2009 02:10:56 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Rohit Tripathi In-Reply-To: <33615c8e0904171440w44227486k5a339b9253329c74@mail.gmail.com> References: <33615c8e0904171440w44227486k5a339b9253329c74@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ANFVO1BJNS14ljcZlOAG" Organization: MarcusCom, Inc. Date: Sat, 18 Apr 2009 02:10:00 -0400 Message-Id: <1240035000.18976.33.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: freebsd-current@freebsd.org Subject: Re: latest xscreensaver-gnome-hacks build fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 06:10:01 -0000 --=-ANFVO1BJNS14ljcZlOAG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-04-17 at 16:40 -0500, Rohit Tripathi wrote: > When building from ports: >=20 > gmake[1]: Entering directory > `/usr/ports/x11/xscreensaver-gnome-hacks/work/xscreensaver-5.08/hacks/glx= ' > cc -pedantic -Wall -Wstrict-prototypes -Wnested-externs > -Wmissing-prototypes -Wno-overlength-strings -Wdeclaration-after > -statement -std=3Dc89 -U__STRICT_ANSI__ -c -I. -I. -I./../../utils > -I./.. -I../.. -D_THREAD_SAFE -I/usr/local/include/gtk > -2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0 > -I/usr/local/include/cairo -I/usr/local/include/pango > -1.0 -I/usr/local/include -I/usr/local/include/glib-2.0 > -I/usr/local/lib/glib-2.0/include -I/usr/local/include/pixman-1 > -I/usr/local/include/freetype2 -I/usr/local/include/libxml2 > -I/usr/local/include/libglade-2.0 -I/usr/local/include/gtk > -2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include > -I/usr/local/include -DSTANDALONE -DUSE_GL -DHAVE > _CONFIG_H -O -pipe -march=3Dprescott -I/usr/local/include You're using non-standard CFLAGS. Switch to the standard -O2 -pipe -fno-strict-aliasing, and it will work. Joe > -I/usr/local/include klein.c > In file included from ./../xlockmore.h:39, > from klein.c:18: > /usr/local/include/GL/glu.h:287: warning: function declaration isn't a pr= ototype > klein.c: In function 'draw_klein': > klein.c:399: internal compiler error: in assign_386_stack_local, at > config/i386/i386.c:13484 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > gmake[1]: *** [klein.o] Error 1 > gmake[1]: Leaving directory > `/usr/ports/x11/xscreensaver-gnome-hacks/work/xscreensaver-5.08/hacks/glx= ' > gmake: *** [all] Error 5 > *** Error code 1 >=20 > Stop in /usr/ports/x11/xscreensaver-gnome-hacks. > *** Error code 1 >=20 > Stop in /usr/ports/x11/xscreensaver-gnome-hacks. > *** Error code 1 >=20 > Stop in /usr/ports/x11/gnome-screensaver. > *** Error code 1 >=20 > Stop in /usr/ports/x11/gnome-screensaver. > *** Error code 1 >=20 > Stop in /usr/ports/x11/gnome2-lite. > *** Error code 1 >=20 > Stop in /usr/ports/x11/gnome2-lite. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " >=20 --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-ANFVO1BJNS14ljcZlOAG 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) iEYEABECAAYFAknpbrcACgkQb2iPiv4Uz4f5rgCeOW4FYKP8WYqxr0pnPoUklOKh 8/IAoIZOBIxrqa7NL94VnUlzb3wFII7l =Spde -----END PGP SIGNATURE----- --=-ANFVO1BJNS14ljcZlOAG-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 06:17: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 87B5B106564A; Sat, 18 Apr 2009 06:17:57 +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 55F078FC08; Sat, 18 Apr 2009 06:17:57 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 77B117E818; Fri, 17 Apr 2009 22:17:55 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Sat, 18 Apr 2009 08:17:48 +0200 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.2; i386; ; ) References: <57200BF94E69E54880C9BB1AF714BBCB5DE72E@w2003s01.double-l.local> <200904172107.15616.mel.flynn+fbsd.current@mailing.thruhere.net> <49E8DB50.2060606@freebsd.org> In-Reply-To: <49E8DB50.2060606@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904180817.49926.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Tim Kientzle Subject: Re: buildworld fails. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 06:17:57 -0000 On Friday 17 April 2009 21:41:04 Tim Kientzle wrote: > Of course, libarchive's mtree support is mostly for > developers to use in building new tools that use > mtree format in innovative ways. Exposing it through > tar is primarily to make it easier to test. Hmm. Or tar could store the mtree file as the first file and we'd have a table of contents for a streaming format, if tar -c can take an mtree file and a prefix as input. Especially useful when tarring a small amount of large files, since -t would still have to through the entire file to list the entries. And you can then extract only the mtree file and compare it to you live system to figure out what's been meddled with. I like the possibilities, thanks for your work on it! -- Mel From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 07:39:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4099106564A; Sat, 18 Apr 2009 07:39:13 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 6FAAB8FC08; Sat, 18 Apr 2009 07:39:13 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2DC61.dip.t-dialin.net [217.226.220.97]) by redbull.bpaserver.net (Postfix) with ESMTP id 09C302E068; Sat, 18 Apr 2009 09:39:06 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.2.103]) by outgoing.leidinger.net (Postfix) with ESMTP id 2410FC2B67; Sat, 18 Apr 2009 09:38:59 +0200 (CEST) Date: Sat, 18 Apr 2009 09:38:57 +0200 From: Alexander Leidinger To: ticso@cicely.de Message-ID: <20090418093857.0000199a@unknown> In-Reply-To: <20090417141817.GR11551@cicely7.cicely.de> References: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> <20090417141817.GR11551@cicely7.cicely.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.10.13; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 09C302E068.61563 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.4, required 6, BAYES_00 -15.00, L_HELLO_ADDRESS 0.50, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: current@freebsd.org, fs@freebsd.org Subject: Re: ZFS: unlimited arc cache growth? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 07:39:14 -0000 On Fri, 17 Apr 2009 16:18:17 +0200 Bernd Walter wrote: > On Fri, Apr 17, 2009 at 02:50:24PM +0200, Alexander Leidinger wrote: > > Hi, > > > > to fs@, please CC me, as I'm not subscribed. > > > > I monitored (by hand) a while the sysctls > > kstat.zfs.misc.arcstats.size and kstat.zfs.misc.arcstats.hdr_size. > > Both grow way higher (at some point I've seen more than 500M) than > > what I have configured in vfs.zfs.arc_max (40M). > > My understanding about this is the following: > vfs.zfs.arc_min/max are not used as min max values. > They are used as high/low watermarks. > If arc is more than max the arc a thread is triggered to reduce the > arc cache until min, but in the meantime other threads can still grow > arc so there is a race between them. 500M (more than 10 times my max) after a night seems to be a big race... > > After a while FS operations (e.g. pkgdb -F with about 900 > > packages... my specific workload is the fixup of gnome packages > > after the removal of the obsolete libusb port) get very slow (in my > > specific example I let the pkgdb run several times over night and > > it still is not finished). > > I've seen many workloads were prefetching can saturate disks without > ever being used. > You might want to try disabling prefetch. > Of course prefetching also grows arc. Prefetching is already disabled in this case. > > The big problem with this is, that at some point in time the > > machine reboots (panic, page fault, page not present, during a > > fork1). I have the impression (beware, I have a watchdog > > configured, as I don't know if a triggered WD would cause the same > > panic, the following is just a guess) that I run out of memory of > > some kind (I have 1G RAM, i386, max kmem size 700M). I restarted > > pkgdb several times after a reboot, and it continues to process the > > libusb removal, but hey, this is anoying. > > With just 700M kmem you should set arc values extremly small and > avoid anything which can quickly grow it. > Unfortunately accessing many small files is a know arc filling > workload. Activating vfs.zfs.cache_flush_disable can help speeding up > arc decreasing, with the obvous risks of course... I have this: ---snip--- vfs.zfs.prefetch_disable=1 vm.kmem_size="700M" vm.kmem_size_max="700M" vfs.zfs.arc_max="40M" vfs.zfs.vdev.cache.size="5M" vfs.zfs.vdev.cache.bshift="13" # device read ahead: 8k vfs.zfs.vdev.max_pending="6" # congruent request to the device, + for NCQ ---snip--- Bye, Alexander. From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 07:48:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 353CD106564A; Sat, 18 Apr 2009 07:48:31 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id AC7278FC0C; Sat, 18 Apr 2009 07:48:30 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2DC61.dip.t-dialin.net [217.226.220.97]) by redbull.bpaserver.net (Postfix) with ESMTP id A1B1D2E0AD; Sat, 18 Apr 2009 09:48:26 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.2.103]) by outgoing.leidinger.net (Postfix) with ESMTP id F2787C2E1F; Sat, 18 Apr 2009 09:48:22 +0200 (CEST) Date: Sat, 18 Apr 2009 09:48:21 +0200 From: Alexander Leidinger To: Ben Kelly Message-ID: <20090418094821.00002e67@unknown> In-Reply-To: References: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.10.13; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: A1B1D2E0AD.767EF X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.823, required 6, BAYES_00 -15.00, RDNS_DYNAMIC 0.10, TW_ZF 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: current@freebsd.org, fs@freebsd.org Subject: Re: ZFS: unlimited arc cache growth? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 07:48:31 -0000 On Fri, 17 Apr 2009 10:04:15 -0400 Ben Kelly wrote: > On Apr 17, 2009, at 8:50 AM, Alexander Leidinger wrote: > > to fs@, please CC me, as I'm not subscribed. > > > > I monitored (by hand) a while the sysctls > > kstat.zfs.misc.arcstats.size and kstat.zfs.misc.arcstats.hdr_size. > > Both grow way higher (at some point I've seen more than 500M) than > > what I have configured in vfs.zfs.arc_max (40M). > > > > After a while FS operations (e.g. pkgdb -F with about 900 > > packages... my specific workload is the fixup of gnome packages > > after the removal of the obsolete libusb port) get very slow (in > > my specific example I let the pkgdb run several times over night > > and it still is not finished). > > > > The big problem with this is, that at some point in time the > > machine reboots (panic, page fault, page not present, during a > > fork1). I have the impression (beware, I have a watchdog > > configured, as I don't know if a triggered WD would cause the same > > panic, the following is just a guess) that I run out of memory of > > some kind (I have 1G RAM, i386, max kmem size 700M). I restarted > > pkgdb several times after a reboot, and it continues to process the > > libusb removal, but hey, this is anoying. > > > > Does someone see something similar to what I describe (mainly the > > growth of the arc cache way beyond what is configured)? Anyone > > with some ideas what to try? > > Can you provide the rest of the arcstats from sysctl? Also, does > your arc_reclaim_thread process get any cycles when this problem > occurs? What happens if you kill the pkgdb -F manually before it > completes? Does the arc cache size come back down or is it stuck at > the abnormally high level? I haven't tried killing pkgdb and looking at the stats, but on the idle machine (reboot after the panic and 5h of no use by me... the machine fetches my mails, has a webmail + mysql + imap interface and is a fileserver) the size is double of my max value. Again there's no real load at this time, just fetching my mails (most traffic from the FreeBSD lists) and a little bit of SpamAssassin filtering of them. When I logged in this morning the machine was rebooted about 5h ago by a panic and no FS traffic was going on (100% idle). Currently the arc_reclaim_thread has 0:12 of accumulated CPU time, the wcpu is at 0%, but it is in the running state. The machine is about 80% idle. Here are all zfs sysctls as of now (pkgdb started 5min ago): ---snip--- # sysctl -a | grep zfs vfs.zfs.arc_meta_limit: 10485760 vfs.zfs.arc_meta_used: 130211600 vfs.zfs.mdcomp_disable: 0 vfs.zfs.arc_min: 22937600 vfs.zfs.arc_max: 41943040 vfs.zfs.zfetch.array_rd_sz: 1048576 vfs.zfs.zfetch.block_cap: 256 vfs.zfs.zfetch.min_sec_reap: 2 vfs.zfs.zfetch.max_streams: 8 vfs.zfs.prefetch_disable: 1 vfs.zfs.recover: 0 vfs.zfs.txg.synctime: 5 vfs.zfs.txg.timeout: 30 vfs.zfs.scrub_limit: 10 vfs.zfs.vdev.cache.bshift: 13 vfs.zfs.vdev.cache.size: 5242880 vfs.zfs.vdev.cache.max: 16384 vfs.zfs.vdev.aggregation_limit: 131072 vfs.zfs.vdev.ramp_rate: 2 vfs.zfs.vdev.time_shift: 6 vfs.zfs.vdev.min_pending: 4 vfs.zfs.vdev.max_pending: 6 vfs.zfs.cache_flush_disable: 0 vfs.zfs.zil_disable: 0 vfs.zfs.version.zpl: 3 vfs.zfs.version.vdev_boot: 1 vfs.zfs.version.spa: 13 vfs.zfs.version.dmu_backup_stream: 1 vfs.zfs.version.dmu_backup_header: 2 vfs.zfs.version.acl: 1 vfs.zfs.debug: 0 vfs.zfs.super_owner: 0 kstat.zfs.misc.arcstats.hits: 2483157 kstat.zfs.misc.arcstats.misses: 604115 kstat.zfs.misc.arcstats.demand_data_hits: 187200 kstat.zfs.misc.arcstats.demand_data_misses: 78685 kstat.zfs.misc.arcstats.demand_metadata_hits: 2295957 kstat.zfs.misc.arcstats.demand_metadata_misses: 525430 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 0 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0 kstat.zfs.misc.arcstats.mru_hits: 1621026 kstat.zfs.misc.arcstats.mru_ghost_hits: 32102 kstat.zfs.misc.arcstats.mfu_hits: 862131 kstat.zfs.misc.arcstats.mfu_ghost_hits: 18804 kstat.zfs.misc.arcstats.deleted: 550853 kstat.zfs.misc.arcstats.recycle_miss: 287993 kstat.zfs.misc.arcstats.mutex_miss: 2 kstat.zfs.misc.arcstats.evict_skip: 654418 kstat.zfs.misc.arcstats.hash_elements: 5363 kstat.zfs.misc.arcstats.hash_elements_max: 8569 kstat.zfs.misc.arcstats.hash_collisions: 133396 kstat.zfs.misc.arcstats.hash_chains: 739 kstat.zfs.misc.arcstats.hash_chain_max: 5 kstat.zfs.misc.arcstats.p: 41943040 kstat.zfs.misc.arcstats.c: 41943040 kstat.zfs.misc.arcstats.c_min: 22937600 kstat.zfs.misc.arcstats.c_max: 41943040 kstat.zfs.misc.arcstats.size: 130467088 kstat.zfs.misc.arcstats.hdr_size: 730456 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 0 kstat.zfs.misc.vdev_cache_stats.delegations: 2728 kstat.zfs.misc.vdev_cache_stats.hits: 297326 kstat.zfs.misc.vdev_cache_stats.misses: 368918 ---snip--- Bye, Alexander. From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 08:17: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 484451065670 for ; Sat, 18 Apr 2009 08:17:29 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 097F48FC12 for ; Sat, 18 Apr 2009 08:17:28 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Lv5jr-0003U0-2S for freebsd-current@freebsd.org; Sat, 18 Apr 2009 10:17:27 +0200 Message-ID: <49E98C97.9080602@gwdg.de> Date: Sat, 18 Apr 2009 10:17:27 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Subject: acroread8 does not print any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 08:17:29 -0000 Since I am using the new linux emulator f8 I am not able to print with acroread8 any more. I get this behaviour on three different systems. The following message does appear in acroread: --------------------------------------------------------- Beim Drucken ist folgender Fehler aufgetreten... '/libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "libgcc_s.so.1"' --------------------------------------------------------- Does anyone else see this error? I would suppose that /compat/linux/lib/libc.so.6 has to be used, but acroread is looking at /usr/local/lib/compat/libc.so.6. Any suggestions what could be wrong? Let me know if I can give more information or test something. Thanks in advance, Rainer Hurling P.S.: I am running FreeBSD 8.0-CURRENT with linux_base-f8 sysctl compat.linux.osrelease: 2.6.16 /etc/make.conf OVERRIDE_LINUX_BASE_PORT=f8 OVERRIDE_LINUX_NONBASE_PORTS=f8 #ls -d /var/db/pkg/linux* linux-f8-alsa-lib-1.0.15 linux-f8-jpeg-6b linux-flashplugin-9.0r159 linux-f8-atk-1.20.0 linux-f8-libsigc++20-2.0.18 linux-kmod-compat-20080408 linux-f8-cairo-1.4.14 linux-f8-libxml2-2.7.2 linux-nvu-1.0_1 linux-f8-dri-7.0.2 linux-f8-openssl-0.9.8b linux-realplayer-10.0.9.809.20070726 linux-f8-expat-2.0.1 linux-f8-pango-1.18.4 linux-scim-gtk-fc8-1.4.7_1 linux-f8-fontconfig-2.4.2 linux-f8-png-1.2.22 linux-scim-libs-fc8-1.4.7_2 linux-f8-gtk2-2.12.8 linux-f8-tiff-3.8.2 linux_base-f8-8_11 From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 11:59: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 1DEAE10659EA; Sat, 18 Apr 2009 11:59:01 +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 977DC8FC1F; Sat, 18 Apr 2009 11:58:57 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id A327A7E818; Sat, 18 Apr 2009 03:58:55 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Sat, 18 Apr 2009 13:58:49 +0200 User-Agent: KMail/1.11.2 (FreeBSD/8.0-CURRENT; KDE/4.2.2; i386; ; ) References: <49E7BE78.6000802@freebsd.org> <49E915A4.1000108@freebsd.org> In-Reply-To: <49E915A4.1000108@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904181358.50806.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Tim Kientzle Subject: Re: Weird warnings from lots of applications X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 11:59:17 -0000 On Saturday 18 April 2009 01:49:56 Tim Kientzle wrote: > Igor R wrote: > >> "unexpected character `{', expected keyword - e.g. `style' > > > > Looks like GTK? > > I can't find this message in the gtk20 source anywhere. > > I actually ran grep over /usr/local/lib and the only > library that has all of these strings is libpython. > Of course, according to 'ldd', none of the programs > I've seen generating these warnings uses libpython. Sure they do. Just not via linking (fork or dlopen, didn't care to look). But, there's a run dep right here: # /stable/root/bin/finddep.php www/firefox lang/python26 /usr/ports/x11/xcb-proto: /usr/local/bin/python2.6 => /usr/ports/lang/python26 /usr/ports/x11/libxcb: /usr/local/bin/python2.6 => /usr/ports/lang/python26 /usr/ports/devel/glib20: /usr/local/bin/python2.6 => /usr/ports/lang/python26 -- Mel From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 12:58:38 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE88A1065C57; Sat, 18 Apr 2009 12:58:38 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id E20738FC16; Sat, 18 Apr 2009 12:58:37 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: by fxm11 with SMTP id 11so1268416fxm.43 for ; Sat, 18 Apr 2009 05:58:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.55.142 with SMTP id u14mr3348482bkg.121.1240059516812; Sat, 18 Apr 2009 05:58:36 -0700 (PDT) In-Reply-To: <20090418094821.00002e67@unknown> References: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> <20090418094821.00002e67@unknown> Date: Sat, 18 Apr 2009 14:58:36 +0200 Message-ID: From: =?ISO-8859-1?Q?Marius_N=FCnnerich?= To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fs@freebsd.org, current@freebsd.org, Ben Kelly Subject: Re: ZFS: unlimited arc cache growth? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 12:58:49 -0000 On Sat, Apr 18, 2009 at 09:48, Alexander Leidinger wrote: > On Fri, 17 Apr 2009 10:04:15 -0400 Ben Kelly wrote: > > >> On Apr 17, 2009, at 8:50 AM, Alexander Leidinger wrote: >> > to fs@, please CC me, as I'm not subscribed. >> > >> > I monitored (by hand) a while the sysctls >> > kstat.zfs.misc.arcstats.size and kstat.zfs.misc.arcstats.hdr_size. >> > Both grow way higher (at some point I've seen more than 500M) than >> > what I have configured in vfs.zfs.arc_max (40M). >> > >> > After a while FS operations (e.g. pkgdb -F with about 900 >> > packages... my specific workload is the fixup of gnome packages >> > after the removal of the obsolete libusb port) get very slow (in >> > my specific example I let the pkgdb run several times over night >> > and it still is not finished). >> > >> > The big problem with this is, that at some point in time the >> > machine reboots (panic, page fault, page not present, during a >> > fork1). I have the impression (beware, I have a watchdog >> > configured, as I don't know if a triggered WD would cause the same >> > panic, the following is just a guess) that I run out of memory of >> > some kind (I have 1G RAM, i386, max kmem size 700M). I restarted >> > pkgdb several times after a reboot, and it continues to process the >> > libusb removal, but hey, this is anoying. >> > >> > Does someone see something similar to what I describe (mainly the >> > growth of the arc cache way beyond what is configured)? Anyone >> > with some ideas what to try? >> >> Can you provide the rest of the arcstats from sysctl? =A0Also, does >> your arc_reclaim_thread process get any cycles when this problem >> occurs? What happens if you kill the pkgdb -F manually before it >> completes? Does the arc cache size come back down or is it stuck at >> the abnormally high level? > > I haven't tried killing pkgdb and looking at the stats, but on the idle > machine (reboot after the panic and 5h of no use by me... the machine > fetches my mails, has a webmail + mysql + imap interface and is a > fileserver) the size is double of my max value. Again there's no real > load at this time, just fetching my mails (most traffic from the > FreeBSD lists) and a little bit of SpamAssassin filtering of them. When > I logged in this morning the machine was rebooted about 5h ago by a > panic and no FS traffic was going on (100% idle). > > Currently the arc_reclaim_thread has 0:12 of accumulated CPU time, > the wcpu is at 0%, but it is in the running state. The machine is > about 80% idle. > [snip] How about adding a few DTrace probes into arc_reclaim_thread and see what it does? From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 13:24: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 37F2B1065E2D for ; Sat, 18 Apr 2009 13:24:48 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 4D0AB8FC26 for ; Sat, 18 Apr 2009 13:24:47 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: by fxm11 with SMTP id 11so1274511fxm.43 for ; Sat, 18 Apr 2009 06:24:46 -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=IQPwsvsYNDfrgoUihsIw/rd4TmlgLGhu4Mhy0qCId9g=; b=manY1qgmI3RrOXT0yRRI+9EznK1rovXIUQjL5Kgv21/Fc90PZ6ZnXqcgJ0Q+/lTc/H uwoSDUvjVVta13JoIJ0JYKJ7XvYemW1DsXvESxRPFcByN99BKFsdMDBLyFWfrtk2ZZVc 2vdNiHBYG+eeyIfn+wsbo3zPqtxuu9VaeSDkE= 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=e9AqiMjUpl+otabHSXyid4X/W7WHYe6yl8uxfR85KLB4b0sROfJ+8qKyQmOHe9Xu5A afc7UNnnCBzonS/ylPhmNWByvlRSWhXvYDsul1Ui6mjnPxhub08b1Ck6xj+5N2YTH64K HiyPLBl+MLFoel+247AGiGBLt537xWCwZzbQg= MIME-Version: 1.0 Received: by 10.223.110.211 with SMTP id o19mr1061665fap.57.1240061086254; Sat, 18 Apr 2009 06:24:46 -0700 (PDT) In-Reply-To: <7daacbbe0904130624r70509e06k1ceffecd7e902bb0@mail.gmail.com> References: <7daacbbe0904130203m62080028v14f6a1e4a3285dc0@mail.gmail.com> <49E3362B.9040704@gwdg.de> <7daacbbe0904130624r70509e06k1ceffecd7e902bb0@mail.gmail.com> Date: Sat, 18 Apr 2009 15:24:45 +0200 Message-ID: <7daacbbe0904180624g219f91e5gd18bb46d080c9177@mail.gmail.com> From: Dominique Goncalves To: Rainer Hurling Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Subject: Re: Unusable Xorg with USB mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 13:25:13 -0000 Hi, With disabling completly moused, it seems to make everything working as expected. According to /usr/ports/UPDATING entry 20090124: problem with moused should be resolved but unfortunuly on my desktop it persist. On Mon, Apr 13, 2009 at 3:24 PM, Dominique Goncalves wrote: > Hi Rainer, > > On Mon, Apr 13, 2009 at 2:55 PM, Rainer Hurling wrote: >> Hi Dominique, >> >> On 13.04.2009 11:03 (UTC+1), Dominique Goncalves wrote: >>> >>> Hi, >>> >>> I upgraded my FreeBSD desktop (XFCE4 and some applications) from >>> 7.1-RELEASE to 8.0-CURRENT r190942 all ports was build from scratch >>> after removing old files with make delete-old delete-old-libs. > > I should have been more precise, I followed these steps, > > upgrade to -CURRENT with the usual steps described in UPDATING > (buildworld, buildkernel, installworld, installkernel, mergemaster, > etc) > > # rm -fr /usr/local/* /var/db/pkg/* > # cd /usr/src > # yes | make delete-old > # yes | make delete-old-libs > > and rebuild ports: xorg, xfce4, firefox3 > >> as far as I know 'make delete-old delete-old-libs' has to be done from >> /usr/src and so it removes obsolete files from system (see >> /usr/src/ObsoleteFiles.inc). >> >> To remove ports (/usr/ports) and build from scratch you have to 'pkg_del= ete >> -a' or something like this... >> >>> Now it's very hard to listen music with mplayer, write text with vim, >>> browse internet with firefox... it just stop working and restart when >>> moving the mouse! >> >> There had been many changes in CURRENT and xorg in the last time. USB is >> totally new, libusb is integrated in the system (please do not install t= hat >> port!) etc. >> >> So please read /usr/ports/UPDATING, especially the entries 20090309 and >> 20090123. >> >> Hope I could help, >> Rainer >> >> >>> Let me know if you need more information. >>> >>> Any help is really appreciated, >>> Thanks. >>> >>>> dmesg >>> >>> Copyright (c) 1992-2009 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199= 4 >>> =A0 =A0 =A0 =A0The Regents of the University of California. All rights = reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 8.0-CURRENT #0 r190942: Sat Apr 11 22:05:48 CEST 2009 >>> =A0 =A0root@djdomics:/usr/obj/usr/src/sys/GENERIC_NODEBUG >>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>> CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (2000.15-MHz 686-class CPU) >>> =A0Origin =3D "GenuineIntel" =A0Id =3D 0xf24 =A0Stepping =3D 4 >>> >>> =A0Features=3D0x3febfbff >>> real memory =A0=3D 805306368 (768 MB) >>> avail memory =3D 774045696 (738 MB) >>> ACPI APIC Table: >>> MADT: Forcing active-low polarity and level trigger for SCI >>> ioapic0 irqs 0-23 on motherboard >>> kbd1 at kbdmux0 >>> acpi0: on motherboard >>> acpi0: [ITHREAD] >>> acpi0: Power Button (fixed) >>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >>> acpi_button0: on acpi0 >>> pcib0: port 0xcf8-0xcff on acpi0 >>> pci0: on pcib0 >>> agp0: on hostb0 >>> pcib1: at device 1.0 on pci0 >>> pci1: on pcib1 >>> vgapci0: mem >>> 0xde000000-0xdeffffff,0xc0000000-0xcfffffff irq 16 at device 0.0 on >>> pci1 >>> isab0: at device 2.0 on pci0 >>> isa0: on isab0 >>> atapci0: port >>> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 2.5 on >>> pci0 >>> ata0: on atapci0 >>> ata0: [ITHREAD] >>> ata1: on atapci0 >>> ata1: [ITHREAD] >>> ohci0: mem 0xdfffc000-0xdfffcfff irq 20 at >>> device 3.0 on pci0 >>> ohci0: [ITHREAD] >>> usbus0: on ohci0 >>> ohci1: mem 0xdfffd000-0xdfffdfff irq 21 at >>> device 3.1 on pci0 >>> ohci1: [ITHREAD] >>> usbus1: on ohci1 >>> ohci2: mem 0xdfffe000-0xdfffefff irq 22 at >>> device 3.2 on pci0 >>> ohci2: [ITHREAD] >>> usbus2: on ohci2 >>> ehci0: mem 0xdffff000-0xdfffffff >>> irq 23 at device 3.3 on pci0 >>> ehci0: [ITHREAD] >>> usbus3: EHCI version 1.0 >>> usbus3: on ehci0 >>> pcm0: port >>> 0xdc00-0xdc1f,0xd800-0xd80f,0xd400-0xd40f,0xd000-0xd03f irq 19 at >>> device 8.0 on pci0 >>> pcm0: [ITHREAD] >>> pcm0: system configuration >>> =A0SubVendorID: 0x1412, SubDeviceID: 0xd63b >>> =A0XIN2 Clock Source: 22.5792MHz(44.1kHz*512) >>> =A0MPU-401 UART(s) #: 1 >>> =A0AC'97 codec: not exist >>> =A0ADC #: 4 >>> =A0DAC #: 4 >>> =A0Multi-track converter type: I2S(96KHz support, 24bit resolution, ID#= 0x2) >>> =A0S/PDIF(IN/OUT): 1/1 ID# 0x00 >>> =A0GPIO(mask/dir/state): 0x04/0xfb/0x7e >>> rl0: port 0xcc00-0xccff mem >>> 0xdfffbf00-0xdfffbfff irq 18 at device 11.0 on pci0 >>> miibus0: on rl0 >>> rlphy0: PHY 0 on miibus0 >>> rlphy0: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >>> rl0: Ethernet address: 00:10:dc:82:9b:d2 >>> rl0: [ITHREAD] >>> atrtc0: port 0x70-0x71 irq 8 on acpi0 >>> fdc1: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq >>> 6 drq 2 on acpi0 >>> fdc1: [FILTER] >>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >>> uart0: [FILTER] >>> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >>> uart1: [FILTER] >>> ppc0: port 0x378-0x37f irq 7 on acpi0 >>> ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode >>> ppc0: [ITHREAD] >>> ppbus0: on ppc0 >>> plip0: on ppbus0 >>> plip0: [ITHREAD] >>> lpt0: on ppbus0 >>> lpt0: [ITHREAD] >>> lpt0: Interrupt-driven port >>> ppi0: on ppbus0 >>> cpu0: on acpi0 >>> p4tcc0: on cpu0 >>> pmtimer0 on isa0 >>> orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd27ff pnpid >>> ORM0000 on isa0 >>> sc0: at flags 0x100 on isa0 >>> sc0: VGA <16 virtual consoles, flags=3D0x300> >>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on is= a0 >>> atkbdc0: at port 0x60,0x64 on isa0 >>> atkbd0: irq 1 on atkbdc0 >>> kbd0 at atkbd0 >>> atkbd0: [GIANT-LOCKED] >>> atkbd0: [ITHREAD] >>> fdc0: No FDOUT register! >>> Timecounter "TSC" frequency 2000150592 Hz quality 800 >>> Timecounters tick every 1.000 msec >>> usbus0: 12Mbps Full Speed USB v1.0 >>> usbus1: 12Mbps Full Speed USB v1.0 >>> usbus2: 12Mbps Full Speed USB v1.0 >>> usbus3: 480Mbps High Speed USB v2.0 >>> ad0: 57241MB at ata0-master UDMA100 >>> 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 >>> ad1: 57241MB at ata0-slave UDMA100 >>> uhub0: 2 ports with 2 removable, self powered >>> uhub1: 2 ports with 2 removable, self powered >>> uhub2: 2 ports with 2 removable, self powered >>> acd0: DVDROM at ata1-master UDMA33 >>> GEOM: ad0: partition 1 does not start on a track boundary. >>> GEOM: ad0: partition 1 does not end on a track boundary. >>> acd1: CDRW at ata1-slave UDMA33 >>> GEOM: ad0s2: geometry does not match label (255h,63s !=3D 16h,255s). >>> GEOM: ad1: partition 1 does not start on a track boundary. >>> GEOM: ad1: partition 1 does not end on a track boundary. >>> uhub3: 6 ports with 6 removable, self powered >>> acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 >>> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 >>> cd0 at ata1 bus 0 target 1 lun 0 >>> cd0: Removable CD-ROM SCSI-0 device >>> cd0: 33.000MB/s transfers >>> cd0: cd present [196100 x 2048 byte records] >>> cd1 at ata1 bus 0 target 0 lun 0 >>> cd1: Removable CD-ROM SCSI-0 device >>> cd1: 33.000MB/s transfers >>> cd1: cd present [3510947 x 2048 byte records] >>> GEOM_LABEL: Label for provider acd0 is iso9660/DIE_HARD_1. >>> GEOM_LABEL: Label for provider ad0s2a is ufsid/47fa91abbef03a13. >>> GEOM_LABEL: Label for provider ad0s2d is ufsid/47fa91ad7b28768a. >>> GEOM_LABEL: Label for provider ad0s2e is ufsid/47fa91abefc1e226. >>> GEOM_LABEL: Label for provider ad0s2f is ufsid/47fa91abfb5c1768. >>> GEOM: ad1s2: geometry does not match label (255h,63s !=3D 16h,255s). >>> GEOM: ad1s3: geometry does not match label (16h,63s !=3D 16h,255s). >>> ugen2.2: at usbus2 >>> ums0: on usbus2 >>> ums0: 3 buttons and [XYZ] coordinates ID=3D0 >>> GEOM_LABEL: Label for provider acd1 is iso9660/CDROM. >>> GEOM_LABEL: Label for provider ad1s2a is ufsid/423b25e8c0bf6015. >>> GEOM_LABEL: Label for provider ad1s2d is ufsid/423b25e933d9f5b1. >>> GEOM_LABEL: Label for provider ad1s2e is ufsid/423b25e88d1a575d. >>> GEOM_LABEL: Label for provider ad1s2f is ufsid/423b25e8f04b19a7. >>> GEOM_LABEL: Label for provider ad1s3g is ufsid/423de7c40ececa0b. >>> GEOM_LABEL: Label for provider ad1s3i is ufsid/423de7c57cc3c44b. >>> GEOM_LABEL: Label for provider ad1s3j is ufsid/423de7cf5ab394ca. >>> acd1: FAILURE - READ_BIG ILLEGAL REQUEST asc=3D0x64 ascq=3D0x00 >>> Trying to mount root from ufs:/dev/ad0s2a >>> GEOM_LABEL: Label ufsid/47fa91abbef03a13 removed. >>> GEOM_LABEL: Label for provider ad0s2a is ufsid/47fa91abbef03a13. >>> GEOM_LABEL: Label ufsid/47fa91abefc1e226 removed. >>> GEOM_LABEL: Label for provider ad0s2e is ufsid/47fa91abefc1e226. >>> GEOM_LABEL: Label ufsid/47fa91abfb5c1768 removed. >>> GEOM_LABEL: Label for provider ad0s2f is ufsid/47fa91abfb5c1768. >>> GEOM_LABEL: Label ufsid/47fa91ad7b28768a removed. >>> GEOM_LABEL: Label for provider ad0s2d is ufsid/47fa91ad7b28768a. >>> GEOM_LABEL: Label ufsid/47fa91abbef03a13 removed. >>> GEOM_LABEL: Label ufsid/47fa91abefc1e226 removed. >>> GEOM_LABEL: Label ufsid/47fa91abfb5c1768 removed. >>> GEOM_LABEL: Label ufsid/47fa91ad7b28768a removed. >>> rl0: link state changed to UP >>> >>>> vmstat -i >>> >>> interrupt =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0total =A0 = =A0 =A0 rate >>> irq1: atkbd0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01823 =A0 = =A0 =A0 =A0 =A01 >>> irq14: ata0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A010943 =A0 = =A0 =A0 =A0 =A07 >>> irq15: ata1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4692 =A0 = =A0 =A0 =A0 =A03 >>> irq18: rl0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 32566 =A0 = =A0 =A0 =A0 22 >>> irq19: pcm0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A099133 =A0 = =A0 =A0 =A0 68 >>> irq22: ohci2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 31197 =A0 =A0 = =A0 =A0 21 >>> irq23: ehci0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 = =A0 =A0 =A0 =A00 >>> cpu0: timer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02872088 =A0 =A0 = =A0 1998 >>> Total =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A03052444 = =A0 =A0 =A0 2124 >>> >>>> cat /etc/rc.conf >>> >>> # -- sysinstall generated deltas -- # Mon Apr =A07 23:50:43 2008 >>> # Created: Mon Apr =A07 23:50:43 2008 >>> # Enable network daemons for user convenience. >>> # Please make all changes to this file, not to /etc/defaults/rc.conf. >>> # This file now contains just the overrides from /etc/defaults/rc.conf. >>> hostname=3D"djdomics" >>> ifconfig_rl0=3D"DHCP" >>> keymap=3D"fr.iso.acc" >>> sshd_enable=3D"YES" >>> gnome_enable=3D"YES" >>> >>>> cat /etc/X11/xorg.conf >>> >>> Section "ServerLayout" >>> =A0 =A0 =A0 =A0Identifier =A0 =A0 "X.org Configured" >>> =A0 =A0 =A0 =A0Screen =A0 =A0 =A00 =A0"Screen0" 0 0 >>> =A0 =A0 =A0 =A0InputDevice =A0 =A0"Mouse0" "CorePointer" >>> =A0 =A0 =A0 =A0InputDevice =A0 =A0"Keyboard0" "CoreKeyboard" >>> =A0 =A0 =A0 =A0Option =A0 =A0 =A0 =A0 "AllowEmptyInput" "off" >>> EndSection >>> >>> Section "Files" >>> =A0 =A0 =A0 =A0ModulePath =A0 "/usr/local/lib/xorg/modules" >>> =A0 =A0 =A0 =A0FontPath =A0 =A0 "/usr/local/lib/X11/fonts/misc/" >>> =A0 =A0 =A0 =A0FontPath =A0 =A0 "/usr/local/lib/X11/fonts/TTF/" >>> =A0 =A0 =A0 =A0FontPath =A0 =A0 "/usr/local/lib/X11/fonts/OTF" >>> =A0 =A0 =A0 =A0FontPath =A0 =A0 "/usr/local/lib/X11/fonts/Type1/" >>> =A0 =A0 =A0 =A0FontPath =A0 =A0 "/usr/local/lib/X11/fonts/100dpi/" >>> =A0 =A0 =A0 =A0FontPath =A0 =A0 "/usr/local/lib/X11/fonts/75dpi/" >>> EndSection >>> >>> Section "Module" >>> =A0 =A0 =A0 =A0Load =A0"dbe" >>> =A0 =A0 =A0 =A0Load =A0"dri" >>> =A0 =A0 =A0 =A0Load =A0"extmod" >>> =A0 =A0 =A0 =A0Load =A0"glx" >>> =A0 =A0 =A0 =A0Load =A0"record" >>> =A0 =A0 =A0 =A0Load =A0"xtrap" >>> =A0 =A0 =A0 =A0Load =A0"freetype" >>> EndSection >>> >>> Section "InputDevice" >>> =A0 =A0 =A0 =A0Identifier =A0"Keyboard0" >>> =A0 =A0 =A0 =A0Driver =A0 =A0 =A0"kbd" >>> =A0 =A0 =A0 =A0Option =A0 =A0 =A0"XkbLayout" "fr" >>> EndSection >>> >>> Section "InputDevice" >>> =A0 =A0 =A0 =A0Identifier =A0"Mouse0" >>> =A0 =A0 =A0 =A0Driver =A0 =A0 =A0"mouse" >>> =A0 =A0 =A0 =A0Option =A0 =A0 =A0"Protocol" "auto" >>> =A0 =A0 =A0 =A0Option =A0 =A0 =A0"Device" "/dev/sysmouse" >>> =A0 =A0 =A0 =A0Option =A0 =A0 =A0"ZAxisMapping" "4 5 6 7" >>> EndSection >>> >>> Section "Monitor" >>> =A0 =A0 =A0 =A0#DisplaySize =A0 =A0 =A0320 =A0 240 =A0 =A0 # mm >>> =A0 =A0 =A0 =A0Identifier =A0 "Monitor0" >>> =A0 =A0 =A0 =A0VendorName =A0 "FUS" >>> =A0 =A0 =A0 =A0ModelName =A0 =A0"C700" >>> =A0 =A0 =A0 =A0HorizSync =A0 =A030.0 - 72.0 >>> =A0 =A0 =A0 =A0VertRefresh =A050.0 - 160.0 >>> =A0 =A0 =A0 =A0Option =A0 =A0 =A0"DPMS" >>> EndSection >>> >>> Section "Device" >>> =A0 =A0 =A0 =A0### Available Driver options are:- >>> =A0 =A0 =A0 =A0### Values: : integer, : float, : "True"/"Fa= lse", >>> =A0 =A0 =A0 =A0### : "String", : " Hz/kHz/MHz" >>> =A0 =A0 =A0 =A0### [arg]: arg optional >>> =A0 =A0 =A0 =A0#Option =A0 =A0 "SWcursor" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# [] >>> =A0 =A0 =A0 =A0#Option =A0 =A0 "HWcursor" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# [] >>> =A0 =A0 =A0 =A0#Option =A0 =A0 "NoAccel" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 # [] >>> =A0 =A0 =A0 =A0#Option =A0 =A0 "ShadowFB" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# [] >>> =A0 =A0 =A0 =A0#Option =A0 =A0 "UseFBDev" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# [] >>> =A0 =A0 =A0 =A0#Option =A0 =A0 "Rotate" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0# [] >>> =A0 =A0 =A0 =A0#Option =A0 =A0 "VideoKey" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# >>> =A0 =A0 =A0 =A0#Option =A0 =A0 "FlatPanel" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 # [] >>> =A0 =A0 =A0 =A0#Option =A0 =A0 "FPDither" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# [] >>> =A0 =A0 =A0 =A0#Option =A0 =A0 "CrtcNumber" =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0# >>> =A0 =A0 =A0 =A0#Option =A0 =A0 "FPScale" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 # [] >>> =A0 =A0 =A0 =A0#Option =A0 =A0 "FPTweak" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 # >>> =A0 =A0 =A0 =A0#Option =A0 =A0 "DualHead" =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0# [] >>> =A0 =A0 =A0 =A0Identifier =A0"Card0" >>> =A0 =A0 =A0 =A0Driver =A0 =A0 =A0"nv" >>> =A0 =A0 =A0 =A0VendorName =A0"nVidia Corporation" >>> =A0 =A0 =A0 =A0BoardName =A0 "NV36 [GeForce FX 5700LE]" >>> =A0 =A0 =A0 =A0BusID =A0 =A0 =A0 "PCI:1:0:0" >>> EndSection >>> >>> Section "Screen" >>> =A0 =A0 =A0 =A0Identifier "Screen0" >>> =A0 =A0 =A0 =A0Device =A0 =A0 "Card0" >>> =A0 =A0 =A0 =A0Monitor =A0 =A0"Monitor0" >>> =A0 =A0 =A0 =A0SubSection "Display" >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Viewport =A0 0 0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Depth =A0 =A0 1 >>> =A0 =A0 =A0 =A0EndSubSection >>> =A0 =A0 =A0 =A0SubSection "Display" >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Viewport =A0 0 0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Depth =A0 =A0 4 >>> =A0 =A0 =A0 =A0EndSubSection >>> =A0 =A0 =A0 =A0SubSection "Display" >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Viewport =A0 0 0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Depth =A0 =A0 8 >>> =A0 =A0 =A0 =A0EndSubSection >>> =A0 =A0 =A0 =A0SubSection "Display" >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Viewport =A0 0 0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Depth =A0 =A0 15 >>> =A0 =A0 =A0 =A0EndSubSection >>> =A0 =A0 =A0 =A0SubSection "Display" >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Viewport =A0 0 0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Depth =A0 =A0 16 >>> =A0 =A0 =A0 =A0EndSubSection >>> =A0 =A0 =A0 =A0SubSection "Display" >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Viewport =A0 0 0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Depth =A0 =A0 24 >>> =A0 =A0 =A0 =A0EndSubSection >>> EndSection >>> >>> >>> >> > > > > -- > There's this old saying: "Give a man a fish, feed him for a day. Teach > a man to fish, feed him for life." > Regards. --=20 There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 14:32: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 8C6F410656E9 for ; Sat, 18 Apr 2009 14:32:57 +0000 (UTC) (envelope-from wmoran@potentialtech.com) Received: from mail.potentialtech.com (internet.potentialtech.com [66.167.251.6]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0108FC12 for ; Sat, 18 Apr 2009 14:32:57 +0000 (UTC) (envelope-from wmoran@potentialtech.com) Received: from working (pool-72-95-226-5.pitbpa.ftas.verizon.net [72.95.226.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.potentialtech.com (Postfix) with ESMTPSA id 5FBBCEBC0A; Sat, 18 Apr 2009 10:17:03 -0400 (EDT) Date: Sat, 18 Apr 2009 10:17:02 -0400 From: Bill Moran To: Mel Flynn Message-Id: <20090418101702.18a4fcdf.wmoran@potentialtech.com> In-Reply-To: <200904181358.50806.mel.flynn+fbsd.current@mailing.thruhere.net> References: <49E7BE78.6000802@freebsd.org> <49E915A4.1000108@freebsd.org> <200904181358.50806.mel.flynn+fbsd.current@mailing.thruhere.net> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Weird warnings from lots of applications X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 14:33:02 -0000 Mel Flynn wrote: > > On Saturday 18 April 2009 01:49:56 Tim Kientzle wrote: > > Igor R wrote: > > >> "unexpected character `{', expected keyword - e.g. `style' > > > > > > Looks like GTK? > > > > I can't find this message in the gtk20 source anywhere. > > > > I actually ran grep over /usr/local/lib and the only > > library that has all of these strings is libpython. > > Of course, according to 'ldd', none of the programs > > I've seen generating these warnings uses libpython. > > Sure they do. Just not via linking (fork or dlopen, didn't care to look). > But, there's a run dep right here: > # /stable/root/bin/finddep.php www/firefox lang/python26 > /usr/ports/x11/xcb-proto: /usr/local/bin/python2.6 => /usr/ports/lang/python26 > /usr/ports/x11/libxcb: /usr/local/bin/python2.6 => /usr/ports/lang/python26 > /usr/ports/devel/glib20: /usr/local/bin/python2.6 => /usr/ports/lang/python26 That finddep.php seems to be a rather brilliant script. Couldn't find it on the WWW anywhere ... are you keeping the code secret? -- Bill Moran http://www.potentialtech.com From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 14:41: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 9E90F1065807 for ; Sat, 18 Apr 2009 14:41:43 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED338FC14 for ; Sat, 18 Apr 2009 14:41:42 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so487613mue.3 for ; Sat, 18 Apr 2009 07:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FwBFEdrepABQqBwkNljCEOW9QopvC8zUdhK7Nr4YW9A=; b=g04jXW//PLb7wwBGl7ukpnNXy0TIBElKQj2NXaASk70a9HxV1QkqJugKdXlJY+jO/S pBRBJJYs+l/2xWMxQ/HJeVGrYZ3c546grtN+xooWupRJpk6c+JyZ7iH6Jba5PjrSYX9L KeoLpQNRKDCrHAE+upyLjMGX9b18zYmp5jxmw= 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=fRUpzZVtzd6VcnCc5yNgd/+riJtR1mFRrwCzwSOQtnJBfMtA5x9CNDskTVxqHa0XtY /doB/0zu9hPI9ROhzJxmxPMo33SvL2t24xpy89m5sZxBD7/c300AlS7SHpOHNbkLgjex fkcDKao2r6fhwXnznAVDlLcnJBz3Z8kApVgb8= MIME-Version: 1.0 Received: by 10.103.171.6 with SMTP id y6mr2033741muo.31.1240065702040; Sat, 18 Apr 2009 07:41:42 -0700 (PDT) In-Reply-To: References: Date: Sat, 18 Apr 2009 07:41:41 -0700 Message-ID: From: pluknet To: Maksim Yevmenkin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: possible bug in the sbappendrecord_locked()? (Was: Re: core dump with bluetooth device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 14:41:47 -0000 2009/4/17 Maksim Yevmenkin : > On Thu, Apr 16, 2009 at 9:48 PM, pluknet wrote: >> Sorry for top-posting. >> >> This is a fairly old bug. >> See my investigation >> http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019345.html > > ahh, i see. thanks for the pointer. please read below. > >>>>>> wrote: >>>>>>> hi there, >>>>>>> >>>>>>> i'm running r191076M. when i try to send files from my mobile phone= to my >>>>>>> computer via bt the core dumps. here's a backtrace: >>>>>>> >>>>>>> Unread portion of the kernel message buffer: >>>>>>> sblastmbufchk: sb_mb 0xc8d54d00 sb_mbtail 0 last 0xc8d54d00 >>>>>>> packet tree: >>>>>>> =A0 =A0 =A0 =A00xc8d54d00 >>>>>>> panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:797 >>>>>>> cpuid =3D 0 >>>>>> >>>>>> are you, by change, have "options =A0SOCKBUF_DEBUG" in your kernel? >>>>> >>>>> ok, there is something strange going on in the >>>>> sbappendrecord_locked(). consider the following initial conditions: >>>>> >>>>> 1) sockbuf sb is empty, i.e. sb_mb =3D=3D sb_mbtail =3D=3D sb_lastrec= ord =3D=3D NULL >>>>> >>>>> 2) sbappendrecord_locked() is given mbuf m0 with has exactly one mbuf= , >>>>> i.e. m0->m_next =3D=3D NULL >>>>> >>>>> so >>>>> >>>>> void >>>>> sbappendrecord_locked(struct sockbuf *sb, struct mbuf *m0) >>>>> { >>>>> =A0 =A0 =A0 =A0struct mbuf *m; >>>>> >>>>> =A0 =A0 =A0 =A0SOCKBUF_LOCK_ASSERT(sb); >>>>> >>>>> =A0 =A0 =A0 =A0if (m0 =3D=3D 0) >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; >>>>> =A0 =A0 =A0 =A0m =3D sb->sb_mb; >>>>> >>>>> =A0 =A0 =A0 =A0if (m) >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0while (m->m_nextpkt) >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m =3D m->m_nextpkt; >>>>> >>>>> --> m is still NULL at this point >>>>> >>>>> =A0 =A0 =A0 =A0/* >>>>> =A0 =A0 =A0 =A0 * Put the first mbuf on the queue. =A0Note this permi= ts zero length >>>>> =A0 =A0 =A0 =A0 * records. >>>>> =A0 =A0 =A0 =A0 */ >>>>> =A0 =A0 =A0 =A0sballoc(sb, m0); >>>>> =A0 =A0 =A0 =A0SBLASTRECORDCHK(sb); >>>>> >>>>> --> passed successfully, because sb_mb =3D=3D sb_lastrecord =3D=3D NU= LL (i.e. >>>>> sockbuf is empty) >>>>> >>>>> =A0 =A0 =A0 =A0SBLINKRECORD(sb, m0); >>>>> >>>>> --> at this point sb_mb =3D=3D sb_lastrecord =A0=3D=3D m0, _but_ sb_m= tail =3D=3D NULL >>>>> >>>>> =A0 =A0 =A0 =A0if (m) >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m->m_nextpkt =3D m0; >>>>> =A0 =A0 =A0 =A0else >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sb->sb_mb =3D m0; >>>>> >>>>> --> not sure about those lines above, didn't SBLINKRECORD(sb, m0) tak= e >>>>> care of it already? >>>>> --> in any case, still, sb_mb =3D=3D sb_lastrecord =3D=3D m0 _and_ st= ill >>>>> sb_mtail =3D=3D NULL >>>>> >>>>> =A0 =A0 =A0 =A0m =3D m0->m_next; >>>>> =A0 =A0 =A0 =A0m0->m_next =3D 0; >>>>> >>>>> --> m is still NULL here >>>>> >>>>> =A0 =A0 =A0 =A0if (m && (m0->m_flags & M_EOR)) { >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m0->m_flags &=3D ~M_EOR; >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m->m_flags |=3D M_EOR; >>>>> =A0 =A0 =A0 =A0} >>>>> >>>>> --> sbcompress() is called with m =3D=3D NULL, which is triggers the = panic >>>>> (read below) >>>>> >>>>> =A0 =A0 =A0 =A0sbcompress(sb, m, m0); >>>>> } >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> void >>>>> sbcompress(struct sockbuf *sb, struct mbuf *m, struct mbuf *n) >>>>> { >>>>> =A0 =A0 =A0 =A0int eor =3D 0; >>>>> =A0 =A0 =A0 =A0struct mbuf *o; >>>>> >>>>> =A0 =A0 =A0 =A0SOCKBUF_LOCK_ASSERT(sb); >>>>> >>>>> =A0 =A0 =A0 =A0while (m) { >>>>> >>>>> --> lots of code that never gets executed because m =3D=3D NULL >>>>> >>>>> =A0 =A0 =A0 =A0} >>>>> =A0 =A0 =A0 =A0if (eor) { >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0KASSERT(n !=3D NULL, ("sbcompress: eor= && n =3D=3D NULL")); >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0n->m_flags |=3D eor; >>>>> =A0 =A0 =A0 =A0} >>>>> >>>>> --> this where panic happens, because sb_mbtail is still NULL, but >>>>> sockbuf now contains exactly one record >>>>> >>>>> =A0 =A0 =A0 =A0SBLASTMBUFCHK(sb); >>>>> } >>>>> >>>>> so, it looks like, sbcompress() should only be called when m !=3D NUL= L. >>>>> also, when m =3D=3D NULL, m0 should be marked as EOR. >>>> >>>> actually, no, EOR should be set (or not set already). >>>> >>>>> comments anyone? > > > ok, this is completely untested, so be warned :) would something like > the following =A0work? am i missing something? I'm on vacations and will not able to test it until after 4/23. :( > >> svn diff > Index: uipc_sockbuf.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 > --- uipc_sockbuf.c =A0 =A0 =A0(revision 191012) > +++ uipc_sockbuf.c =A0 =A0 =A0(working copy) > @@ -577,10 +577,6 @@ > > =A0 =A0 =A0 =A0if (m0 =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; > - =A0 =A0 =A0 m =3D sb->sb_mb; > - =A0 =A0 =A0 if (m) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 while (m->m_nextpkt) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m =3D m->m_nextpkt; > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 * Put the first mbuf on the queue. =A0Note this permits z= ero length > =A0 =A0 =A0 =A0 * records. > @@ -588,17 +584,17 @@ > =A0 =A0 =A0 =A0sballoc(sb, m0); > =A0 =A0 =A0 =A0SBLASTRECORDCHK(sb); > =A0 =A0 =A0 =A0SBLINKRECORD(sb, m0); > - =A0 =A0 =A0 if (m) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->m_nextpkt =3D m0; > - =A0 =A0 =A0 else > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 sb->sb_mb =3D m0; > + =A0 =A0 =A0 sb->sb_mbtail =3D m0; > =A0 =A0 =A0 =A0m =3D m0->m_next; > =A0 =A0 =A0 =A0m0->m_next =3D 0; > - =A0 =A0 =A0 if (m && (m0->m_flags & M_EOR)) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 m0->m_flags &=3D ~M_EOR; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->m_flags |=3D M_EOR; > + =A0 =A0 =A0 if (m !=3D NULL) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (m0->m_flags & M_EOR) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m0->m_flags &=3D ~M_EOR; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->m_flags |=3D M_EOR; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 sbcompress(sb, m, m0); > =A0 =A0 =A0 =A0} > - =A0 =A0 =A0 sbcompress(sb, m, m0); > =A0} > > =A0/* > > =3D=3D > > thanks, > max > --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 15:53:40 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C6991065677; Sat, 18 Apr 2009 15:53:40 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id E9B628FC0C; Sat, 18 Apr 2009 15:53:39 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from Macintosh-4.local ([10.0.0.200]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n3IFrcEI024861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Apr 2009 08:53:39 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49E9F782.6080201@freebsd.org> Date: Sat, 18 Apr 2009 08:53:38 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Slawa Olhovchenkov References: <20090417214339.GQ10728%slw@acropolis.ru> In-Reply-To: <20090417214339.GQ10728%slw@acropolis.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: current@freebsd.org Subject: Re: ath problem w/ WPA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 15:53:41 -0000 Slawa Olhovchenkov wrote: > ath0: mem 0x88000000-0x8800ffff irq 16 at device 0.0 on cardbus0 > ath0: [ITHREAD] > ath0: AR2413 mac 7.9 RF2413 phy 4.5 > > After 1 hour stable working card lost all traffic. > This is time of EAP reauthentication period. > > When using Intel card -- all works OK. > > With very old kernel (~ 1 year old) all works OK. > > I can't test intermediate kernel -- on this kernels > cardbus port don't powered correctly. > > Last update to -current -- now. > Known problem that was diagnosed recently on this list (or possibly mobile@). wpa_supplicant is passing the kernel an unexpected key index. You can check for the mailing list postings for more information as noone has submitted a PR. Unfortunately I've got no time to look at this for at least a couple of weeks. Maybe someone else will handle it. This is a show stopper for 8.0. Sam From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 16:22:41 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D37A710656F3; Sat, 18 Apr 2009 16:22:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [194.58.105.35]) by mx1.freebsd.org (Postfix) with ESMTP id 8DE178FC13; Sat, 18 Apr 2009 16:22:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.44 (FreeBSD)) id 1LvDJQ-0004TD-MK; Sat, 18 Apr 2009 20:22:40 +0400 Date: Sat, 18 Apr 2009 20:22:40 +0400 From: Slawa Olhovchenkov To: Sam Leffler Message-ID: <20090418162240.GA91248%slw@zxy.spb.ru> References: <20090417214339.GQ10728%slw@acropolis.ru> <49E9F782.6080201@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E9F782.6080201@freebsd.org> User-Agent: Mutt/1.5.11 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: current@freebsd.org Subject: Re: ath problem w/ WPA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 16:22:46 -0000 On Sat, Apr 18, 2009 at 08:53:38AM -0700, Sam Leffler wrote: > Slawa Olhovchenkov wrote: > > ath0: mem 0x88000000-0x8800ffff irq 16 at device 0.0 on cardbus0 > > ath0: [ITHREAD] > > ath0: AR2413 mac 7.9 RF2413 phy 4.5 > > > > After 1 hour stable working card lost all traffic. > > This is time of EAP reauthentication period. > > > > When using Intel card -- all works OK. > > > > With very old kernel (~ 1 year old) all works OK. > > > > I can't test intermediate kernel -- on this kernels > > cardbus port don't powered correctly. > > > > Last update to -current -- now. > > > > Known problem that was diagnosed recently on this list (or possibly > mobile@). wpa_supplicant is passing the kernel an unexpected key index. > You can check for the mailing list postings for more information as > noone has submitted a PR. I check old wpa_supplicant -- same result. And with same wpa_supplicant (old and new) iwi worked OK. > Unfortunately I've got no time to look at this for at least a couple of > weeks. Maybe someone else will handle it. > > This is a show stopper for 8.0. From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 16:43: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 71F25106564A for ; Sat, 18 Apr 2009 16:43:32 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id CBC968FC14 for ; Sat, 18 Apr 2009 16:43:31 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: by ewy19 with SMTP id 19so1245815ewy.43 for ; Sat, 18 Apr 2009 09:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=OTuAwsPzliL6LYogBdwRIyDnndckiV4Xm//u7nsfD/Q=; b=Nb3Z6FovP0noo7ksMgf/aezzQKdXMtAlOcYHrD93ZO1yWbWDKg8EbtRlZGRjTO4O0K 5jWXF2kNspPT2m2dCCTFeqfdQYJQnBiCMnnDQD+mjGN2oA/C1ELgsP+UijFzS23l6xef p9y/NjOqX6Ih6mVMwnxLTP0n+5vK7CEDfg2zU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=nUzCU5ujgSSEDSek/MUr8O34Zbdm4obmkuHqxv20vsSt89Vwn6houQt9Bq+jNwQwNe u53AGCUfBUOw4pylnxmP64Qfk8EYzRVpP206IA9G18OCISB5pJ9I+vh0QNPq10lp7apJ ilL2p1DdmdIi/F/+0Bd+thWzBruhiicpEctI8= Received: by 10.210.11.13 with SMTP id 13mr1891967ebk.48.1240073010721; Sat, 18 Apr 2009 09:43:30 -0700 (PDT) Received: from ?157.181.96.136? (quark.teteny.elte.hu [157.181.96.136]) by mx.google.com with ESMTPS id 10sm1015985eyz.38.2009.04.18.09.43.29 (version=SSLv3 cipher=RC4-MD5); Sat, 18 Apr 2009 09:43:30 -0700 (PDT) Message-ID: <49EA038A.7080603@gmail.com> Date: Sat, 18 Apr 2009 18:44:58 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <49E6ACEE.6080301@gmail.com> <200904161116.58094.jhb@freebsd.org> <1239913234.1991.1.camel@balrog.2hip.net> <49E7FED0.9090708@gmail.com> <1240002714.24514.13.camel@balrog.2hip.net> In-Reply-To: <1240002714.24514.13.camel@balrog.2hip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 16:43:32 -0000 Robert Noland wrote: > On Fri, 2009-04-17 at 06:00 +0200, deeptech71@gmail.com wrote: >> Robert Noland wrote: >>> On Thu, 2009-04-16 at 11:16 -0400, John Baldwin wrote: >>>> The drm code is doing a copyin() while holding a mutex (which is not allowed). >>> Ok, the quick and dirty fix for this is >>> http://people.freebsd.org/~rnoland/drm_radeon_state-copyin-fix.patch >>> >>> I think there may be other places of concern though and a more proper >>> fix is needed. >> I still get the same lockup :( > > Ok, try this one... It should address all of the copyin/copyout paths in > radeon. the r300_cmdbuf.c bits worry me a little, but I'm running this > way now.... > > http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch OK, I can't seem to reproduce the crash with this patch. Thanks. From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 17:22: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 5AEBE106564A; Sat, 18 Apr 2009 17:22:46 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2599F8FC2C; Sat, 18 Apr 2009 17:22:46 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n3IHMjIB040772; Sat, 18 Apr 2009 10:22:45 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id ghkeg4gmbhknx3iutjdqepru7i; Sat, 18 Apr 2009 10:22:45 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <49EA0C64.8090709@freebsd.org> Date: Sat, 18 Apr 2009 10:22:44 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090409 SeaMonkey/1.1.15 MIME-Version: 1.0 To: Mel Flynn References: <49E7BE78.6000802@freebsd.org> <49E915A4.1000108@freebsd.org> <200904181358.50806.mel.flynn+fbsd.current@mailing.thruhere.net> In-Reply-To: <200904181358.50806.mel.flynn+fbsd.current@mailing.thruhere.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-current@freebsd.org Subject: Re: Weird warnings from lots of applications X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 17:22:49 -0000 On Saturday 18 April 2009 01:49:56 Tim Kientzle wrote: > Igor R wrote: >>> "unexpected character `{', expected keyword - e.g. `style' >> Looks like GTK? GTK is certainly involved, it appears. From ktrace, I know that it invokes open() on the raw directory and reads it just before generating the warning. From inside GDB, I can breakpoint open() and see this backtrace just before the warning gets printed: Breakpoint 2, 0x28ca9f5c in open () from /lib/libc.so.7 #0 0x28ca9f5c in open () from /lib/libc.so.7 #1 0x28a97cb2 in open () from /lib/libthr.so.3 #2 0x2836c227 in gtk_rc_get_im_module_path () from /usr/local/lib/libgtk-x11-2.0.so.0 #3 0x2836c7a4 in gtk_rc_reparse_all_for_settings () from /usr/local/lib/libgtk-x11-2.0.so.0 #4 0x28388b64 in gtk_settings_get_for_screen () from /usr/local/lib/libgtk-x11-2.0.so.0 #5 0x28388cf5 in gtk_settings_get_default () from /usr/local/lib/libgtk-x11-2.0.so.0 So gtk is reading the raw directory and trying to interpret it as a settings file. Still don't know where it's getting the screwed-up settings file name from, but this is progress. Tim From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 17:50:38 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC40F106578B; Sat, 18 Apr 2009 17:50:37 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [194.58.105.35]) by mx1.freebsd.org (Postfix) with ESMTP id 646908FC0C; Sat, 18 Apr 2009 17:50:37 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.44 (FreeBSD)) id 1LvEgP-0004ws-Gl; Sat, 18 Apr 2009 21:50:29 +0400 Date: Sat, 18 Apr 2009 21:50:29 +0400 From: Slawa Olhovchenkov To: Daniel Thiele Message-ID: <20090418175029.GB91248%slw@zxy.spb.ru> References: <20090417214339.GQ10728%slw@acropolis.ru> <49E9F782.6080201@freebsd.org> <49EA0F51.3020404@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49EA0F51.3020404@gmx.net> User-Agent: Mutt/1.5.11 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Sam Leffler , current@freebsd.org Subject: Re: ath problem w/ WPA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 17:52:00 -0000 On Sat, Apr 18, 2009 at 07:35:13PM +0200, Daniel Thiele wrote: > Sam Leffler wrote: > >[...] > >Known problem that was diagnosed recently on this list (or possibly > >mobile@). wpa_supplicant is passing the kernel an unexpected key index. > >You can check for the mailing list postings for more information as > >noone has submitted a PR. > > > > Slawa, in case you have not found if already by yourself, the posting > Sam probably is refering to is: "Wireless connection (WPA-EAP) stops > working after a while" from March 24 on this list. Thanks, now I found this thread and read. Yes, I have same problem. And I think problem in the new ath driver: any version of wpa_suplicant worked with iwi (Intel(R) PRO/Wireless 2200BG). > Sam, should we (Slawa and me) open a PR to gather all information on > this issue in one place so that it will be readily available once you > have (or someone else has) the time to look further into the problem? I can collect any additional debug -- AP controled by me (FreeeBSD 6.2, Atheros 5212). From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 18:01: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 298091065673 for ; Sat, 18 Apr 2009 18:01:58 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 667728FC0C for ; Sat, 18 Apr 2009 18:01:57 +0000 (UTC) (envelope-from dthiele@gmx.net) Received: (qmail invoked by alias); 18 Apr 2009 17:35:15 -0000 Received: from p54866599.dip.t-dialin.net (EHLO impala.vnws.lan) [84.134.101.153] by mail.gmx.net (mp013) with SMTP; 18 Apr 2009 19:35:15 +0200 X-Authenticated: #19302822 X-Provags-ID: V01U2FsdGVkX19IaGpojvFIyGtnj3c0hePBWRNyUWxeLNLHlKofWj pvNiW9IV9kxTTf Message-ID: <49EA0F51.3020404@gmx.net> Date: Sat, 18 Apr 2009 19:35:13 +0200 From: Daniel Thiele User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: Sam Leffler References: <20090417214339.GQ10728%slw@acropolis.ru> <49E9F782.6080201@freebsd.org> In-Reply-To: <49E9F782.6080201@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Cc: current@freebsd.org, Slawa Olhovchenkov Subject: Re: ath problem w/ WPA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 18:01:59 -0000 Sam Leffler wrote: > [...] > Known problem that was diagnosed recently on this list (or possibly > mobile@). wpa_supplicant is passing the kernel an unexpected key index. > You can check for the mailing list postings for more information as > noone has submitted a PR. > Slawa, in case you have not found if already by yourself, the posting Sam probably is refering to is: "Wireless connection (WPA-EAP) stops working after a while" from March 24 on this list. Sam, should we (Slawa and me) open a PR to gather all information on this issue in one place so that it will be readily available once you have (or someone else has) the time to look further into the problem? Best regards, Daniel From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 18:18: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 E6CA21065677 for ; Sat, 18 Apr 2009 18:18:15 +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 4EB2D8FC16 for ; Sat, 18 Apr 2009 18:18:14 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from sarevok.dnr.servegame.org (gate.lan.rachie.is-a-geek.net [192.168.2.10]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id BF87C7E818; Sat, 18 Apr 2009 10:18:13 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Sat, 18 Apr 2009 20:18:09 +0200 User-Agent: KMail/1.11.2 (FreeBSD/8.0-CURRENT; KDE/4.2.2; i386; ; ) References: <49E7BE78.6000802@freebsd.org> <200904181358.50806.mel.flynn+fbsd.current@mailing.thruhere.net> <20090418101702.18a4fcdf.wmoran@potentialtech.com> In-Reply-To: <20090418101702.18a4fcdf.wmoran@potentialtech.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904182018.11123.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Bill Moran Subject: Re: Weird warnings from lots of applications X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 18:18:52 -0000 On Saturday 18 April 2009 16:17:02 Bill Moran wrote: > Mel Flynn wrote: > > On Saturday 18 April 2009 01:49:56 Tim Kientzle wrote: > > > Igor R wrote: > > > >> "unexpected character `{', expected keyword - e.g. `style' > > > > > > > > Looks like GTK? > > > > > > I can't find this message in the gtk20 source anywhere. > > > > > > I actually ran grep over /usr/local/lib and the only > > > library that has all of these strings is libpython. > > > Of course, according to 'ldd', none of the programs > > > I've seen generating these warnings uses libpython. > > > > Sure they do. Just not via linking (fork or dlopen, didn't care to look). > > But, there's a run dep right here: > > # /stable/root/bin/finddep.php www/firefox lang/python26 > > /usr/ports/x11/xcb-proto: /usr/local/bin/python2.6 => > > /usr/ports/lang/python26 /usr/ports/x11/libxcb: /usr/local/bin/python2.6 > > => /usr/ports/lang/python26 /usr/ports/devel/glib20: > > /usr/local/bin/python2.6 => /usr/ports/lang/python26 > > That finddep.php seems to be a rather brilliant script. Couldn't find it > on the WWW anywhere ... are you keeping the code secret? Lol, no. I think I posted it on -questions once, either way, it's below. Been too lazy to use an option for "look for build deps too", so I switch comments on the respective lines. -- Mel #!/usr/local/bin/php -q \n"); echo("\tFind which dependancy lists dep in origin\n"); exit(1); } function chkdep($val, $check) { if( !is_dir($val) ) { fprintf(STDERR, "No such dir: %s/%s\n", $GLOBALS['PORTSDIR'], $val ); return; } chdir($val); $_deps = preg_split('/\s/', shell_exec("/usr/bin/make -V LIB_DEPENDS -V RUN_DEPENDS") //shell_exec("/usr/bin/make -V LIB_DEPENDS -V RUN_DEPENDS -V BUILD_DEPENDS") ); foreach($_deps AS $_dep) { list($pkgname, $origin) = explode(':', $_dep); if( preg_match('/^\s*$/', $origin) ) continue; if( in_array($origin, $GLOBALS['CHECKED']) ) continue; if( $origin == $GLOBALS['PORTSDIR'] . '/' . $check ) echo("$val: $pkgname => $origin\n"); else { if( defined('DEBUG') ) { fprintf(STDERR, "%s != %s/%s\n", $origin, $GLOBALS['PORTSDIR'], $check ); } $GLOBALS['CHECKED'][] = $origin; chkdep($origin, $check); } } } if( $argc < 3 ) usage(); $PORTSDIR=('' != getenv('PORTSDIR') ) ? getenv('PORTSDIR') : '/usr/ports'; $pkg = $argv[1]; $dep = $argv[2]; if(!file_exists("$PORTSDIR/$pkg/Makefile") ) { fprintf(STDERR, "Orphaned port: $pkg\n"); exit(2); } $CHECKED=array(); chkdep($PORTSDIR . '/' . $pkg, $dep); ?> From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 18:25: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 64BFB1065809 for ; Sat, 18 Apr 2009 18:25:35 +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 123D18FC50 for ; Sat, 18 Apr 2009 18:23:47 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-156-16-91.bna.bellsouth.net [70.156.16.91]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3IINggi044183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Apr 2009 14:23:42 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: deeptech71@gmail.com In-Reply-To: <49E93312.2090403@gmail.com> References: <49E6ACEE.6080301@gmail.com> <200904161116.58094.jhb@freebsd.org> <1239913234.1991.1.camel@balrog.2hip.net> <49E7FED0.9090708@gmail.com> <1239996517.24514.1.camel@balrog.2hip.net> <49E93312.2090403@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-xHlsAanDDlNtbMLIAScG" Organization: FreeBSD Date: Sat, 18 Apr 2009 13:22:37 -0500 Message-Id: <1240078957.3525.3.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 18:26:51 -0000 --=-xHlsAanDDlNtbMLIAScG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-04-18 at 03:55 +0200, deeptech71@gmail.com wrote: > Robert Noland wrote: > > On Fri, 2009-04-17 at 06:00 +0200, deeptech71@gmail.com wrote: > >> Robert Noland wrote: > >>> On Thu, 2009-04-16 at 11:16 -0400, John Baldwin wrote: > >>>> The drm code is doing a copyin() while holding a mutex (which is not= allowed). > >>> Ok, the quick and dirty fix for this is > >>> http://people.freebsd.org/~rnoland/drm_radeon_state-copyin-fix.patch > >>> > >>> I think there may be other places of concern though and a more proper > >>> fix is needed. > >> I still get the same lockup :( > >=20 > > It can't be the same backtrace though... I'll get a more complete patch > > put together shortly. >=20 > Wait do I need to do a make buildworld too? I only built a patched kernel= . No, you shouldn't need to buildworld, as long as everything was in sync to start with. robert. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-xHlsAanDDlNtbMLIAScG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknqGm0ACgkQM4TrQ4qfRON+kwCeOlXO11hPIu+Q9Ir5PqGkLnCE Xo4An0UIWz2Btv4oWo9534Pu4v718EaR =zUzW -----END PGP SIGNATURE----- --=-xHlsAanDDlNtbMLIAScG-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 20:54: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 16859106566C; Sat, 18 Apr 2009 20:54:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E6A8F8FC12; Sat, 18 Apr 2009 20:54:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 9E3C946B23; Sat, 18 Apr 2009 16:54:21 -0400 (EDT) Date: Sat, 18 Apr 2009 21:54:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: net@FreeBSD.org, current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: IFF_NEEDSGIANT now gone from 8.x (was: svn commit: r191253 - head/sys/net (fwd)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 20:54:22 -0000 Dear all: Just under four years ago, the non-MPSAFE network stack de-orbit burn schedule was announced, setting out a plan for eliminating remaining use of the Giant lock in the FreeBSD network stack. With the attached commit, that plan is now complete, and almost all of the network stack neither requires Giant nor runs with it. As always there are some loose ends, especially in IPv6, but with any luck those can be dealt with 8.0 also. Special thanks are due to the people who worked on and shepherded the last steps of this process -- especially Hans Petter Selasky, Alfred Perlstein, Andrew Thompson, Ed Schouten, and John Baldwin, who collectively bought our USB, tty, and other non-MPSAFE device driver stacks into a post-SMPng world. Thanks, Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Sat, 18 Apr 2009 20:39:18 +0000 (UTC) From: Robert Watson To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r191253 - head/sys/net Author: rwatson Date: Sat Apr 18 20:39:17 2009 New Revision: 191253 URL: http://svn.freebsd.org/changeset/base/191253 Log: Remove IFF_NEEDSGIANT interface flag: we no longer provide ifnet-layer infrastructure to support non-MPSAFE network device drivers. Modified: head/sys/net/if.h Modified: head/sys/net/if.h ============================================================================== --- head/sys/net/if.h Sat Apr 18 20:10:39 2009 (r191252) +++ head/sys/net/if.h Sat Apr 18 20:39:17 2009 (r191253) @@ -149,7 +149,6 @@ struct if_data { #define IFF_PPROMISC 0x20000 /* (n) user-requested promisc mode */ #define IFF_MONITOR 0x40000 /* (n) user-requested monitor mode */ #define IFF_STATICARP 0x80000 /* (n) static ARP */ -#define IFF_NEEDSGIANT 0x100000 /* (i) hold Giant over if_start calls */ /* * Old names for driver flags so that user space tools can continue to use @@ -163,8 +162,7 @@ struct if_data { /* flags set internally only: */ #define IFF_CANTCHANGE \ (IFF_BROADCAST|IFF_POINTOPOINT|IFF_DRV_RUNNING|IFF_DRV_OACTIVE|\ - IFF_SIMPLEX|IFF_MULTICAST|IFF_ALLMULTI|IFF_SMART|IFF_PROMISC|\ - IFF_NEEDSGIANT) + IFF_SIMPLEX|IFF_MULTICAST|IFF_ALLMULTI|IFF_SMART|IFF_PROMISC) /* * Values for if_link_state. From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 21:17:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77FA0106576E; Sat, 18 Apr 2009 21:17:04 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 001308FC13; Sat, 18 Apr 2009 21:17:03 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n3ILH0Dk003279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 18 Apr 2009 21:17:01 GMT (envelope-from ben@wanderview.com) Message-Id: <6535218D-6292-4F84-A8BA-FFA9B2E47F80@wanderview.com> From: Ben Kelly To: Alexander Leidinger In-Reply-To: <20090418094821.00002e67@unknown> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 18 Apr 2009 17:17:00 -0400 References: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> <20090418094821.00002e67@unknown> X-Mailer: Apple Mail (2.930.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: current@freebsd.org, fs@freebsd.org Subject: Re: ZFS: unlimited arc cache growth? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 21:17:04 -0000 On Apr 18, 2009, at 3:48 AM, Alexander Leidinger wrote: > On Fri, 17 Apr 2009 10:04:15 -0400 Ben Kelly > wrote: > I haven't tried killing pkgdb and looking at the stats, but on the > idle > machine (reboot after the panic and 5h of no use by me... the machine > fetches my mails, has a webmail + mysql + imap interface and is a > fileserver) the size is double of my max value. Again there's no real > load at this time, just fetching my mails (most traffic from the > FreeBSD lists) and a little bit of SpamAssassin filtering of them. > When > I logged in this morning the machine was rebooted about 5h ago by a > panic and no FS traffic was going on (100% idle). From looking at the code, its not too surprising it settles out at 2x your zfs_arc_max tunable. It looks like under normal conditions the arc_reclaim_thread only tries to evict buffers when the arc_size plus any ghost buffers is twice the value of arc_c: if (needfree || (2 * arc_c < arc_size + arc_mru_ghost->arcs_size + arc_mfu_ghost- >arcs_size)) arc_adjust(); (The needfree flag is only set when the system lowmem event is fired.) The arc_reclaim_thread checks this once a second. Perhaps this limit should be a tunable. Also, it might make sense to have a separate limit check for the ghost buffers. I was able to reproduce similar arc_size growth on my machine by running my rsync backup. After instrumenting the code it appeared that buffers were not being evicted because they were "indirect" and had been in the cache less than a second. The "indirect" flag is set based on the on-disk level field. When you see the arcstats.evict_skip sysctl going up this is probably what is happening. The comments in the code say this check is only for prefetch data, but it also triggers for indirect. I'm hesitant to make it really only affect prefetch buffers. Perhaps we could make the timeout a tunable or dynamic based on how far the cache is over its target. After the rsync completed my machine slowly evicts buffers until its back down to about twice arc_c. There was one case, however, where I saw it stop at about four times arc_c. In that case it was failing to evict buffers due to a missed lock. Its not clear yet if it was a buffer lock or hash lock. When this happens you'll see the arcstats.mutex_missed sysctl go up. I'm going to see if I can track down why this is occuring under idle conditions. That seems suspicious to me. Hope that helps. I'll let you know if I find anything else. - Ben From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 21:25: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 A30AD106566C; Sat, 18 Apr 2009 21:25:22 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6338FC25; Sat, 18 Apr 2009 21:25:21 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n3ILPHve003379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 18 Apr 2009 21:25:18 GMT (envelope-from ben@wanderview.com) Message-Id: <6FBF637A-6D96-4117-85C5-F205989DCCC1@wanderview.com> From: Ben Kelly To: =?ISO-8859-1?Q?Marius_N=FCnnerich?= In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 18 Apr 2009 17:25:17 -0400 References: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> <20090417141817.GR11551@cicely7.cicely.de> X-Mailer: Apple Mail (2.930.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: Alexander Leidinger , ticso@cicely.de, fs@freebsd.org, current@freebsd.org Subject: Re: ZFS: unlimited arc cache growth? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 21:25:22 -0000 On Apr 17, 2009, at 12:28 PM, Marius N=FCnnerich wrote: > On Fri, Apr 17, 2009 at 16:18, Bernd Walter =20 > wrote: >> On Fri, Apr 17, 2009 at 02:50:24PM +0200, Alexander Leidinger wrote: >>> Hi, >>> >>> to fs@, please CC me, as I'm not subscribed. >>> >>> I monitored (by hand) a while the sysctls =20 >>> kstat.zfs.misc.arcstats.size >>> and kstat.zfs.misc.arcstats.hdr_size. Both grow way higher (at some >>> point I've seen more than 500M) than what I have configured in >>> vfs.zfs.arc_max (40M). >> >> My understanding about this is the following: >> vfs.zfs.arc_min/max are not used as min max values. >> They are used as high/low watermarks. >> If arc is more than max the arc a thread is triggered to reduce the >> arc cache until min, but in the meantime other threads can still grow >> arc so there is a race between them. > > Hmm, if this is true the ARC size should go down to arc_min once it > did grow past arc_max and no new data is coming along but I do not > observe such a thing here. It simply stays near but below arc_max here > all the time. I have only /home on ZFS with moderate load. It appears arc_reclaim_thread only shrinks from arc_max when the =20 system vm_lowmem event is fired or more than 75% of max kmem is in use =20= by the system. If you want to make it try to shrink the arc all the time you could =20 try the patch below. This worked to reduce arc_c on my system, but it =20= was unable to reduce arc_size to match due to an apparent mutex miss. =20= I'm still trying to track that down. Hope that helps. - Ben Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.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/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c =20 (revision 205) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c =20 (working copy) @@ -1963,7 +1963,7 @@ if (needfree || (2 * arc_c < arc_size + arc_mru_ghost->arcs_size + arc_mfu_ghost-=20 >arcs_size)) - arc_adjust(); + arc_shrink(); if (arc_eviction_list !=3D NULL) arc_do_user_evicts();= From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 23:42:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D57B1065670 for ; Sat, 18 Apr 2009 23:42:11 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id C23ED8FC0C for ; Sat, 18 Apr 2009 23:42:10 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 08928245401 for ; Sun, 19 Apr 2009 00:42:13 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA for ; Sun, 19 Apr 2009 00:42:12 +0000 (GMT) Date: Sun, 19 Apr 2009 00:42:03 +0100 From: Bruce Cran To: current@freebsd.org Message-ID: <20090419004203.6a95382b@gluon.draftnet> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: panic when disconnecting cdce device just before powering off PC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Apr 2009 23:42:11 -0000 I'm running a fairly recent -current and got a panic when shutting down. I'd pressed the power button on my GTA02 and at about the same time had pressed the power button on my PC too. It seems the GTA02 CDCE device powered off first, just before FreeBSD was going to power off: Waiting (max 60 seconds) for system process 'vnlru' to stop...done Waiting (max 60 seconds) for system process 'bufdaemon' to stop...done Waiting (max 60 seconds) for system process 'syncer' to stop... Syncing disks, vnodes remaining...1 1 1 0 0 0 done All buffers synced. Uptime: 10h12m10s ugen3.2: at usbus3 (disconnected) cdce0: at uhub3, port 2, addr 2 (disconnected) Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x288 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80343d3e stack pointer = 0x28:0xfffffffe4001c8a0 frame pointer = 0x28:0xfffffffe4001c8c0 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 = 1 (init) [thread pid 1 tid 100002 ] Stopped at _mtx_lock_sleep+0x4e: movl 0x288(%rcx),%esi db> bt Tracing pid 1 tid 100002 td 0xffffff00014d7a80 _mtx_lock_sleep() at _mtx_lock_sleep+0x4e _sleep() at _sleep+0x232 usb2_proc_mwait() at usb2_proc_mwait+0x46 usb2_ether_ifshutdown() at usb2_ether_ifshutdown+0xaf cdce_shutdown() at cdce_shutdown+0x11 bus_generic_shutdown() at bus_generic_shutdown+0x1a bus_generic_shutdown() at bus_generic_shutdown+0x1a bus_generic_shutdown() at bus_generic_shutdown+0x1a bus_generic_shutdown() at bus_generic_shutdown+0x1a bus_generic_shutdown() at bus_generic_shutdown+0x1a bus_generic_shutdown() at bus_generic_shutdown+0x1a acpi_shutdown() at acpi_shutdown+0x9 bus_generic_shutdown() at bus_generic_shutdown+0x1a bus_generic_shutdown() at bus_generic_shutdown+0x1a root_bus_module_handler() at root_bus_module_handler+0x11b module_shutdown() at module_shutdown+0x84 boot() at boot+0x37b reboot() at reboot+0x46 syscall() at syscall+0x264 Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (55, FreeBSD ELF64, reboot), rip = 0x40897c, rsp = 0x7fffffffe738, rbp = 0x402420 --- -- Bruce Cran