From owner-freebsd-stable@FreeBSD.ORG Sun Feb 7 02:15:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 849BB1065679 for ; Sun, 7 Feb 2010 02:15:21 +0000 (UTC) (envelope-from heli@mikestammer.com) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 571A78FC13 for ; Sun, 7 Feb 2010 02:15:20 +0000 (UTC) Received: from vdsl-151-118-129-45.dnvr.qwest.net ([151.118.129.45] helo=mail.mikestammer.com) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.68) (envelope-from ) id 1NdwCa-00099q-MH; Sun, 07 Feb 2010 01:44:44 +0000 Received: from [192.168.0.225] (unknown [192.168.0.1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eric@mikestammer.com) by mail.mikestammer.com (Postfix) with ESMTPSA id AB360809; Sat, 6 Feb 2010 18:44:42 -0700 (MST) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 151.118.129.45 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19ukix/ax5JzB76pIYQeMH/8EavYLIiMHk= Message-ID: <4B6E1B10.5040702@mikestammer.com> Date: Sat, 06 Feb 2010 18:44:48 -0700 From: Eric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Nenhum_de_Nos References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: samba recplacement X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 02:15:21 -0000 On 2/5/2010 9:22 PM, Nenhum_de_Nos wrote: > hail, > > I've installed a recent 8-stable with gnome installed. I needed samba and > noticed I have samba4-devel installed. but I can't manage to make it a > simple file server as I need. so how to change samba package at minimum > harm ? > > do I need to reinstall all ? a simple make fetch in samba33 says I can't > as it conflicts with samba4 and some tbd-something (not in the machine > right now). > > is there easy way ? > > I'd really like to choose samba version ... I've found a thread in gnome@ > about this change (from late december). not a solution though. > > thanks, > > matheus > > pretty sure samba 4 is not stable yet. i played with it and it didnt work too well a few months ago. go back to the 3.x branch. thats easy to config. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 7 02:37:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31D88106566C for ; Sun, 7 Feb 2010 02:37:22 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-yx0-f188.google.com (mail-yx0-f188.google.com [209.85.210.188]) by mx1.freebsd.org (Postfix) with ESMTP id D7FD88FC14 for ; Sun, 7 Feb 2010 02:37:21 +0000 (UTC) Received: by yxe26 with SMTP id 26so4857824yxe.28 for ; Sat, 06 Feb 2010 18:37:21 -0800 (PST) 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=V0VCFo/FKnBgBpx7U27ch0sQZrVy0dBwSngl8nYSF4I=; b=OZh2QxVY1fZIhKe5M2aShFfpKrXIuHU1OaL1MxQ8dFNOgkdG6utiHyq8jKIJrge25H 45wHVibZanP2bgEV1Egr6cBz6BPeobeC2Klv5dukFs459E+kojrJ9960LlNuUu6ccVZb aJivw8/uy9TeOic9hhDcFvwt3lDOzJ9D/LwS8= 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=B9UAHSGoYejqunsZcBdHGq9RsoEF0Cy4gLGbg+IJr+3IKT4Slm8fMZYH41lF/lvLtg DSEZ+DLlIb4sBfJ8ng2SsnIZqFHXh2gA80jV9LB1b4a9Oql3j9j2HVq2WugDuHlUH1n/ OPMUSKPoxCH1a/v9Iryyh6GGcnvPeF/lmkRuI= Received: by 10.101.167.1 with SMTP id u1mr6206833ano.43.1265510241266; Sat, 06 Feb 2010 18:37:21 -0800 (PST) Received: from cygnus.homeunix.com ([189.71.106.77]) by mx.google.com with ESMTPS id 21sm952766yxe.55.2010.02.06.18.37.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Feb 2010 18:37:19 -0800 (PST) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id A03D3B8A1E; Sat, 6 Feb 2010 23:37:07 -0300 (BRT) Received: from 10.1.1.100 (SquirrelMail authenticated user matheus) by lamneth with HTTP; Sun, 7 Feb 2010 00:37:07 -0200 (BRST) Message-ID: <608eb94c1440af8e8822ec8ca1ce48ba.squirrel@lamneth> In-Reply-To: <4B6E1B10.5040702@mikestammer.com> References: <4B6E1B10.5040702@mikestammer.com> Date: Sun, 7 Feb 2010 00:37:07 -0200 (BRST) From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: samba recplacement X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 02:37:22 -0000 On Sat, February 6, 2010 23:44, Eric wrote: > On 2/5/2010 9:22 PM, Nenhum_de_Nos wrote: >> hail, >> >> I've installed a recent 8-stable with gnome installed. I needed samba >> and >> noticed I have samba4-devel installed. but I can't manage to make it a >> simple file server as I need. so how to change samba package at minimum >> harm ? >> >> do I need to reinstall all ? a simple make fetch in samba33 says I can't >> as it conflicts with samba4 and some tbd-something (not in the machine >> right now). >> >> is there easy way ? >> >> I'd really like to choose samba version ... I've found a thread in >> gnome@ >> about this change (from late december). not a solution though. >> >> thanks, >> >> matheus > > pretty sure samba 4 is not stable yet. i played with it and it didnt > work too well a few months ago. go back to the 3.x branch. thats easy to > config. I think this way too, the problem is how to do it in the least painful way. if I deinstall all samba stuff, gnome will fail to work ? matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Sun Feb 7 02:44:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98CF91065672 for ; Sun, 7 Feb 2010 02:44:02 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 657FF8FC08 for ; Sun, 7 Feb 2010 02:44:01 +0000 (UTC) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.3/8.14.3) with ESMTP id o172hjKp090395; Sat, 6 Feb 2010 20:43:46 -0600 (CST) (envelope-from stephen@missouri.edu) Message-ID: <4B6E28E1.7040904@missouri.edu> Date: Sat, 06 Feb 2010 20:43:45 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100131 Firefox MIME-Version: 1.0 To: Nenhum_de_Nos References: <4B6E1B10.5040702@mikestammer.com> <608eb94c1440af8e8822ec8ca1ce48ba.squirrel@lamneth> In-Reply-To: <608eb94c1440af8e8822ec8ca1ce48ba.squirrel@lamneth> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: samba recplacement X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 02:44:02 -0000 Nenhum_de_Nos wrote: > > On Sat, February 6, 2010 23:44, Eric wrote: >> On 2/5/2010 9:22 PM, Nenhum_de_Nos wrote: >>> hail, >>> >>> I've installed a recent 8-stable with gnome installed. I needed samba >>> and >>> noticed I have samba4-devel installed. but I can't manage to make it a >>> simple file server as I need. so how to change samba package at minimum >>> harm ? >>> >>> do I need to reinstall all ? a simple make fetch in samba33 says I can't >>> as it conflicts with samba4 and some tbd-something (not in the machine >>> right now). >>> >>> is there easy way ? >>> >>> I'd really like to choose samba version ... I've found a thread in >>> gnome@ >>> about this change (from late december). not a solution though. >>> >>> thanks, >>> >>> matheus >> >> pretty sure samba 4 is not stable yet. i played with it and it didnt >> work too well a few months ago. go back to the 3.x branch. thats easy to >> config. > > I think this way too, the problem is how to do it in the least painful > way. if I deinstall all samba stuff, gnome will fail to work ? > > matheus This is what I did: go to /usr/ports/x11/gnome2; do "make config"; deselect the MAPI option. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 7 02:54:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6093106566B for ; Sun, 7 Feb 2010 02:54:32 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-yx0-f188.google.com (mail-yx0-f188.google.com [209.85.210.188]) by mx1.freebsd.org (Postfix) with ESMTP id 87E248FC13 for ; Sun, 7 Feb 2010 02:54:32 +0000 (UTC) Received: by yxe26 with SMTP id 26so4863670yxe.28 for ; Sat, 06 Feb 2010 18:54:31 -0800 (PST) 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=cGtBOsclggOwgwBN24rctiZOjvRFPgc4QNZF9CLrDnQ=; b=vJz98lfLjaQi+b1MLHPngnZLTafQzic+qDEKTiNGPLnhTEOYCOnCWB4LPHOcB8W4S/ yQjjfzAlejTt0tAlJy8dLLx64PTgPUlzlU9A4kIptb3eEY7hpQgrT5WJpD9pDstJiYTM 4uUry7jBbzxCwMB+mt9MwEjla5LM2On3L773w= 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=HlpRgRjPumwu0x3uegBgpCF+4tOmFeQxBb3OrKz5K5SlsFzUF12KaXCy8U41L4NI+l M14BV8mLhf4MO0l6at+Rub8Vdsg2eUQvp2HiRCPldWtASyKS8Ai7EbWWLYI2IYtBxayT sGdwj0r/Qhs4D3ePt6x/hbWdXsSCuQP04OXWM= Received: by 10.101.3.4 with SMTP id f4mr2046419ani.10.1265511271747; Sat, 06 Feb 2010 18:54:31 -0800 (PST) Received: from cygnus.homeunix.com ([189.71.106.77]) by mx.google.com with ESMTPS id 5sm968131yxd.17.2010.02.06.18.54.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Feb 2010 18:54:30 -0800 (PST) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id ADAF1B8A1E; Sat, 6 Feb 2010 23:54:09 -0300 (BRT) Received: from 10.1.1.100 (SquirrelMail authenticated user matheus) by lamneth with HTTP; Sun, 7 Feb 2010 00:54:09 -0200 (BRST) Message-ID: <9fb57f2ae628227e5d75395c1d081e17.squirrel@lamneth> In-Reply-To: <4B6E28E1.7040904@missouri.edu> References: <4B6E1B10.5040702@mikestammer.com> <608eb94c1440af8e8822ec8ca1ce48ba.squirrel@lamneth> <4B6E28E1.7040904@missouri.edu> Date: Sun, 7 Feb 2010 00:54:09 -0200 (BRST) From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: samba recplacement X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 02:54:32 -0000 On Sun, February 7, 2010 00:43, Stephen Montgomery-Smith wrote: > Nenhum_de_Nos wrote: >> >> On Sat, February 6, 2010 23:44, Eric wrote: >>> On 2/5/2010 9:22 PM, Nenhum_de_Nos wrote: >>>> hail, >>>> >>>> I've installed a recent 8-stable with gnome installed. I needed samba >>>> and >>>> noticed I have samba4-devel installed. but I can't manage to make it a >>>> simple file server as I need. so how to change samba package at >>>> minimum >>>> harm ? >>>> >>>> do I need to reinstall all ? a simple make fetch in samba33 says I >>>> can't >>>> as it conflicts with samba4 and some tbd-something (not in the machine >>>> right now). >>>> >>>> is there easy way ? >>>> >>>> I'd really like to choose samba version ... I've found a thread in >>>> gnome@ >>>> about this change (from late december). not a solution though. >>>> >>>> thanks, >>>> >>>> matheus >>> >>> pretty sure samba 4 is not stable yet. i played with it and it didnt >>> work too well a few months ago. go back to the 3.x branch. thats easy >>> to >>> config. >> >> I think this way too, the problem is how to do it in the least painful >> way. if I deinstall all samba stuff, gnome will fail to work ? >> >> matheus > > This is what I did: > > go to /usr/ports/x11/gnome2; do "make config"; deselect the MAPI option. what I will loose in functionality ? I'd have to rebuild it all, right ? matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Sun Feb 7 03:00:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E7F41065672 for ; Sun, 7 Feb 2010 03:00:32 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from quasar.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8C59C8FC14 for ; Sun, 7 Feb 2010 03:00:31 +0000 (UTC) Received: from quasar.darkbsd.org (localhost [127.0.0.1]) by quasar.darkbsd.org (Postfix) with ESMTP id D3D11143E; Sun, 7 Feb 2010 03:44:33 +0100 (CET) Received: from quasar.darkbsd.org ([127.0.0.1]) by quasar.darkbsd.org (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8Ofn3fUFG2n; Sun, 7 Feb 2010 03:44:31 +0100 (CET) Received: from [192.168.3.42] (archer.yomi.darkbsd.org [192.168.3.42]) (Authenticated sender: darksoul) by quasar.darkbsd.org (Postfix) with ESMTPSA id 86A981437; Sun, 7 Feb 2010 03:44:29 +0100 (CET) Message-ID: <4B6E2921.60403@darkbsd.org> Date: Sun, 07 Feb 2010 11:44:49 +0900 From: Stephane LAPIE User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andriy Gapon References: <4B682972.6030604@darkbsd.org> <4B682F29.90505@icyb.net.ua> <4B686324.2090308@elischer.org> <4B68641D.9000201@icyb.net.ua> <4B695CA3.50008@darkbsd.org> <4B6B4E2E.2010902@icyb.net.ua> In-Reply-To: <4B6B4E2E.2010902@icyb.net.ua> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAD01E28EFD635FCFABC45B17" Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Julian Elischer , freebsd-hardware@freebsd.org Subject: Re: [zfs][hardware] Reproducible kernel panic in 8.0-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 03:00:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAD01E28EFD635FCFABC45B17 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 03/02/2010 13:23 Stephane LAPIE said the following: >> I just rebuilt a kernel with debugger options, and obtained the >> following output upon pulling out one disk : >> >> Sleeping thread (tid 100024, pid 0) owns a non-sleepable lock >> sched_switch() at sched_switch+0xf8 >> mi_switch() at mi_switch+0x16f >> sleepq_timedwait() at sleepq_timedwait+0x42 >> _cv_timedwait() at _cv_timedwait+0x129 >> _sema_timedwait() at _sema_timedwait+0x55 >> ata_queue_request() at ata_queue_request+0x526 >> ata_controlcmd() at ata_controlcmd+0xa1 >> ata_setmode() at ata_setmode+0xdc >> ad_init() at ad_init+0x27 >> ad_reinit() at ad_reinit+0x48 >> ata_reinit() at ata_reinit+0x268 >> ata_conn_event() at ata_conn_event+0x49 >> taskqueue_run() at taskqueue_run+0x93 >> taskqueue_thread_loop() at taskqueue_thread_loop+0x46 >> fork_exit() at fork_exit+0x118 >> fork_trampoline() at fork_trampoline+0xe >> --- trap 0, rip =3D 0, rsp =3D 0xffffff80000aad30, rbp =3D 0 --- >> panic: sleeping thread >> cpuid =3D 2 >> KDB: enter: panic >> [thread pid 12 tid 100008 ] >> Stopped at kdb_enter+0x3d: movq $0,0x4943d0(%rip) >=20 > Not sure if I can derive anything useful from here. > Someone with more expertise is needed. > One thing I noticed is that ata_conn_event and ata_reinit and some othe= r > functions up the stack acquire state_mtx recursively, but the mutex is = not > initialized with MTX_RECURSE. >=20 > Perhaps, indeed you would have a better luck with AHCI controller _and_= ahci(4) > driver. It seems to handle dynamic coming and going of disks much bett= er than > ata(4). I just moved half of the "flaky" drives on an AHCI controller. This seems to work much better, starting with disk detection issues=20 being solved, and hotplug working exactly like SCSI does. It does=20 require using camcontrol to recognize the disks again, but that much is=20 not exactly a problem. Although I'm probably dreaming : Did anyone heard about AHCI controllers = beside the on-board ones ? Thanks to everyone for their advice. --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enigAD01E28EFD635FCFABC45B17 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 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktuKSQACgkQ24Ql8u6TF2Mi0wCeMGhdcjKdsyf7TBUyBF1L2n/4 WH8Anjbf3lVlT2hX7D8dABVqck5WAdPv =DwuS -----END PGP SIGNATURE----- --------------enigAD01E28EFD635FCFABC45B17-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 7 03:02:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFD1E1065694 for ; Sun, 7 Feb 2010 03:02:19 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 36F108FC14 for ; Sun, 7 Feb 2010 03:02:18 +0000 (UTC) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.3/8.14.3) with ESMTP id o1732BvT090524; Sat, 6 Feb 2010 21:02:12 -0600 (CST) (envelope-from stephen@missouri.edu) Message-ID: <4B6E2D33.3050802@missouri.edu> Date: Sat, 06 Feb 2010 21:02:11 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100131 Firefox MIME-Version: 1.0 To: Nenhum_de_Nos References: <4B6E1B10.5040702@mikestammer.com><608eb94c1440af8e8822ec8ca1ce48ba.squirrel@lamneth><4B6E28E1.7040904@missouri.edu> <9fb57f2ae628227e5d75395c1d081e17.squirrel@lamneth> In-Reply-To: <9fb57f2ae628227e5d75395c1d081e17.squirrel@lamneth> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: samba recplacement X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 03:02:20 -0000 Nenhum_de_Nos wrote: > > On Sun, February 7, 2010 00:43, Stephen Montgomery-Smith wrote: >> Nenhum_de_Nos wrote: >>> >>> On Sat, February 6, 2010 23:44, Eric wrote: >>>> On 2/5/2010 9:22 PM, Nenhum_de_Nos wrote: >>>>> hail, >>>>> >>>>> I've installed a recent 8-stable with gnome installed. I needed samba >>>>> and >>>>> noticed I have samba4-devel installed. but I can't manage to make it a >>>>> simple file server as I need. so how to change samba package at >>>>> minimum >>>>> harm ? >>>>> >>>>> do I need to reinstall all ? a simple make fetch in samba33 says I >>>>> can't >>>>> as it conflicts with samba4 and some tbd-something (not in the machine >>>>> right now). >>>>> >>>>> is there easy way ? >>>>> >>>>> I'd really like to choose samba version ... I've found a thread in >>>>> gnome@ >>>>> about this change (from late december). not a solution though. >>>>> >>>>> thanks, >>>>> >>>>> matheus >>>> >>>> pretty sure samba 4 is not stable yet. i played with it and it didnt >>>> work too well a few months ago. go back to the 3.x branch. thats easy >>>> to >>>> config. >>> >>> I think this way too, the problem is how to do it in the least painful >>> way. if I deinstall all samba stuff, gnome will fail to work ? >>> >>> matheus >> >> This is what I did: >> >> go to /usr/ports/x11/gnome2; do "make config"; deselect the MAPI option. > > what I will loose in functionality ? I don't know. Some functions related to the mail client "evolution." > I'd have to rebuild it all, right ? I think if you just delete samba4-devel and its dependencies, then you can rebuild from there. > > matheus > From owner-freebsd-stable@FreeBSD.ORG Sun Feb 7 03:24:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D56731065692 for ; Sun, 7 Feb 2010 03:24:28 +0000 (UTC) (envelope-from adam.hawes@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 6515B8FC1B for ; Sun, 7 Feb 2010 03:24:28 +0000 (UTC) Received: by pxi13 with SMTP id 13so2571784pxi.3 for ; Sat, 06 Feb 2010 19:24:28 -0800 (PST) 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=dm5VJdKFJDYujxrrQLpdHbWSR422vK3x6I/FsArzRxE=; b=ohaVvUmM9E+P27Naym1mU+ssVER7VDqSifKD3jV/e9P6LaW8KByrxrjXekT+1sBo6o E7oRnTNa347o3BZKfpip8a4YUU+De/ZQG5HEJbME9CRDN9O6zMqW+O+W0G8pv7EqENjW 7TrV/6Ui3ihNZALoZxUMvqzPz15iqP5S27YbI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=k46tcMetzDVQ65/jPbMvKefwugRcUT7d7kG4gSmOwNyRpZjZKryc2kKzJP66khVoxN gMA3FkcYEmEnGzQAIbLw7+CB62ykH5mViEpMlwa8sM1hns91kw+Sj+ExZgc699fH98+7 WkldAlYSl3jvHZChlIJXEdKFaMGR+4Udzh228= MIME-Version: 1.0 Received: by 10.142.201.14 with SMTP id y14mr1777980wff.95.1265511638271; Sat, 06 Feb 2010 19:00:38 -0800 (PST) Date: Sun, 7 Feb 2010 13:30:38 +1030 Message-ID: <10ce4a5e1002061900y73ad6678wab020fbca7d5227a@mail.gmail.com> From: Adam Hawes To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Promise SX8 SATA controller on FreeBSD8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 03:24:28 -0000 Hi, I am at an end. I can't find anything about this device on FreeBSD; searching for it on Google or the FreeBSD site only provides few hits. Is the SX8 controller supported? I have a server with one and 6 disks that I'd really like to be running FreeBSD 8.0 on with ZFS. The device is detected by the the system boot, and it is detected by BSD, but no driver is assigned. Is there a driver in FreeBSD 8.0 i386 that supports it? Thanks A From owner-freebsd-stable@FreeBSD.ORG Sun Feb 7 03:34:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 725E7106566B for ; Sun, 7 Feb 2010 03:34:36 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id CF77E8FC12 for ; Sun, 7 Feb 2010 03:34:34 +0000 (UTC) Received: by gxk10 with SMTP id 10so1544960gxk.3 for ; Sat, 06 Feb 2010 19:34:32 -0800 (PST) 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=xMfPaXwxTVtE0tT3YmEJ8/QQT2Gr44HnJvsNoOTjPHA=; b=UI/X+ldEc2/e0GeDjERJ2YflbPH6CG5HZNtu3T6kAxYqmjYCeMQlRAx5pJJJza076O 4Bzta9ooSapCe9PtlFEGT+Lb8QNhhNsf+a4iXXcTQ2lCxvFn5YprcWP6fsC7fFFTpQ1N F02IPQHJFneTv7X7fDHQKac3gf9KDAulW6qRs= 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=S65ifdzMWWsPjKTrqObbXPNj8tcGruvuPVglzliMIWI4Sq2MpZhheNjWbzsLErPp7E 8a5qV1N4VuKoYOjau0WlzDXDlKAHDCQ0JwhpeS4wzfLZmM25DLCbkgAi78J8sFA/b8Q7 aK2DtDj8AuhEFCxolN1J/fgHyoB8NinJkASpI= Received: by 10.150.55.27 with SMTP id d27mr6731429yba.124.1265513662993; Sat, 06 Feb 2010 19:34:22 -0800 (PST) Received: from cygnus.homeunix.com ([189.71.106.77]) by mx.google.com with ESMTPS id 15sm978523yxh.4.2010.02.06.19.34.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Feb 2010 19:34:21 -0800 (PST) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id DDA7CB8A1E; Sun, 7 Feb 2010 00:34:12 -0300 (BRT) Received: from 10.1.1.100 (SquirrelMail authenticated user matheus) by lamneth with HTTP; Sun, 7 Feb 2010 01:34:12 -0200 (BRST) Message-ID: <1a62d80a863bb5d210d3f43f3cf14be2.squirrel@lamneth> In-Reply-To: <4B6E2D33.3050802@missouri.edu> References: <4B6E1B10.5040702@mikestammer.com><608eb94c1440af8e8822ec8ca1ce48ba.squirrel@lamneth><4B6E28E1.7040904@missouri.edu> <9fb57f2ae628227e5d75395c1d081e17.squirrel@lamneth> <4B6E2D33.3050802@missouri.edu> Date: Sun, 7 Feb 2010 01:34:12 -0200 (BRST) From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: samba recplacement X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 03:34:36 -0000 On Sun, February 7, 2010 01:02, Stephen Montgomery-Smith wrote: > Nenhum_de_Nos wrote: >> >> On Sun, February 7, 2010 00:43, Stephen Montgomery-Smith wrote: >>> Nenhum_de_Nos wrote: >>>> >>>> On Sat, February 6, 2010 23:44, Eric wrote: >>>>> On 2/5/2010 9:22 PM, Nenhum_de_Nos wrote: >>>>>> hail, >>>>>> >>>>>> I've installed a recent 8-stable with gnome installed. I needed >>>>>> samba >>>>>> and >>>>>> noticed I have samba4-devel installed. but I can't manage to make it >>>>>> a >>>>>> simple file server as I need. so how to change samba package at >>>>>> minimum >>>>>> harm ? >>>>>> >>>>>> do I need to reinstall all ? a simple make fetch in samba33 says I >>>>>> can't >>>>>> as it conflicts with samba4 and some tbd-something (not in the >>>>>> machine >>>>>> right now). >>>>>> >>>>>> is there easy way ? >>>>>> >>>>>> I'd really like to choose samba version ... I've found a thread in >>>>>> gnome@ >>>>>> about this change (from late december). not a solution though. >>>>>> >>>>>> thanks, >>>>>> >>>>>> matheus >>>>> >>>>> pretty sure samba 4 is not stable yet. i played with it and it didnt >>>>> work too well a few months ago. go back to the 3.x branch. thats easy >>>>> to >>>>> config. >>>> >>>> I think this way too, the problem is how to do it in the least painful >>>> way. if I deinstall all samba stuff, gnome will fail to work ? >>>> >>>> matheus >>> >>> This is what I did: >>> >>> go to /usr/ports/x11/gnome2; do "make config"; deselect the MAPI >>> option. >> >> what I will loose in functionality ? > > I don't know. Some functions related to the mail client "evolution." if just evolution is affected, no problem for me. >> I'd have to rebuild it all, right ? > > I think if you just delete samba4-devel and its dependencies, then you > can rebuild from there. yeah ... I'll need to rebuild ... but I need samba3 for filesharing purposes :) thanks, maheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Sun Feb 7 03:36:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BEBE1065692 for ; Sun, 7 Feb 2010 03:36:22 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1E98FC15 for ; Sun, 7 Feb 2010 03:36:21 +0000 (UTC) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.3/8.14.3) with ESMTP id o173aH9f090658; Sat, 6 Feb 2010 21:36:18 -0600 (CST) (envelope-from stephen@missouri.edu) Message-ID: <4B6E3531.9040108@missouri.edu> Date: Sat, 06 Feb 2010 21:36:17 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100131 Firefox MIME-Version: 1.0 To: Nenhum_de_Nos References: <4B6E1B10.5040702@mikestammer.com><608eb94c1440af8e8822ec8ca1ce48ba.squirrel@lamneth><4B6E28E1.7040904@missouri.edu><9fb57f2ae628227e5d75395c1d081e17.squirrel@lamneth><4B6E2D33.3050802@missouri.edu> <1a62d80a863bb5d210d3f43f3cf14be2.squirrel@lamneth> In-Reply-To: <1a62d80a863bb5d210d3f43f3cf14be2.squirrel@lamneth> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: samba recplacement X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 03:36:22 -0000 Nenhum_de_Nos wrote: > > On Sun, February 7, 2010 01:02, Stephen Montgomery-Smith wrote: >> Nenhum_de_Nos wrote: >>> >>> On Sun, February 7, 2010 00:43, Stephen Montgomery-Smith wrote: >>>> Nenhum_de_Nos wrote: >>>>> >>>>> On Sat, February 6, 2010 23:44, Eric wrote: >>>>>> On 2/5/2010 9:22 PM, Nenhum_de_Nos wrote: >>>>>>> hail, >>>>>>> >>>>>>> I've installed a recent 8-stable with gnome installed. I needed >>>>>>> samba >>>>>>> and >>>>>>> noticed I have samba4-devel installed. but I can't manage to make it >>>>>>> a >>>>>>> simple file server as I need. so how to change samba package at >>>>>>> minimum >>>>>>> harm ? >>>>>>> >>>>>>> do I need to reinstall all ? a simple make fetch in samba33 says I >>>>>>> can't >>>>>>> as it conflicts with samba4 and some tbd-something (not in the >>>>>>> machine >>>>>>> right now). >>>>>>> >>>>>>> is there easy way ? >>>>>>> >>>>>>> I'd really like to choose samba version ... I've found a thread in >>>>>>> gnome@ >>>>>>> about this change (from late december). not a solution though. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> matheus >>>>>> >>>>>> pretty sure samba 4 is not stable yet. i played with it and it didnt >>>>>> work too well a few months ago. go back to the 3.x branch. thats easy >>>>>> to >>>>>> config. >>>>> >>>>> I think this way too, the problem is how to do it in the least painful >>>>> way. if I deinstall all samba stuff, gnome will fail to work ? >>>>> >>>>> matheus >>>> >>>> This is what I did: >>>> >>>> go to /usr/ports/x11/gnome2; do "make config"; deselect the MAPI >>>> option. >>> >>> what I will loose in functionality ? >> >> I don't know. Some functions related to the mail client "evolution." > > if just evolution is affected, no problem for me. > >>> I'd have to rebuild it all, right ? >> >> I think if you just delete samba4-devel and its dependencies, then you >> can rebuild from there. > > yeah ... I'll need to rebuild ... > > but I need samba3 for filesharing purposes :) And you can install samba3 separately, just like I did. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 7 15:36:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDD09106566B for ; Sun, 7 Feb 2010 15:36:44 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 7BEBE8FC19 for ; Sun, 7 Feb 2010 15:36:44 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KXH0046LA0VBEF0@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 07 Feb 2010 16:36:31 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KXH00LH5A0VO510@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 07 Feb 2010 16:36:31 +0100 (CET) Date: Sun, 07 Feb 2010 16:36:31 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100207163631.da7205fc.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> References: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: panic - sleeping thread on FreeBSD 8.0-stable / amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 15:36:44 -0000 On Sun, 31 Jan 2010 17:56:39 +0100 Torfinn Ingolfsen wrote: > On Sun, 31 Jan 2010 14:42:17 +0100 > Torfinn Ingolfsen wrote: > > > Hi, > > > > One of my machines had a panic or something. > > The machine was pingable, but I couldn't ssh into it, and there was no response on the console. > > > > And it did it again, only a few hours later. I'll try to update to latest -stable, and see if that helps. > Same messgae as last time, unfortunately I didn't record tge details (tid and pid). Oh well. Well, it was stable for many days, but today it rebooted on its ownb again. After the fact, I see this in /var/log/messages: Feb 7 11:50:16 kg-f2 ntpd[906]: time reset +2.376096 s Feb 7 12:02:21 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f Feb 7 12:02:21 kg-f2 kernel: ata6: hardware reset timeout Feb 7 12:05:43 kg-f2 syslogd: kernel boot file is /boot/kernel/kernel So there is probably some problem with a cable or disk. On the plus side, it did reboot and came upa agin without any issues. -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sun Feb 7 17:55:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA806106566B for ; Sun, 7 Feb 2010 17:55:49 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 7BBDB8FC08 for ; Sun, 7 Feb 2010 17:55:49 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o17HtkkF015675 for ; Sun, 7 Feb 2010 18:55:47 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 5943D24 for ; Sun, 7 Feb 2010 18:55:46 +0100 (CET) Date: Sun, 7 Feb 2010 18:55:45 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-stable@freebsd.org Message-Id: <20100207185545.e29108dc.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.7.174544 Subject: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 17:55:50 -0000 Hi all, After being disturbed by the firmware issues of the wd drives causing exceeding load cycles (see thread "immense delayed write to file system (ZFS and UFS2), performance issues" in January), I have found some more problematic drives in the following setup: 4 x 2.5" WDC WD4000BEVT-00ZAT0 in RAIDZ1 configuration attached to a Supermicro SAS controller: mpt0@pci0:2:0:0: class=0x010000 card=0xa38015d9 chip=0x00581000 rev=0x08 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'SAS 3000 series, 8-port with 1068E -StorPort' class = mass storage subclass = SCSI luna# camcontrol devlist at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 1 lun 0 (pass1,da1) at scbus0 target 2 lun 0 (pass2,da2) at scbus0 target 3 lun 0 (pass3,da3) The disks appear to load/unload every 10s or so if I do not artificially keep them busy. Does anyone here have a suggestion how to make this interval longer or even turn off the unload feature completely? I tried luna# camcontrol idle da0 -t 600 (pass0:mpt0:0:0:0): CMD: IDLE: e3 00 00 00 00 40 00 00 00 00 78 00 (pass0:mpt0:0:0:0): CAM Status: CCB request was invalid luna# camcontrol standby da0 -t 600 (pass0:mpt0:0:0:0): CMD: STANDBY: e2 00 00 00 00 40 00 00 00 00 78 00 (pass0:mpt0:0:0:0): CAM Status: CCB request was invalid >From /usr/share/misc/scsi_modes I gather that page 26 should contain power control features, but no avail: luna# camcontrol modepage da0 -m 26 camcontrol: error sending mode sense command Any further ideas how to get rid of this "feature"? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Sun Feb 7 20:57:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8385C106568B for ; Sun, 7 Feb 2010 20:57:27 +0000 (UTC) (envelope-from alan.bryan@yahoo.com) Received: from web50505.mail.re2.yahoo.com (web50505.mail.re2.yahoo.com [206.190.38.81]) by mx1.freebsd.org (Postfix) with SMTP id 280AC8FC22 for ; Sun, 7 Feb 2010 20:57:27 +0000 (UTC) Received: (qmail 57358 invoked by uid 60001); 7 Feb 2010 20:57:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1265576246; bh=hzoL+ecvMB6FfZZsEUWE/+0mVjeJzL5wIAaLgghskso=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Tzg95G08QsXzD39dr/mGHqGLsVuatlN5Nl43CfL0L30STfVnVf1FDh5LMBBPmGhYVcQ7ea+76s0Asbl6EQxcqdLOlD7tm6n2TBqJBcVjD5Hw7eSs+xKsGQFtoDsmkOC5DmdsH2ZybBkS9XdVeux6AO0tLP4dCCuUtX7i+E38zxg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Q6C1FzzzYEMKBgsCd8rjOnr9lRpRfvho73PjUv4PDOkYYygFzhxYd2lE3Jtje5HQeXnyFt1OQds1Tnbmee+jiKVfQWmazf4Vs7bdy4g0NBpvwuAzRNFs040DGxbXD/My/r68e6oYhHTcmjYq3szITw7ORvCVvZkxG6jv7BwZo1Y=; Message-ID: <636471.56837.qm@web50505.mail.re2.yahoo.com> X-YMail-OSG: OEtLrogVM1lTpcz.tjO1kIgm5_Jbw9tT8ehoPJtXxySVuY8Gde69sCXbZQx08W4wh_vKjlLUo1n14ULfVc6nvq3zbSmN_dyEWWIDCL4ovmqLjc4hfNfkJJyPMzxPRLwxOuY7EpNNM788.ADr_PeB7Lsq.hVfirsjPlbnRfWA7Yqq9.IXuO3xkYwFVoWw3xMVzqnR_6Uz0hB_ea5LQnV.UMtocTaDqKnCCE5QONRfitAXMm0uZnhbSKvUksoiFienKagDob2Ag425df8C9my3q1uDvBtcI8QG2D3c3ytqqOnPc5K8TgmEQBdhpDoyMvOOOW0Y_hTlAL6bJTxIHtwylneQMK0SRx6v2ySYVfwGY8vuu8h4_IeP0H8K8w-- Received: from [68.4.245.43] by web50505.mail.re2.yahoo.com via HTTP; Sun, 07 Feb 2010 12:57:26 PST X-Mailer: YahooMailClassic/9.1.10 YahooMailWebService/0.8.100.260964 Date: Sun, 7 Feb 2010 12:57:26 -0800 (PST) From: alan bryan To: Rick Macklem In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: Zombie NFS writing from FreeBSD clients to FreeBSD 8.0 server with ZFS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 20:57:27 -0000 --- On Wed, 2/3/10, Rick Macklem wrote: > From: Rick Macklem > Subject: Re: Zombie NFS writing from FreeBSD clients to FreeBSD 8.0 server with ZFS > To: "alan bryan" > Date: Wednesday, February 3, 2010, 8:02 AM > > > On Tue, 2 Feb 2010, alan bryan wrote: > > > I've tried different network driver igb->em, > UDP->TCP for NFS, enabling NFS locking on the > server/clients (lockd, statd). > > > I'm out of ideas so hoping this tcpdump sheds light on > how it's getting stuck in this loop. > > You could try the experimental server, just to see if that > has any effect. > Either set nfsv4_server_enable="YES" or add "-e" to both > nfs_server_flags > and mountd_flags. > > Note that the server will handle NFSv3, so you don't need > to use NFSv4 > mounts. > > rick > Thanks - I might give that a try. This was only initially happening on our production stack which made it difficult to try things to troubleshoot. I've since been able to get it to happen on our dev stack too. Basically - I have about 70 mounts from the clients. 70 or so separate ZFS filesystems each exported via sharenfs. This appears to work well at first. After some traffic and some time (less than a day) the zombie writes start occuring. So, on dev we enabled dtrace (not at all familiar with it unfortunately) and tried to get this to happen. When it did happen we could see some patterns to the calls which matches up to the repeating conversations witnessed in the tcpdumps. zpool iostat when this is occuring is showing nothing being written to the disks. So, it appears that the client is requesting a write, NFS takes the request, asks ZFS which is replying with some error (from it's cache?) and then back to the client again. So, I'm starting to lean to this being more of a ZFS issue than an NFS one but I'm still not sure. We've read the recommendations about disabling the ZIL for ZFS/NFS and that sounds a bit scary. We've bought some Intel X25-E SSDs to mirror for a log device to add to the pool instead to see if that makes any sort of difference. (the thinking here is that this is now appearing like it might be a ZFS issue and that the speed of the SSDs plus the different code path in dealing with a dedicated log device might help us avoid the issue). So, if the SSDs don't change the behavior I may give the experimental NFS server a try to see if it helps. Thanks, Alan From owner-freebsd-stable@FreeBSD.ORG Sun Feb 7 21:56:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18020106568D for ; Sun, 7 Feb 2010 21:56:29 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 92A9E8FC0C for ; Sun, 7 Feb 2010 21:56:28 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o17LuGGW023649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 08:56:18 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o17LuGYV004612; Mon, 8 Feb 2010 08:56:16 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o17LuF82004611; Mon, 8 Feb 2010 08:56:15 +1100 (EST) (envelope-from peter) Date: Mon, 8 Feb 2010 08:56:15 +1100 From: Peter Jeremy To: Pascal Stumpf Message-ID: <20100207215615.GB4536@server.vk2pj.dyndns.org> References: <4B696D0B.3070301@minibofh.org> <201002061211.09140.Pascal.Stumpf@cubes.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZoaI/ZTpAVc4A5k6" Content-Disposition: inline In-Reply-To: <201002061211.09140.Pascal.Stumpf@cubes.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Inmutable bit in some binaries X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 21:56:29 -0000 --ZoaI/ZTpAVc4A5k6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-06 12:11:08 +0100, Pascal Stumpf wrote: >just another idea: You may want to take a look at integrity checking syste= ms=20 >as an alternative, i.e. tripwire. Note that mtree(8) supports the integrity checking functionality of tripwire and is in the base system. (It doesn't have all the bells and whistles of tripwire and so isn't suitable for all cases). If you do go for an integrity checking system, remember to ensure that everything that your integrity checking system relies on (ie executable, database, shared libraries) is immutable - as well as the shell/cron that runs it and however the results are reported. --=20 Peter Jeremy --ZoaI/ZTpAVc4A5k6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktvNv8ACgkQ/opHv/APuIf4lACgti1+C+vvmXkTwSts3tsEjICG dxMAoLGnXexBhms1+YrB9/2YyuHGUStR =sEqZ -----END PGP SIGNATURE----- --ZoaI/ZTpAVc4A5k6-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 7 22:22:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DBE81065670; Sun, 7 Feb 2010 22:22:58 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 59FCE8FC13; Sun, 7 Feb 2010 22:22:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANfLbkuDaFvH/2dsb2JhbADVH4RUBA X-IronPort-AV: E=Sophos;i="4.49,423,1262581200"; d="scan'208";a="64577006" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 07 Feb 2010 17:22:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id F136D1084121; Sun, 7 Feb 2010 17:22:55 -0500 (EST) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh4RZXqNRpIz; Sun, 7 Feb 2010 17:22:54 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id AEE4B108423C; Sun, 7 Feb 2010 17:22:54 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o17MY9I07955; Sun, 7 Feb 2010 17:34:09 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sun, 7 Feb 2010 17:34:08 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: George Mamalakis In-Reply-To: <4B6D3A18.2030304@eng.auth.gr> Message-ID: References: <4B6BE7A2.6000402@eng.auth.gr> <4B6D3A18.2030304@eng.auth.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: Kerberized NFSv3 incorrect behavior X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 22:22:58 -0000 On Sat, 6 Feb 2010, George Mamalakis wrote: > > thank you for all your answers. I am planning on setting up the computer labs > of my department using kerberized nfsv3 (since v4 seems to be "more" > experimental) with a FreeBSD nfs server and Linux nfs clients. I was > wondering "how stable" such an implementation would be; meaning that I > wouldn't want to end up with an unstsable setup when receiving requests from > 50-60 simultaneous clients, because that would be my everyday scenario. > I believe that the above should be stable, but your mileage may vary, as they say. The main issue will be what your TGT lifetime will be, since client access to the server will normally stop when the TGT expires. Some systems (Mac OS X) will automagically renew the TGT before it expires, if your KDC allows that. I don't think most/all Linux systems do this by default, but there are some utilities out there (try a search for krenew) that will do so. Basically, I think you'll want to avoid TGTs expiring before the user logs out. You also need a unique uid<->user principal mapping for all users logging in. You definitely want to do some testing with whatever Linux system you are using for the client. Good luck with it, rick ps: Choosing nfsv3 vs nfsv4 is basically independent of using RPCSEC_GSS except for the host based initiator credential needed by some clients (Linux and Solaris10 are among those) for NFSv4. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 05:01:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9C5A106566B for ; Mon, 8 Feb 2010 05:01:02 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id A0E578FC17 for ; Mon, 8 Feb 2010 05:01:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id DC2B7508A8 for ; Mon, 8 Feb 2010 05:01:01 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB2+adEfKxkl for ; Mon, 8 Feb 2010 05:01:00 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id E21D050830 for ; Mon, 8 Feb 2010 05:01:00 +0000 (GMT) Message-ID: <4B6F9A8D.4050907@langille.org> Date: Mon, 08 Feb 2010 00:01:01 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 05:01:02 -0000 Hi, I'm looking at creating a large home use storage machine. Budget is a concern, but size and reliability are also a priority. Noise is also a concern, since this will be at home, in the basement. That, and cost, pretty much rules out a commercial case, such as a 3U case. It would be nice, but it greatly inflates the budget. This pretty much restricts me to a tower case. The primary use of this machine will be a backup server[1]. It will do other secondary use will include minor tasks such as samba, CIFS, cvsup, etc. I'm thinking of 8x1TB (or larger) SATA drives. I've found a case[2] with hot-swap bays[3], that seems interesting. I haven't looked at power supplies, but given that number of drives, I expect something beefy with a decent reputation is called for. Whether I use hardware or software RAID is undecided. I I think I am leaning towards software RAID, probably ZFS under FreeBSD 8.x but I'm open to hardware RAID but I think the cost won't justify it given ZFS. Given that, what motherboard and RAM configuration would you recommend to work with FreeBSD [and probably ZFS]. The lists seems to indicate that more RAM is better with ZFS. Thanks. [1] - FYI running Bacula, but that's out of scope for this question [2] - http://www.newegg.com/Product/Product.aspx?Item=N82E16811192058 [3] - nice to have, especially for a failure. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 05:27:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E1FD106566C for ; Mon, 8 Feb 2010 05:27:02 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7A4428FC14 for ; Mon, 8 Feb 2010 05:27:00 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o185QvsC056285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 8 Feb 2010 15:56:57 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Mon, 8 Feb 2010 15:56:46 +1030 User-Agent: KMail/1.9.10 References: <4B6F9A8D.4050907@langille.org> In-Reply-To: <4B6F9A8D.4050907@langille.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1276947.7vxR9E8l1F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002081556.54782.doconnor@gsoft.com.au> X-Spam-Score: -3.641 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 05:27:02 -0000 --nextPart1276947.7vxR9E8l1F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 8 Feb 2010, Dan Langille wrote: > Given that, what motherboard and RAM configuration would you > recommend to work with FreeBSD [and probably ZFS]. =A0The lists seems > to indicate that more RAM is better with ZFS. I have something similar (5x1Tb) - I have a Gigabyte GA-MA785GM-US2H=20 with an Athlon X2 and 4Gb of RAM (only half filled - 2x2Gb) The board has 5 SATA ports + 1 eSATA (I looped that back into the case=20 to connect to the DVD drive :). I boot it off a 4Gb CF card in an IDE adapter. I think you could boot=20 off ZFS but it seemed a bit unreliable when I installed it so I opted=20 for a more straightforward method. The CPU fan is fairly quiet (although a 3rd party one would probably be=20 quieter) and the rest of the motherboard is fanless. The onboard video works great with radeonhd (it's a workstation for=20 someone as well as a file server). Note that it doesn't support ECC, I don't know if that is a problem. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1276947.7vxR9E8l1F Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLb6Ce5ZPcIHs/zowRAoXCAJ9ExdsaXReQJbHHDpWBZ57KM8fuXQCdGeKI W/BMdwQgYKeqCvD23Dz+bSA= =Q72s -----END PGP SIGNATURE----- --nextPart1276947.7vxR9E8l1F-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 09:12:44 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E14DE106568F for ; Mon, 8 Feb 2010 09:12:44 +0000 (UTC) (envelope-from rgrover1@gmail.com) Received: from mail-px0-f203.google.com (mail-px0-f203.google.com [209.85.216.203]) by mx1.freebsd.org (Postfix) with ESMTP id BE0778FC18 for ; Mon, 8 Feb 2010 09:12:44 +0000 (UTC) Received: by pxi41 with SMTP id 41so6843231pxi.27 for ; Mon, 08 Feb 2010 01:12:44 -0800 (PST) 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=p3RikZfjUCrfO0DKQ0WBDd0kUkp1aIntPb0aV2j/A1Q=; b=JdyXtAUIDBDv18hn8KV48ODL36ERFRHn3m+a9pWa21CAoaP3FVH0LbBLOrbLYzNJ1V rpXOlWwJcNNU5uITetnY/L+GH+58HQOw8KalPe+PEIh6bYqQJF0tIDu8llQDMPLqvEX4 Z3SspSacHph9XS7WuNTRS7CqudnygZyamwD0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LJSiQ7NvPOJ6PJ4Pit5I0nQC4Dez2oe8f2v5H6ZTmW8wPus2+Mdd6AdWfXPUsLKxZJ DaDYzdGFRTIbqTpkrM7cr/1aTa+uVUnf17f1cD4Gcio89ImyiPi0j+iixaemp3JHOODC Lg44vmdSO0fVTDfeSgAFP6iR7m5DIpbGfUMoU= MIME-Version: 1.0 Received: by 10.115.102.24 with SMTP id e24mr2443712wam.71.1265618946639; Mon, 08 Feb 2010 00:49:06 -0800 (PST) Date: Mon, 8 Feb 2010 14:19:06 +0530 Message-ID: <426bed111002080049u16354c87pd4fb8830e0542972@mail.gmail.com> From: Rohit Grover To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Unresponsive keyboard after a few boots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 09:12:45 -0000 Hi, I am using a very recent Freebsd 8.0 STABLE on a Macbook. I updated my sources and rebuilt a kernel about 3 days ago. I was able to use the machine fine once or twice after that. But now the keyboard has stopped working. The boot program is able to use the keyboard, but the kernel isn't, and I am unable to do anything useful with the machine from the login screen. I had rebuilt the kernel twice with slightly varying settings, so I don't have a copy of the previously working kernel in /boot/kernel.old. It may not be easy for me to download a ISO image. Can someone please help? Thanks. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 09:40:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B5C71065672 for ; Mon, 8 Feb 2010 09:40:26 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id EC7D98FC1B for ; Mon, 8 Feb 2010 09:40:25 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o189eLpF002703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 20:40:23 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o189eKe9008213; Mon, 8 Feb 2010 20:40:20 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o189eI5v008212; Mon, 8 Feb 2010 20:40:18 +1100 (EST) (envelope-from peter) Date: Mon, 8 Feb 2010 20:40:18 +1100 From: Peter Jeremy To: Andriy Gapon Message-ID: <20100208094018.GA7730@server.vk2pj.dyndns.org> References: <20100201085131.GA34006@server.vk2pj.dyndns.org> <4B66A0DD.2070109@icyb.net.ua> <20100202063635.GA64643@server.vk2pj.dyndns.org> <4B67C8A6.5050102@icyb.net.ua> <20100202230511.GA19744@pjdesk.au.alcatel-lucent.com> <4B6B4CD8.8060208@icyb.net.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <4B6B4CD8.8060208@icyb.net.ua> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Kernel probe order issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 09:40:26 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Andriy, On 2010-Feb-05 00:40:24 +0200, Andriy Gapon wrote: >Unfortunately, I don't see any explanation for what you are experiencing. > >I came up with some things with which you can try to experiment: > >1. Boot with hw.pci.usb_early_takeover=3D"0" in loader.conf. > >2. Comment out the following line in sys/dev/usb/controller/uhci_pci.c: >pci_write_config(self, PCI_LEGSUP, PCI_LEGSUP_USBPIRQDEN, 2); hps@ suggested a ukbd patch as well. Unfortunately, something has come up and I won't be able to check either suggestion until late March. --=20 Peter Jeremy --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktv3AIACgkQ/opHv/APuIc+iwCeLNfDomZH8/N0jdepGx2qVFzE ATMAn0qeCr+9NuCVwaJ/TIiqKwzZKtp6 =MuDP -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 09:52:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 946821065670 for ; Mon, 8 Feb 2010 09:52:07 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (unknown [IPv6:2002:51af:3dc3:0:20c:29ff:fece:79f3]) by mx1.freebsd.org (Postfix) with ESMTP id E137E8FC22 for ; Mon, 8 Feb 2010 09:52:06 +0000 (UTC) Received: from [IPv6:2002:51af:3dc3:0:1944:2305:85be:bcff] (unknown [IPv6:2002:51af:3dc3:0:1944:2305:85be:bcff]) (Authenticated sender: svein-listmail) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id D21D522 for ; Mon, 8 Feb 2010 10:52:09 +0100 (CET) Message-ID: <4B6FDEC5.2040905@stillbilde.net> Date: Mon, 08 Feb 2010 10:52:05 +0100 From: "Svein Skogen (Listmail Account)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B6F9A8D.4050907@langille.org> In-Reply-To: <4B6F9A8D.4050907@langille.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 09:52:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08.02.2010 06:01, Dan Langille wrote: > Hi, > > I'm looking at creating a large home use storage machine. Budget is a > concern, but size and reliability are also a priority. Noise is also a > concern, since this will be at home, in the basement. That, and cost, > pretty much rules out a commercial case, such as a 3U case. It would be > nice, but it greatly inflates the budget. This pretty much restricts me > to a tower case. > > The primary use of this machine will be a backup server[1]. It will do > other secondary use will include minor tasks such as samba, CIFS, cvsup, > etc. > > I'm thinking of 8x1TB (or larger) SATA drives. I've found a case[2] > with hot-swap bays[3], that seems interesting. I haven't looked at > power supplies, but given that number of drives, I expect something > beefy with a decent reputation is called for. > > Whether I use hardware or software RAID is undecided. I > > I think I am leaning towards software RAID, probably ZFS under FreeBSD > 8.x but I'm open to hardware RAID but I think the cost won't justify it > given ZFS. > > Given that, what motherboard and RAM configuration would you recommend > to work with FreeBSD [and probably ZFS]. The lists seems to indicate > that more RAM is better with ZFS. Just before christmas, I rebuilt my own storage backend server for my home, so I've had a recent look at "what's there". Some hardware I had from the old solution, and some were new. Some of it is a tad more expensive that what you gave as the idea here, but the logic is (mostly) the same. I'll also include what replacements for some of the old parts I'm looking at. Heirlooms of the old server: - -Disks (four Samsung HD501LJ, Four Seagate ST31500341AS) - -Disk Controller AMI/Lsilogic Megaraid SAS 8308ELP (8chan MFI) The new hardware around this: - -Chieftec UNB-410F-B - -Two Chieftec SST3141SAS - -Chieftec APS-850C (850watt modular power) - -Intel E7500 CPU using the bundled stock cooler, and arcticsilver paste - -4 2GB Corasair Valueram DDR2 1066 sticks - -Asus P5Q Premium mainboard - -LSI SAS3801E (for the tape autoloader) - -Some old graphics board (unless you need a lot of fancy 3D stuff, use what you have around that's not ESD-damaged here). Should I have started from scratch, I'd have used Seagate 2TB "Green" disks, due to the lower temperatures and powerconsumption of these. And that's about the only thing I'd do differently. The MFI controller (Megaraid) would stay, simply because it has built in logic to periodically do patrolreading and consistency checks, and I've had previous experiences with the raid-controllers checks discovering bad disks before they go critical. But this breed of controllers is a little costly (Customers are willing to pay for the features, so the manufacturer milks them for all they can). I recommend you go for a modular power, that is rated for quite a bit more that what you expect to draw from it. The reason is that as current increases, the efficiency of the conversion drops, so a power running at half its rated max, is more efficient than one pushed to the limits. Go for modular so you don't have to have the extra cables tied into coils inside your machine distruption airflow (and creating EMF noise). Make sure you get yourself a proper ESD wriststrap (or anklestrap) before handling any of these components, and make sure you use correct torque for all the screws handling the components (and disks). This machine will probably have a lot of uptime, and disks (and fans) create vibrations. If in doubt, use some fancy-colored nailpolish (or locktite) on the screws to make sure they don't unscrew from vibrations over time. (a loose screw has a will of it own, and WILL short-circuit the most expensive component in your computer). Also make sure you use cableties to get the cables out of the airflow, so you get sufficient cooling. Speaking of cooling, make sure your air-inputs have some sort of filtering, or you'll learn where Illiad (userfriendly.org) got the idea for "Dustpuppy". No matter how pedantic you are about cleaning your house, a computer is basically a large, expensive, vacuum-cleaner and WILL suck in dust from the air. These are some of the pointers I'd like to share on the subject. :) //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg Østli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktv3sUACgkQODUnwSLUlKSdCQCcDzIFDv4zSRmPwYP3XhxQyIBe Tc0AnikVuqUs0IO1Z6bcaeLJWjXJ2jVv =zV8R -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 10:18:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 756331065679; Mon, 8 Feb 2010 10:18: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 33B8E8FC13; Mon, 8 Feb 2010 10:18:31 +0000 (UTC) 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 <1NeQhK-0004bJ-3X>; Mon, 08 Feb 2010 11:18:30 +0100 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 <1NeQhK-0000cw-1i>; Mon, 08 Feb 2010 11:18:30 +0100 Message-ID: <4B6FE550.9020506@zedat.fu-berlin.de> Date: Mon, 08 Feb 2010 10:20:00 +0000 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100206 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-questions@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: NFSv4: mount -t nsf4 not the same as mount_newnfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 10:18:31 -0000 Hello. I set up a NFSv4 server located on a FreeBSD 8.0/amd64 box (most recent world). It seems I successfully set up the NFSv4 service and this results in a successful mount of a file system by another FreeBSD 8.0 box. But their is a weirdnes I do not understand. Mounting the filessystem via mount_newnfs host:/path /path works fine, but not mount -t nfs4 host:/path /path. When doing the latter, I always get the error : Operation not supported by device What I'm doing wrong? Regards, Oliver P.S. Kernel has both NFSSERVER and NFSD, NFSCL and NFSCLIENT, /etc/rc.conf has nfsv4_server_enable="YES" nfsuserd_enable="YES" rpcbind_enable="YES" on serverside, on clientside, it's nfsuserd_enable="YES" nfscbd_enable="YES" From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 10:59:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BE72106566B for ; Mon, 8 Feb 2010 10:59:31 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id C15C68FC0A for ; Mon, 8 Feb 2010 10:59:30 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 613AA19E023; Mon, 8 Feb 2010 11:59:29 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id F16A819E019; Mon, 8 Feb 2010 11:59:26 +0100 (CET) Message-ID: <4B6FEE8E.4090209@quip.cz> Date: Mon, 08 Feb 2010 11:59:26 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.7) Gecko/20100104 SeaMonkey/2.0.2 MIME-Version: 1.0 To: Dan Langille References: <4B6F9A8D.4050907@langille.org> In-Reply-To: <4B6F9A8D.4050907@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 10:59:31 -0000 Dan Langille wrote: > Hi, > > I'm looking at creating a large home use storage machine. Budget is a > concern, but size and reliability are also a priority. Noise is also a > concern, since this will be at home, in the basement. That, and cost, > pretty much rules out a commercial case, such as a 3U case. It would be > nice, but it greatly inflates the budget. This pretty much restricts me > to a tower case. > > The primary use of this machine will be a backup server[1]. It will do > other secondary use will include minor tasks such as samba, CIFS, cvsup, > etc. It depends on your needs (storage capacity [number of drives], performance etc.) One year ago I purchased HP ProLiant ML110G5 / P2160 / 1GB / 250GB SATA / DVDRW / Tower / (with 3 years Next Business Day support!). It is sold for about 9000,- CZK ($500), I added next 4GB of RAM, 4x 1TB Samsung F1 instead of original 250GB Seagate. System is booted from 2GB internal USB flash drive and all drives are in RAIDZ pool. The machine is really quiet. All in all cost is about $1000 with 3 years NBD. You can put in 2TB drives instead of 1TB drives. It is really low end machine, but runs without problems for more than a year. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 11:15:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DF221065676 for ; Mon, 8 Feb 2010 11:15:28 +0000 (UTC) (envelope-from christer.solskogen@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id E85C18FC0A for ; Mon, 8 Feb 2010 11:15:27 +0000 (UTC) Received: by ewy3 with SMTP id 3so3340326ewy.13 for ; Mon, 08 Feb 2010 03:15:26 -0800 (PST) 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=uCXE2QVS0kD6/+lC11RsAFHohsON0I6Hx8YgNXz9wcU=; b=osYrnREXA0RTIKRyG0ympWGXysNaIyJnriD0/LlgrLKyA8VHdpObSPGwgWvgp7kYSq HAH5qZw/sz+0T9pKzFsb8Unr/MtQk7fvSz7pP/4d1NuNbvfmsDNr4r4Pxe/fYJfkdjB2 fRLWouhPAyRwTLtCAMKnzTWmuUzCXV2B9x7n8= 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=Zf43kYUpOIaFdwZrTbtrmckmdJB5UZ8wvYuR7u+kSb/TGnhjg+avY7xFq/ZeexubMe KtIT9+WCBNCd29LQjpfLTJ678g5YzXrW1bE9lXqI97IZCmxGy46ovX+M1Yp0Rwv0a0Jl FOee0LJ7YIAsX1YU1eux9pqwt2xfAv5TsL1gw= MIME-Version: 1.0 Received: by 10.213.24.17 with SMTP id t17mr5486930ebb.19.1265627726724; Mon, 08 Feb 2010 03:15:26 -0800 (PST) In-Reply-To: <4B6FEE8E.4090209@quip.cz> References: <4B6F9A8D.4050907@langille.org> <4B6FEE8E.4090209@quip.cz> Date: Mon, 8 Feb 2010 12:15:26 +0100 Message-ID: From: Christer Solskogen To: Miroslav Lachman <000.fbsd@quip.cz> Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable , Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 11:15:28 -0000 On Mon, Feb 8, 2010 at 11:59 AM, Miroslav Lachman <000.fbsd@quip.cz> wrote: > System is booted from 2GB internal USB flash Be aware that not all USB sticks work as a root device on 8.0-RELEASE. I've tried a couple of different sticks that is probed *after* the kernel tries to mount /. It seems to be a problem that emerged with 8.0, as 7.x worked like a charm on the same USB stick. http://www.freebsd.org/cgi/query-pr.cgi?pr=138798 -- chs, From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 11:47:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97E4E106566B for ; Mon, 8 Feb 2010 11:47:36 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 8188F8FC1B for ; Mon, 8 Feb 2010 11:47:36 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta12.emeryville.ca.mail.comcast.net with comcast id fPnL1d0051vN32cACPnck1; Mon, 08 Feb 2010 11:47:36 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta22.emeryville.ca.mail.comcast.net with comcast id fPpF1d0033S48mS8iPpFHS; Mon, 08 Feb 2010 11:49:15 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E8F801E3033; Mon, 8 Feb 2010 03:47:34 -0800 (PST) Date: Mon, 8 Feb 2010 03:47:34 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100208114734.GA99245@icarus.home.lan> References: <426bed111002080049u16354c87pd4fb8830e0542972@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426bed111002080049u16354c87pd4fb8830e0542972@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Unresponsive keyboard after a few boots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 11:47:36 -0000 On Mon, Feb 08, 2010 at 02:19:06PM +0530, Rohit Grover wrote: > I am using a very recent Freebsd 8.0 STABLE on a Macbook. I updated my > sources and rebuilt a kernel about 3 days ago. I was able to use the > machine fine once or twice after that. But now the keyboard has > stopped working. The boot program is able to use the keyboard, but the > kernel isn't, and I am unable to do anything useful with the machine > from the login screen. > > I had rebuilt the kernel twice with slightly varying settings, so I > don't have a copy of the previously working kernel in > /boot/kernel.old. > > It may not be easy for me to download a ISO image. Can someone please help? Is the keyboard USB? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 13:30:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70A1A106566B; Mon, 8 Feb 2010 13:30:56 +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 2E76D8FC08; Mon, 8 Feb 2010 13:30:55 +0000 (UTC) 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 <1NeThX-0006US-7h>; Mon, 08 Feb 2010 14:30:55 +0100 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 <1NeThX-0006TA-5z>; Mon, 08 Feb 2010 14:30:55 +0100 Message-ID: <4B701269.9070703@zedat.fu-berlin.de> Date: Mon, 08 Feb 2010 13:32:25 +0000 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100206 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: www/firefox: Firefox 3.6 crashes, Firefox 3.5.7 not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 13:30:56 -0000 Today, I upgraded Firefox 3.5.7 (built yesterday) to Firefox 3.6. After deleting ~/.mozilla (after I did a buckup, of course), I tried a fresh start of 'firefox3'. After firefox showed up, I realized that no option-field (File, Extras etc) can be used, they are dead and after a few seconds I clicked them, firefox3 is crashing. Since I recompiled firefox 3.5.7 yesterday I was wondering if this is due to some 'false' lib or dependency. Since I figured that I have similar trouble with Thunderbird 3.0.1 after I installed it, I suspect a faulty library causing this behaviour. With Thunderbird 3, I never solved the problem although I tried to rebuild everything with thunderbird via 'portmaster -f'. I'll did this with firefox 3.6 also, but with no success. The crashing is observed on two nearly identical SMP FreeBSD 8.0/amd64 STABLE boxes (make world of today), up-to-date ports. The crash is NOT observed on my private oldish UP box, nearly the same setup, OS at the same revision and ports up to date as of yesterday. Maybe this could be a hint. Any hints or suggestions? Regards, Oliver From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 13:43:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 627811065670 for ; Mon, 8 Feb 2010 13:43:50 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f191.google.com (mail-yw0-f191.google.com [209.85.211.191]) by mx1.freebsd.org (Postfix) with ESMTP id 2528B8FC08 for ; Mon, 8 Feb 2010 13:43:49 +0000 (UTC) Received: by ywh29 with SMTP id 29so403121ywh.13 for ; Mon, 08 Feb 2010 05:43:49 -0800 (PST) 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=LzMI+O+nmZh9MOdF6/OZb2xfkq3EjSIuUChm0nrzjSw=; b=gp6Qfw5YLE8biX6q6CbEmHbIUC5zB1Sl1ZR+KiGAT3T4tp+zVlcM9nws1Bhoamt10l JhMR+ZHJAmvPvI1sYz2aUa6zEDdOw6DbA4WB5AREFalAttVoZkMaoborE1T3eGK9CdAQ ThOgKGSr7m3PKdwBDr4QhIRQF7L47QO9m9BqM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Qaqv0JtlrJCGCf1gpfvI43Mpixj9VfXvZx7yyjtpDBp5t8giDJHu4EreUfGoymCYma nIyipwBenNGzC9jO5IjsWRoxniiiI652DgbE0VDn8wNuq32TI84oIrqYZBy8o8TK2jqT g3d0zfqf+8mDFAyGM0uPUjubrcwwjS/A0vbYs= MIME-Version: 1.0 Received: by 10.101.128.5 with SMTP id f5mr3374035ann.125.1265636626938; Mon, 08 Feb 2010 05:43:46 -0800 (PST) Date: Mon, 8 Feb 2010 15:43:46 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: RE: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 13:43:50 -0000 >Any further ideas how to get rid of this "feature"? You have several options. 1) The most "clean" solution is probably using the WDIDLE3 utility on your drives to disable automatic parking or in cases where its not possible to complete disable it, you can adjust it to 5 minutes, which essentially solves the problem. Note that going this route will probably involve rebuilding your entire array from scratch, because applying WDIDLE3 to the disk is likely to very slightly affect disk geometry, but just enough for hardware raid or ZFS or whatever to bark at you and refuse to continue using the drive in an existing pool (the affected disk can become very slightly smaller in capacity). Backup data, apply WDIDLE3 to all disks. Recreate the pool, restore backups. This will also void your warranty if used on the new WD drives, although it will still work just fine. 2) A less clean solution would be to setup a script that polls the SMART data of all disks affected by the problem every 8-9 seconds and have this script launch on boot. This will keep the affected drives just busy enough to not park their heads. - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 13:55:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43AC9106566B for ; Mon, 8 Feb 2010 13:55:08 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id C5E978FC12 for ; Mon, 8 Feb 2010 13:55:07 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o18Dt4CV021090; Mon, 8 Feb 2010 14:55:06 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id E54C624; Mon, 8 Feb 2010 14:55:04 +0100 (CET) Date: Mon, 8 Feb 2010 14:55:04 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Dan Naumov Message-Id: <20100208145504.762eaa7b.gerrit@pmp.uni-hannover.de> In-Reply-To: References: Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.8.133622 Cc: FreeBSD-STABLE Mailing List Subject: Re: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 13:55:08 -0000 On Mon, 8 Feb 2010 15:43:46 +0200 Dan Naumov wrote about RE: one more load-cycle-count problem: DN> >Any further ideas how to get rid of this "feature"? DN> 1) The most "clean" solution is probably using the WDIDLE3 utility on DN> your drives to disable automatic parking or in cases where its not DN> possible to complete disable it, you can adjust it to 5 minutes, which DN> essentially solves the problem. Note that going this route will DN> probably involve rebuilding your entire array from scratch, because DN> applying WDIDLE3 to the disk is likely to very slightly affect disk DN> geometry, but just enough for hardware raid or ZFS or whatever to bark DN> at you and refuse to continue using the drive in an existing pool (the DN> affected disk can become very slightly smaller in capacity). Backup DN> data, apply WDIDLE3 to all disks. Recreate the pool, restore backups. DN> This will also void your warranty if used on the new WD drives, DN> although it will still work just fine. Thanks for the warning. How on earth can a tool to set the idle time affect the disk geometry?! DN> 2) A less clean solution would be to setup a script that polls the DN> SMART data of all disks affected by the problem every 8-9 seconds and DN> have this script launch on boot. This will keep the affected drives DN> just busy enough to not park their heads. That's what I'm doing since yesterday when I first noted the problem on this particular system. Not a pretty solution either. I'm close of buying Hitachi drives instead (HTE545050B9A300). Does anyone here know these drives and can confirm that they do not have this kind of problem (I would expect it because of the 24/7 certification)? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 13:56:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DC2F10656A4 for ; Mon, 8 Feb 2010 13:56:37 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f199.google.com (mail-yx0-f199.google.com [209.85.210.199]) by mx1.freebsd.org (Postfix) with ESMTP id 948088FC19 for ; Mon, 8 Feb 2010 13:56:36 +0000 (UTC) Received: by yxe37 with SMTP id 37so1977858yxe.27 for ; Mon, 08 Feb 2010 05:56:35 -0800 (PST) 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=zGQft543CCF2BpyikUlZk0QyTwZaPal/xJ2UKuMCruM=; b=ms2p6zfcJTI5HMImUJJuaprNmzOXga0DuGRB+INF2bkRY64lP2IzTaIGiHe0h31Nhr 676gtL7DsgYjvOzS6HosxYU7bcjoi29oHvDCYXfc8FRaVFqt3sqe9HFpnINgL3mHnU93 ZSYvFSdwNmoQzdEBnLEGV1Z56k55U0KXbqQ7Y= 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=Ut/+MtQJ+slCIfATI8Mu4/TcKuWG6CI7n4QQUDk8J+auMHRiiK8Wcs/PRup9LdUfAh MSVViKtoCHfB1qgJ3XHyjmp50EnCYXhD+ldWDfy8TVvXtDFg2eC8DEZwDaYhoQaGLTHM E6dY6nRp6li4vr1iHy9FEt+Xg6UPQb7tf/zLs= MIME-Version: 1.0 Received: by 10.101.199.30 with SMTP id b30mr8168779anq.177.1265637395722; Mon, 08 Feb 2010 05:56:35 -0800 (PST) In-Reply-To: <20100208145504.762eaa7b.gerrit@pmp.uni-hannover.de> References: <20100208145504.762eaa7b.gerrit@pmp.uni-hannover.de> Date: Mon, 8 Feb 2010 15:56:35 +0200 Message-ID: From: Dan Naumov To: =?ISO-8859-1?Q?Gerrit_K=FChn?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List Subject: Re: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 13:56:37 -0000 2010/2/8 Gerrit K=FChn : > On Mon, 8 Feb 2010 15:43:46 +0200 Dan Naumov wrote > about RE: one more load-cycle-count problem: > > DN> >Any further ideas how to get rid of this "feature"? > > DN> 1) The most "clean" solution is probably using the WDIDLE3 utility on > DN> your drives to disable automatic parking or in cases where its not > DN> possible to complete disable it, you can adjust it to 5 minutes, whic= h > DN> essentially solves the problem. Note that going this route will > DN> probably involve rebuilding your entire array from scratch, because > DN> applying WDIDLE3 to the disk is likely to very slightly affect disk > DN> geometry, but just enough for hardware raid or ZFS or whatever to bar= k > DN> at you and refuse to continue using the drive in an existing pool (th= e > DN> affected disk can become very slightly smaller in capacity). Backup > DN> data, apply WDIDLE3 to all disks. Recreate the pool, restore backups. > DN> This will also void your warranty if used on the new WD drives, > DN> although it will still work just fine. > > Thanks for the warning. How on earth can a tool to set the idle time > affect the disk geometry?! WDIDLE3 changes the drive firmware. This is also how WD can detect you've used it on your disk and void your warranty accordingly :) - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 14:23:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D59E1065670 for ; Mon, 8 Feb 2010 14:23:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 547728FC15 for ; Mon, 8 Feb 2010 14:23:00 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta07.emeryville.ca.mail.comcast.net with comcast id fS3b1d0031smiN4A7SP03c; Mon, 08 Feb 2010 14:23:00 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id fSP01d0083S48mS8gSP0Ve; Mon, 08 Feb 2010 14:23:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 174B11E3033; Mon, 8 Feb 2010 06:22:59 -0800 (PST) Date: Mon, 8 Feb 2010 06:22:59 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100208142259.GA3210@icarus.home.lan> References: <20100208145504.762eaa7b.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 14:23:00 -0000 On Mon, Feb 08, 2010 at 03:56:35PM +0200, Dan Naumov wrote: > 2010/2/8 Gerrit Kühn : > > On Mon, 8 Feb 2010 15:43:46 +0200 Dan Naumov wrote > > about RE: one more load-cycle-count problem: > > > > DN> >Any further ideas how to get rid of this "feature"? > > > > DN> 1) The most "clean" solution is probably using the WDIDLE3 utility on > > DN> your drives to disable automatic parking or in cases where its not > > DN> possible to complete disable it, you can adjust it to 5 minutes, which > > DN> essentially solves the problem. Note that going this route will > > DN> probably involve rebuilding your entire array from scratch, because > > DN> applying WDIDLE3 to the disk is likely to very slightly affect disk > > DN> geometry, but just enough for hardware raid or ZFS or whatever to bark > > DN> at you and refuse to continue using the drive in an existing pool (the > > DN> affected disk can become very slightly smaller in capacity). Backup > > DN> data, apply WDIDLE3 to all disks. Recreate the pool, restore backups. > > DN> This will also void your warranty if used on the new WD drives, > > DN> although it will still work just fine. > > > > Thanks for the warning. How on earth can a tool to set the idle time > > affect the disk geometry?! > > WDIDLE3 changes the drive firmware. This is also how WD can detect > you've used it on your disk and void your warranty accordingly :) I have to assume WDIDLE3 is identical in implementation/style as WDTLER is -- the firmware itself does not change but rather some tuning settings in an EEPROM on the drive PCB (which may be embedded in the on-PCB I/O controller -- yes this is possible, PIC chips offer this). Last I remember, there *is not* a way to determine if someone has ever adjusted these settings. As long as you set them back to their factory defaults (whatever those values are; the EXEs tell you what they were before they change them), there's no accurate way to determine whether or not the settings had been adjusted since the disk was shipped. The DOS utilities submit custom ATA CMDs or data to all WD disks to toggle or adjust these features. If someone could figure out what the command(s) were, the feature(s) could be implemented into atacontrol(8). Of course, that would require reverse-engineering of the EXEs, which would probably induce DMCA-related lawsuits (in the US). Sad too, since documentation of said feature(s) would improve customer satisfaction. But hey, I'm just an engineer, what do I know. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 14:33:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EC451065670 for ; Mon, 8 Feb 2010 14:33:35 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 9C81E8FC0C for ; Mon, 8 Feb 2010 14:33:34 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id D4F7619EF for ; Mon, 8 Feb 2010 15:33:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:content-disposition:content-type:content-type :mime-version:message-id:subject:subject:from:from:date:date :received:received; s=mail; t=1265639609; x=1267454009; bh=y3Ka1 gDfcgpYjEa8wC1jhdwSF9X0Muw0Md7iEx+3cco=; b=ioOjdEKsmCQaHtl3b4Sh2 7viegHvQET5gq3tgkvgQqCPCSgivDU8T0Cn80x9obFiGSi70jgZow6/O2edhAG4V ODqNn8xpgr8G0maf3GJeCGoArlJ6BQ8gHfKzBCaaPpzyJ9pEcZ5amp027+bMUbdJ lZkW1lSw01ZAfs0QjK4ZI4= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wdpAtUPcRzpJ for ; Mon, 8 Feb 2010 15:33:29 +0100 (CET) Received: by megatron.madpilot.net (Postfix, from userid 1000) id A38F419E6; Mon, 8 Feb 2010 15:33:29 +0100 (CET) Date: Mon, 8 Feb 2010 15:33:29 +0100 From: Guido Falsi To: FreeBSD-STABLE Mailing List Message-ID: <20100208143329.GA12057@megatron.madpilot.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline X-Operating-System: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Subject: ATA_CAM + ZFS gives short 1-2 seconds system freeze on disk load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 14:33:35 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! I'm seeing this problem on my machine at work. It's an HP DC 7800, mounts an ich9 chipset(not ahci capable). I'm attaching the dmesg. I noticed this in the past, but it got evident(and very annoying) while recompiling many ports today after the jpeg-8 update. It looks like it freezes the system for the second or two it takes to flush buffers to disk when there are big outputs. This happens when decompressiong big distfiles, mainly. The openoffice port triggers this almost continuosly every few seconds during compilation. I've also seen this when working with big files(for example graphic images in uncompressed formats). It gets very annoying and I don't remember this happening before activating the ATA_CAM flag. There was some slowdown with big disk access, but not a total freeze. The input I give during the freeze is not lost though, but replayed in a bunch as soon as the system becomes responsive again. BTW there's another thing that shows up on this machine. Lately, this too after putting the option ATA_CAM in the kernel, during boot there is a long pause(exactly one minute, as the message below states) in this point of the dmesg: uhub6: on usbus6 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 4 ports with 4 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen2.2: at usbus2 ums0: on usbus2 ums0: 16 buttons and [XYZ] coordinates ID=0 uhid0: on usbus2 ugen1.2: at usbus1 ubt0: on usbus1 ---------- 60 seconds pause happens here ------------ run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config ada0 at ata0 bus 0 scbus2 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO size 8192bytes)cd0 at ata1 bus 0 scbus3 target 0 lun 0 This is not a big problem but quite annoying too. Maybe they're related, maybe not. I don't relly know. Hope these indications help. If needed I could provide more information and test patches. Thanks to the developers for they're great work on FreeBSD. Hope this email helps make it even better! Thanks in advance for any attention to this problem! -- Guido Falsi --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot" Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #38: Mon Feb 8 10:27:55 CET 2010 root@vwg82.xxx.it:/usr/obj/usr/src/sys/VWG82 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz (2327.51-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4299161600 (4100 MB) avail memory = 4037332992 (3850 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard netsmb_dev: loaded iscsi: version 2.1.0 kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1230-0x1237 mem 0xf0100000-0xf017ffff,0xe0000000-0xefffffff,0xf0000000-0xf00fffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 6140k stolen memory agp0: aperture size is 256M drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xe0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 pci0: at device 3.0 (no driver attached) atapci0: port 0x1238-0x123f,0x1270-0x1273,0x1240-0x1247,0x1274-0x1277,0x11e0-0x11ef irq 18 at device 3.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 3.3 (no driver attached) em0: port 0x1100-0x111f mem 0xf0180000-0xf019ffff,0xf01a5000-0xf01a5fff irq 19 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1e:0b:ab:e6:a7 uhci0: port 0x1120-0x113f irq 20 at device 26.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1140-0x115f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1160-0x117f irq 22 at device 26.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xf01a6000-0xf01a63ff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 hdac0: mem 0xf01a0000-0xf01a3fff irq 21 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100122_0141 hdac0: [ITHREAD] pcib1: at device 28.0 on pci0 pci32: on pcib1 pcib2: irq 21 at device 28.1 on pci0 pci48: on pcib2 uhci3: port 0x1180-0x119f irq 20 at device 29.0 on pci0 uhci3: [ITHREAD] usbus4: on uhci3 uhci4: port 0x11a0-0x11bf irq 21 at device 29.1 on pci0 uhci4: [ITHREAD] usbus5: on uhci4 ehci1: mem 0xf01a6400-0xf01a67ff irq 20 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: on ehci1 pcib3: at device 30.0 on pci0 pci7: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x11f0-0x11ff,0x1200-0x120f irq 18 at device 31.2 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] atapci2: port 0x1260-0x1267,0x1280-0x1283,0x1268-0x126f,0x1284-0x1287,0x1210-0x121f,0x1220-0x122f irq 18 at device 31.5 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: port 0x378-0x37f,0x778-0x77d irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/13 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version 3 ZFS storage pool version 14 Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0xfc offMax=0x25a Waiting 5 seconds for SCSI devices to settle hdac0: HDA Codec #0: Analog Devices AD1884 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 4 ports with 4 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen2.2: at usbus2 ums0: on usbus2 ums0: 16 buttons and [XYZ] coordinates ID=0 uhid0: on usbus2 ugen1.2: at usbus1 ubt0: on usbus1 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config ada0 at ata0 bus 0 scbus2 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO size 8192bytes)cd0 at ata1 bus 0 scbus3 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO size 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada0: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) ada1 at ata4 bus 0 scbus4 target 0 lun 0 ada1: ATA-7 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO size 8192bytes) ada1: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched! Trying to mount root from zfs:tank em0: link state changed to UP --T4sUOijqQbZv57TR-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 14:35:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C543B1065670 for ; Mon, 8 Feb 2010 14:35:24 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 81DAA8FC13 for ; Mon, 8 Feb 2010 14:35:24 +0000 (UTC) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1NeUhv-000Ma7-1k; Mon, 08 Feb 2010 17:35:23 +0300 From: Boris Samorodov To: Dan Naumov References: <20100208145504.762eaa7b.gerrit@pmp.uni-hannover.de> Date: Mon, 08 Feb 2010 17:35:22 +0300 In-Reply-To: (Dan Naumov's message of "Mon, 8 Feb 2010 15:56:35 +0200") Message-ID: <55033829@bb.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD-STABLE Mailing List Subject: Re: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 14:35:24 -0000 On Mon, 8 Feb 2010 15:56:35 +0200 Dan Naumov wrote: > WDIDLE3 changes the drive firmware. This is also how WD can detect > you've used it on your disk and void your warranty accordingly :) I've upgraded the firmware at five WD1000FYPS disks. One of them still kept on running load cycles. Then I used wdidle3 to disable this feature at this particular disk. Finally that helped. But I don't see any changes at the disk geomentry. It's just the same as before (and other four disks as well). May be not all disks are affected by a geometry change. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 14:41:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADC07106568B for ; Mon, 8 Feb 2010 14:41:34 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 683498FC17 for ; Mon, 8 Feb 2010 14:41:34 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1NeUnp-0001hD-M5 for freebsd-stable@freebsd.org; Mon, 08 Feb 2010 15:41:29 +0100 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 ; Mon, 08 Feb 2010 15:41:29 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Feb 2010 15:41:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 08 Feb 2010 15:41:14 +0100 Lines: 17 Message-ID: References: <20100208143329.GA12057@megatron.madpilot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20100118 Thunderbird/3.0 In-Reply-To: <20100208143329.GA12057@megatron.madpilot.net> Sender: news Subject: Re: ATA_CAM + ZFS gives short 1-2 seconds system freeze on disk load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 14:41:34 -0000 On 02/08/10 15:33, Guido Falsi wrote: > It looks like it freezes the system for the second or two it takes > to flush buffers to disk when there are big outputs. This happens > when decompressiong big distfiles, mainly. The openoffice port > triggers this almost continuosly every few seconds during compilation. > I've also seen this when working with big files(for example graphic > images in uncompressed formats). > > It gets very annoying and I don't remember this happening before > activating the ATA_CAM flag. There was some slowdown with big disk > access, but not a total freeze. I think ZFS does this all the time, i.e. regardless of underlying device drivers. Can you test your theory by going to an older kernel and keeping *everything* else the same? From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 14:49:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 565E11065670 for ; Mon, 8 Feb 2010 14:49:49 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0D5408FC18 for ; Mon, 8 Feb 2010 14:49:48 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALKyb0uDaFvJ/2dsb2JhbADXNoRUBA X-IronPort-AV: E=Sophos;i="4.49,430,1262581200"; d="scan'208";a="64633266" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 08 Feb 2010 09:49:47 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 952BFFB809E; Mon, 8 Feb 2010 09:49:47 -0500 (EST) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxaLLfpZ7EEy; Mon, 8 Feb 2010 09:49:46 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id DBB92FB808D; Mon, 8 Feb 2010 09:49:46 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o18F13J26546; Mon, 8 Feb 2010 10:01:03 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 8 Feb 2010 10:01:03 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "O. Hartmann" In-Reply-To: <4B6FE550.9020506@zedat.fu-berlin.de> Message-ID: References: <4B6FE550.9020506@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: NFSv4: mount -t nsf4 not the same as mount_newnfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 14:49:49 -0000 On Mon, 8 Feb 2010, O. Hartmann wrote: > > Mounting the filessystem via > > mount_newnfs host:/path /path > > works fine, but not > > mount -t nfs4 host:/path /path. > The mount command can be either: mount -t nfs -o nfsv4 host:/path /path or mount -t newnfs -o nfsv4 host:/path /path (The above was what the old now removed nfs4 used.) Have fun with it, rick From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 14:50:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAA8C106566B; Mon, 8 Feb 2010 14:50:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9E4288FC08; Mon, 8 Feb 2010 14:50:58 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 50A7246B03; Mon, 8 Feb 2010 09:50:58 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 7042E8A025; Mon, 8 Feb 2010 09:50:57 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org, randi@freebsd.org Date: Mon, 8 Feb 2010 09:32:17 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <201002051400.o15E0p2T071852@lurza.secnetix.de> In-Reply-To: <201002051400.o15E0p2T071852@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002080932.17814.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 08 Feb 2010 09:50:57 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: 8.0-RELEASE -> -STABLE and size of / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 14:50:58 -0000 On Friday 05 February 2010 9:00:51 am Oliver Fromme wrote: > Randi Harper wrote: > > Marian Hettwer wrote: > > > +1 vote for making / bigger. > > > At least a size where a make installkernel runs through. > > > > This is going to happen. It's been on my to-do list for a while, as I > > find it increasingly annoying. The default sizes of all mount points > > need to be tweaked a bit. Be patient, there will be some new changes > > going into sysinstall very soon. > > Revisiting sysinstall's default partition sizes is certainly > a good idea. > > However, I think it makes a lot of sense to *not* install > symbol files in /boot/kernel by default. I can't think of > a good reason why they need to be there by default, and > they're what causes the space problems for the root FS in > the first place. > > Please change the default. It makes debugging kernel crashes for simpler and easier. For example, with the kernel symbols installed, the crashinfo(8) script can generate useful information after a crash on an out-of-the-box system. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 14:51:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B4BE106566B; Mon, 8 Feb 2010 14:51:00 +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 1F02C8FC12; Mon, 8 Feb 2010 14:51:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id AA8A446B2A; Mon, 8 Feb 2010 09:50:59 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id C5F5E8A021; Mon, 8 Feb 2010 09:50:58 -0500 (EST) From: John Baldwin To: Tom McLaughlin Date: Mon, 8 Feb 2010 09:49:00 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B6B89E7.8030002@sdf.lonestar.org> <201002050827.53343.jhb@freebsd.org> <4B6DE364.8030509@sdf.lonestar.org> In-Reply-To: <4B6DE364.8030509@sdf.lonestar.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201002080949.00877.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 08 Feb 2010 09:50:58 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: kib@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 14:51:00 -0000 On Saturday 06 February 2010 4:47:16 pm Tom McLaughlin wrote: > John Baldwin wrote, On 02/05/2010 08:27 AM: > > On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: > >> Hi all, a recent MFC to 7-STABLE has started to cause issues for my VMs > >> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk > >> controller the VM just shuts off. The workaround is to change the disk > >> controller to the BusLogic type. Still, it used to work up until last > >> week. The change was made around January 26th and based on the commits > >> that day I'm guessing it's either r203047 or r203073 > >> > >> I have the same issue with both amd64 and i386 VMs. This affects HEAD > >> and 8-STABLE as well and first affected HEAD over the summer. (I just > >> worked around it and went about my business at the time. :-/) I've > >> attached a dmesg from a kernel before the problem and one from after it > >> started. > > > > What if you set 'hw.clfush_disable=1' from the loader? > > > > Yes, that corrected it on all my VMs. I've talked to people on ESXi 4 > and they do not see the problem. I have yet to try 3.5u5 to see if this > is a non-issue. 3.5 will be supported for awhile longer from VMware. > I'm going to try upgrading the box during the week. I believe folks had to do this on HEAD/8.x as well. Perhaps we can automatically disable clflush if we are executing under VMware or Xen: Index: amd64/amd64/initcpu.c =================================================================== --- amd64/amd64/initcpu.c (revision 203430) +++ amd64/amd64/initcpu.c (working copy) @@ -177,17 +177,16 @@ if ((cpu_feature & CPUID_CLFSH) != 0) cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; /* - * XXXKIB: (temporary) hack to work around traps generated when - * CLFLUSHing APIC registers window. + * XXXKIB: (temporary) hack to work around traps generated + * when CLFLUSHing APIC registers window under virtualization + * environments. */ TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && - hw_clflush_disable == -1) + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) cpu_feature &= ~CPUID_CLFSH; /* * Allow to disable CLFLUSH feature manually by - * hw.clflush_disable tunable. This may help Xen guest on some AMD - * CPUs. + * hw.clflush_disable tunable. */ if (hw_clflush_disable == 1) cpu_feature &= ~CPUID_CLFSH; Index: i386/i386/initcpu.c =================================================================== --- i386/i386/initcpu.c (revision 203430) +++ i386/i386/initcpu.c (working copy) @@ -724,17 +724,16 @@ if ((cpu_feature & CPUID_CLFSH) != 0) cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; /* - * XXXKIB: (temporary) hack to work around traps generated when - * CLFLUSHing APIC registers window. + * XXXKIB: (temporary) hack to work around traps generated + * when CLFLUSHing APIC registers window under virtualization + * environments. */ TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && - hw_clflush_disable == -1) + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) cpu_feature &= ~CPUID_CLFSH; /* * Allow to disable CLFLUSH feature manually by - * hw.clflush_disable tunable. This may help Xen guest on some AMD - * CPUs. + * hw.clflush_disable tunable. */ if (hw_clflush_disable == 1) cpu_feature &= ~CPUID_CLFSH; -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 14:51:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A879E10658F1 for ; Mon, 8 Feb 2010 14:51:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 9185E8FC1D for ; Mon, 8 Feb 2010 14:51:49 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta06.emeryville.ca.mail.comcast.net with comcast id fR7g1d0031u4NiLA6SrqGS; Mon, 08 Feb 2010 14:51:50 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta21.emeryville.ca.mail.comcast.net with comcast id fSro1d00P3S48mS8hSrpv1; Mon, 08 Feb 2010 14:51:49 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CA3A51E3035; Mon, 8 Feb 2010 06:51:47 -0800 (PST) Date: Mon, 8 Feb 2010 06:51:47 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100208145147.GA3733@icarus.home.lan> References: <20100208143329.GA12057@megatron.madpilot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100208143329.GA12057@megatron.madpilot.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ATA_CAM + ZFS gives short 1-2 seconds system freeze on disk load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 14:51:49 -0000 On Mon, Feb 08, 2010 at 03:33:29PM +0100, Guido Falsi wrote: > Hi! > > I'm seeing this problem on my machine at work. It's an HP DC 7800, > mounts an ich9 chipset(not ahci capable). I'm attaching the dmesg. > > I noticed this in the past, but it got evident(and very annoying) > while recompiling many ports today after the jpeg-8 update. > > It looks like it freezes the system for the second or two it takes > to flush buffers to disk when there are big outputs. This happens > when decompressiong big distfiles, mainly. The openoffice port > triggers this almost continuosly every few seconds during compilation. > I've also seen this when working with big files(for example graphic > images in uncompressed formats). > > It gets very annoying and I don't remember this happening before > activating the ATA_CAM flag. There was some slowdown with big disk > access, but not a total freeze. This happens without ATA_CAM (e.g. using ataahci(4) or any other controller driver). The behaviour you're describing (bursty heavy disk I/O that stalls the subsystem) is pretty much the norm on all FreeBSD systems I've seen with ZFS. When it starts happening, it's easy to notice/follow using "zpool iostat 1" or "gstat -I500ms". Lots of I/O will happen (read or write) and the ARC is essentially being thrashed -- said utilities won't show any I/O counters incrementing until some threshold is reached, where you'll see a massive amount of I/O reported, during which time the system is sluggish (beyond acceptable levels, IMHO). A few seconds later, the I/O counters start reporting 0 as the ARC gets used, then a few seconds massive I/O, rinse lather repeat. I've seen Solaris 10 systems which behave the same way, and others which don't. I don't know what causes things to start behaving this way. > BTW there's another thing that shows up on this machine. Lately, this > too after putting the option ATA_CAM in the kernel, during boot there is > a long pause(exactly one minute, as the message below states) in this > point of the dmesg: This should probably be discussed in a different thread. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 14:56:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 201A2106566C; Mon, 8 Feb 2010 14:56:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A72F78FC08; Mon, 8 Feb 2010 14:56:40 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o18EuaA7014102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 16:56:36 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o18Euaqm072907; Mon, 8 Feb 2010 16:56:36 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o18EuanI072906; Mon, 8 Feb 2010 16:56:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Feb 2010 16:56:36 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20100208145636.GK9991@deviant.kiev.zoral.com.ua> References: <4B6B89E7.8030002@sdf.lonestar.org> <201002050827.53343.jhb@freebsd.org> <4B6DE364.8030509@sdf.lonestar.org> <201002080949.00877.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9a9Vq1BJdYBEXpLG" Content-Disposition: inline In-Reply-To: <201002080949.00877.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Tom McLaughlin , freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 14:56:41 -0000 --9a9Vq1BJdYBEXpLG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 08, 2010 at 09:49:00AM -0500, John Baldwin wrote: > On Saturday 06 February 2010 4:47:16 pm Tom McLaughlin wrote: > > John Baldwin wrote, On 02/05/2010 08:27 AM: > > > On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: > > >> Hi all, a recent MFC to 7-STABLE has started to cause issues for my = VMs > > >> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk > > >> controller the VM just shuts off. The workaround is to change the d= isk > > >> controller to the BusLogic type. Still, it used to work up until la= st > > >> week. The change was made around January 26th and based on the comm= its > > >> that day I'm guessing it's either r203047 or r203073 > > >> > > >> I have the same issue with both amd64 and i386 VMs. This affects HE= AD > > >> and 8-STABLE as well and first affected HEAD over the summer. (I ju= st > > >> worked around it and went about my business at the time. :-/) I've > > >> attached a dmesg from a kernel before the problem and one from after= it > > >> started. > > >=20 > > > What if you set 'hw.clfush_disable=3D1' from the loader? > > >=20 > >=20 > > Yes, that corrected it on all my VMs. I've talked to people on ESXi 4 > > and they do not see the problem. I have yet to try 3.5u5 to see if this > > is a non-issue. 3.5 will be supported for awhile longer from VMware. > > I'm going to try upgrading the box during the week. >=20 > I believe folks had to do this on HEAD/8.x as well. Perhaps we can=20 > automatically disable clflush if we are executing under VMware or Xen: >=20 > Index: amd64/amd64/initcpu.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 > --- amd64/amd64/initcpu.c (revision 203430) > +++ amd64/amd64/initcpu.c (working copy) > @@ -177,17 +177,16 @@ > if ((cpu_feature & CPUID_CLFSH) !=3D 0) > cpu_clflush_line_size =3D ((cpu_procinfo >> 8) & 0xff) * 8; > /* > - * XXXKIB: (temporary) hack to work around traps generated when > - * CLFLUSHing APIC registers window. > + * XXXKIB: (temporary) hack to work around traps generated > + * when CLFLUSHing APIC registers window under virtualization > + * environments. > */ > TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > - if (cpu_vendor_id =3D=3D CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) = && > - hw_clflush_disable =3D=3D -1) > + if (vm_guest !=3D 0 /* VM_GUEST_NO */ && hw_clflush_disable =3D=3D -1) > cpu_feature &=3D ~CPUID_CLFSH; > /* > * Allow to disable CLFLUSH feature manually by > - * hw.clflush_disable tunable. This may help Xen guest on some AMD > - * CPUs. > + * hw.clflush_disable tunable. > */ > if (hw_clflush_disable =3D=3D 1) > cpu_feature &=3D ~CPUID_CLFSH; > Index: i386/i386/initcpu.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 > --- i386/i386/initcpu.c (revision 203430) > +++ i386/i386/initcpu.c (working copy) > @@ -724,17 +724,16 @@ > if ((cpu_feature & CPUID_CLFSH) !=3D 0) > cpu_clflush_line_size =3D ((cpu_procinfo >> 8) & 0xff) * 8; > /* > - * XXXKIB: (temporary) hack to work around traps generated when > - * CLFLUSHing APIC registers window. > + * XXXKIB: (temporary) hack to work around traps generated > + * when CLFLUSHing APIC registers window under virtualization > + * environments. > */ > TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > - if (cpu_vendor_id =3D=3D CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) = && > - hw_clflush_disable =3D=3D -1) > + if (vm_guest !=3D 0 /* VM_GUEST_NO */ && hw_clflush_disable =3D=3D -1) > cpu_feature &=3D ~CPUID_CLFSH; > /* > * Allow to disable CLFLUSH feature manually by > - * hw.clflush_disable tunable. This may help Xen guest on some AMD > - * CPUs. > + * hw.clflush_disable tunable. > */ > if (hw_clflush_disable =3D=3D 1) > cpu_feature &=3D ~CPUID_CLFSH; It might be better to "or" old condition, i.e. Intel without SS, and new one, vm_guest !=3D 0, instead of replacing the old ? --9a9Vq1BJdYBEXpLG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktwJiMACgkQC3+MBN1Mb4jG2QCfS0vbigrnJVgk46/0kYhZxvPZ 618AoNtymKcvDduLyg47CkUGCeBxWx6o =7Kcr -----END PGP SIGNATURE----- --9a9Vq1BJdYBEXpLG-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 14:57:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EA041065697 for ; Mon, 8 Feb 2010 14:57:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 523A38FC22 for ; Mon, 8 Feb 2010 14:57:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAu1b0uDaFvH/2dsb2JhbADXPIRUBA X-IronPort-AV: E=Sophos;i="4.49,430,1262581200"; d="scan'208";a="64634347" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 08 Feb 2010 09:57:27 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 6FA9B10840B1; Mon, 8 Feb 2010 09:57:27 -0500 (EST) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8LJpH1AdreU; Mon, 8 Feb 2010 09:57:26 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 92D6A1084073; Mon, 8 Feb 2010 09:57:26 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o18F8he27625; Mon, 8 Feb 2010 10:08:43 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 8 Feb 2010 10:08:43 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "O. Hartmann" In-Reply-To: <4B6FE550.9020506@zedat.fu-berlin.de> Message-ID: References: <4B6FE550.9020506@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: NFSv4: mount -t nsf4 not the same as mount_newnfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 14:57:28 -0000 On Mon, 8 Feb 2010, O. Hartmann wrote: > > Mounting the filessystem via > > mount_newnfs host:/path /path > Oh, and you should set: sysctl vfs.newnfs.locallocks_enable=0 in the server, since I haven't fixed the local locking yet. (This implies that apps/daemons running locally on the server won't see byte range locks performed by NFSv4 clients.) However, byte range locking between NFSv4 clients should work ok. rick From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 14:57:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF8D51065794 for ; Mon, 8 Feb 2010 14:57:43 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 232E78FC0C for ; Mon, 8 Feb 2010 14:57:42 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o18EvdND023819; Mon, 8 Feb 2010 15:57:41 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id A9E5D4F; Mon, 8 Feb 2010 15:57:39 +0100 (CET) Date: Mon, 8 Feb 2010 15:57:39 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jeremy Chadwick Message-Id: <20100208155739.f2a51895.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100208142259.GA3210@icarus.home.lan> References: <20100208145504.762eaa7b.gerrit@pmp.uni-hannover.de> <20100208142259.GA3210@icarus.home.lan> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.8.144231 Cc: freebsd-stable@freebsd.org Subject: Re: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 14:57:43 -0000 On Mon, 8 Feb 2010 06:22:59 -0800 Jeremy Chadwick wrote about Re: one more load-cycle-count problem: JC> The DOS utilities submit custom ATA CMDs or data to all WD disks to JC> toggle or adjust these features. If someone could figure out what the JC> command(s) were, the feature(s) could be implemented into atacontrol JC> (8). Of course, that would require reverse-engineering of the EXEs, JC> which would probably induce DMCA-related lawsuits (in the US). Sad JC> too, since documentation of said feature(s) would improve customer JC> satisfaction. But hey, I'm just an engineer, what do I know. :-))) I would really prefer to be able to set this stuff via camcontrol or atacontrol. Alone having to boot DOS with this machine (no floppy, no cdrom) will be a real pain. And most probably the DOS tool will not be able to see the disks sitting behind my lsi-driven controller anyway, so I have to plug them elsewhere, too. Great job, WD. :-( cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 15:33:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 377AF1065670 for ; Mon, 8 Feb 2010 15:33: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 08A558FC14 for ; Mon, 8 Feb 2010 15:33:17 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8044746B06; Mon, 8 Feb 2010 10:33:16 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id A2D7C8A021; Mon, 8 Feb 2010 10:33:15 -0500 (EST) From: John Baldwin To: Kostik Belousov Date: Mon, 8 Feb 2010 10:32:37 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B6B89E7.8030002@sdf.lonestar.org> <201002080949.00877.jhb@freebsd.org> <20100208145636.GK9991@deviant.kiev.zoral.com.ua> In-Reply-To: <20100208145636.GK9991@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201002081032.37841.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 08 Feb 2010 10:33:15 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Tom McLaughlin , freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 15:33:17 -0000 On Monday 08 February 2010 9:56:36 am Kostik Belousov wrote: > On Mon, Feb 08, 2010 at 09:49:00AM -0500, John Baldwin wrote: > > On Saturday 06 February 2010 4:47:16 pm Tom McLaughlin wrote: > > > John Baldwin wrote, On 02/05/2010 08:27 AM: > > > > On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: > > > >> Hi all, a recent MFC to 7-STABLE has started to cause issues for my VMs > > > >> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk > > > >> controller the VM just shuts off. The workaround is to change the disk > > > >> controller to the BusLogic type. Still, it used to work up until last > > > >> week. The change was made around January 26th and based on the commits > > > >> that day I'm guessing it's either r203047 or r203073 > > > >> > > > >> I have the same issue with both amd64 and i386 VMs. This affects HEAD > > > >> and 8-STABLE as well and first affected HEAD over the summer. (I just > > > >> worked around it and went about my business at the time. :-/) I've > > > >> attached a dmesg from a kernel before the problem and one from after it > > > >> started. > > > > > > > > What if you set 'hw.clfush_disable=1' from the loader? > > > > > > > > > > Yes, that corrected it on all my VMs. I've talked to people on ESXi 4 > > > and they do not see the problem. I have yet to try 3.5u5 to see if this > > > is a non-issue. 3.5 will be supported for awhile longer from VMware. > > > I'm going to try upgrading the box during the week. > > > > I believe folks had to do this on HEAD/8.x as well. Perhaps we can > > automatically disable clflush if we are executing under VMware or Xen: > > > > Index: amd64/amd64/initcpu.c > > =================================================================== > > --- amd64/amd64/initcpu.c (revision 203430) > > +++ amd64/amd64/initcpu.c (working copy) > > @@ -177,17 +177,16 @@ > > if ((cpu_feature & CPUID_CLFSH) != 0) > > cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; > > /* > > - * XXXKIB: (temporary) hack to work around traps generated when > > - * CLFLUSHing APIC registers window. > > + * XXXKIB: (temporary) hack to work around traps generated > > + * when CLFLUSHing APIC registers window under virtualization > > + * environments. > > */ > > TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > > - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && > > - hw_clflush_disable == -1) > > + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) > > cpu_feature &= ~CPUID_CLFSH; > > /* > > * Allow to disable CLFLUSH feature manually by > > - * hw.clflush_disable tunable. This may help Xen guest on some AMD > > - * CPUs. > > + * hw.clflush_disable tunable. > > */ > > if (hw_clflush_disable == 1) > > cpu_feature &= ~CPUID_CLFSH; > > Index: i386/i386/initcpu.c > > =================================================================== > > --- i386/i386/initcpu.c (revision 203430) > > +++ i386/i386/initcpu.c (working copy) > > @@ -724,17 +724,16 @@ > > if ((cpu_feature & CPUID_CLFSH) != 0) > > cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; > > /* > > - * XXXKIB: (temporary) hack to work around traps generated when > > - * CLFLUSHing APIC registers window. > > + * XXXKIB: (temporary) hack to work around traps generated > > + * when CLFLUSHing APIC registers window under virtualization > > + * environments. > > */ > > TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > > - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && > > - hw_clflush_disable == -1) > > + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) > > cpu_feature &= ~CPUID_CLFSH; > > /* > > * Allow to disable CLFLUSH feature manually by > > - * hw.clflush_disable tunable. This may help Xen guest on some AMD > > - * CPUs. > > + * hw.clflush_disable tunable. > > */ > > if (hw_clflush_disable == 1) > > cpu_feature &= ~CPUID_CLFSH; > > It might be better to "or" old condition, i.e. Intel without SS, and > new one, vm_guest != 0, instead of replacing the old ? I thought the old condition only happened under VMware? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 16:06:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A4B5106568B; Mon, 8 Feb 2010 16:06:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 58E378FC12; Mon, 8 Feb 2010 16:06:05 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o18G61jB019807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 18:06:01 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o18G611X073489; Mon, 8 Feb 2010 18:06:01 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o18G60KF073488; Mon, 8 Feb 2010 18:06:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Feb 2010 18:06:00 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20100208160600.GN9991@deviant.kiev.zoral.com.ua> References: <4B6B89E7.8030002@sdf.lonestar.org> <201002080949.00877.jhb@freebsd.org> <20100208145636.GK9991@deviant.kiev.zoral.com.ua> <201002081032.37841.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wmhq21yAGFMoSpeN" Content-Disposition: inline In-Reply-To: <201002081032.37841.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Tom McLaughlin , freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 16:06:07 -0000 --wmhq21yAGFMoSpeN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 08, 2010 at 10:32:37AM -0500, John Baldwin wrote: > On Monday 08 February 2010 9:56:36 am Kostik Belousov wrote: > > On Mon, Feb 08, 2010 at 09:49:00AM -0500, John Baldwin wrote: > > > On Saturday 06 February 2010 4:47:16 pm Tom McLaughlin wrote: > > > > John Baldwin wrote, On 02/05/2010 08:27 AM: > > > > > On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: > > > > >> Hi all, a recent MFC to 7-STABLE has started to cause issues for= my VMs > > > > >> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI = disk > > > > >> controller the VM just shuts off. The workaround is to change t= he disk > > > > >> controller to the BusLogic type. Still, it used to work up unti= l last > > > > >> week. The change was made around January 26th and based on the = commits > > > > >> that day I'm guessing it's either r203047 or r203073 > > > > >> > > > > >> I have the same issue with both amd64 and i386 VMs. This affect= s HEAD > > > > >> and 8-STABLE as well and first affected HEAD over the summer. (= I just > > > > >> worked around it and went about my business at the time. :-/) I= 've > > > > >> attached a dmesg from a kernel before the problem and one from a= fter it > > > > >> started. > > > > >=20 > > > > > What if you set 'hw.clfush_disable=3D1' from the loader? > > > > >=20 > > > >=20 > > > > Yes, that corrected it on all my VMs. I've talked to people on ESX= i 4 > > > > and they do not see the problem. I have yet to try 3.5u5 to see if= this > > > > is a non-issue. 3.5 will be supported for awhile longer from VMwar= e. > > > > I'm going to try upgrading the box during the week. > > >=20 > > > I believe folks had to do this on HEAD/8.x as well. Perhaps we can= =20 > > > automatically disable clflush if we are executing under VMware or Xen: > > >=20 > > > Index: amd64/amd64/initcpu.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 > > > --- amd64/amd64/initcpu.c (revision 203430) > > > +++ amd64/amd64/initcpu.c (working copy) > > > @@ -177,17 +177,16 @@ > > > if ((cpu_feature & CPUID_CLFSH) !=3D 0) > > > cpu_clflush_line_size =3D ((cpu_procinfo >> 8) & 0xff) * 8; > > > /* > > > - * XXXKIB: (temporary) hack to work around traps generated when > > > - * CLFLUSHing APIC registers window. > > > + * XXXKIB: (temporary) hack to work around traps generated > > > + * when CLFLUSHing APIC registers window under virtualization > > > + * environments. > > > */ > > > TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > > > - if (cpu_vendor_id =3D=3D CPU_VENDOR_INTEL && !(cpu_feature & CPUID_= SS) && > > > - hw_clflush_disable =3D=3D -1) > > > + if (vm_guest !=3D 0 /* VM_GUEST_NO */ && hw_clflush_disable =3D=3D = -1) > > > cpu_feature &=3D ~CPUID_CLFSH; > > > /* > > > * Allow to disable CLFLUSH feature manually by > > > - * hw.clflush_disable tunable. This may help Xen guest on some AMD > > > - * CPUs. > > > + * hw.clflush_disable tunable. > > > */ > > > if (hw_clflush_disable =3D=3D 1) > > > cpu_feature &=3D ~CPUID_CLFSH; > > > Index: i386/i386/initcpu.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 > > > --- i386/i386/initcpu.c (revision 203430) > > > +++ i386/i386/initcpu.c (working copy) > > > @@ -724,17 +724,16 @@ > > > if ((cpu_feature & CPUID_CLFSH) !=3D 0) > > > cpu_clflush_line_size =3D ((cpu_procinfo >> 8) & 0xff) * 8; > > > /* > > > - * XXXKIB: (temporary) hack to work around traps generated when > > > - * CLFLUSHing APIC registers window. > > > + * XXXKIB: (temporary) hack to work around traps generated > > > + * when CLFLUSHing APIC registers window under virtualization > > > + * environments. > > > */ > > > TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > > > - if (cpu_vendor_id =3D=3D CPU_VENDOR_INTEL && !(cpu_feature & CPUID_= SS) && > > > - hw_clflush_disable =3D=3D -1) > > > + if (vm_guest !=3D 0 /* VM_GUEST_NO */ && hw_clflush_disable =3D=3D = -1) > > > cpu_feature &=3D ~CPUID_CLFSH; > > > /* > > > * Allow to disable CLFLUSH feature manually by > > > - * hw.clflush_disable tunable. This may help Xen guest on some AMD > > > - * CPUs. > > > + * hw.clflush_disable tunable. > > > */ > > > if (hw_clflush_disable =3D=3D 1) > > > cpu_feature &=3D ~CPUID_CLFSH; > >=20 > > It might be better to "or" old condition, i.e. Intel without SS, and > > new one, vm_guest !=3D 0, instead of replacing the old ? >=20 > I thought the old condition only happened under VMware? Reports I got where from XEN. --wmhq21yAGFMoSpeN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktwNmgACgkQC3+MBN1Mb4jHegCeLLTpOtXKNdE5reQ8HEkDqnI9 9LMAn2jggrg3DW/nlP8Wvc5ux9L8BcJv =Ixp5 -----END PGP SIGNATURE----- --wmhq21yAGFMoSpeN-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 16:13:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD7BE106566B for ; Mon, 8 Feb 2010 16:13:40 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 3CDA28FC25 for ; Mon, 8 Feb 2010 16:13:39 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 3E1E91B1E; Mon, 8 Feb 2010 17:13:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mail; t=1265645616; x= 1267460016; bh=ssXdwTZcduB+yNJyEMC0tXrzvW9bNpexbvLpnas9SAg=; b=C XDzatKhyDj74VrfH7Fj0Jp39igCrM2ZEW5o+aenlI3Xp5I+T3x/L6XJH+2IVytML Pc3CpCQlZJUQyqNsMYGxPjn6c2OfxJEc76nMKxK2CpKtTShoe7ZENugtMLPxbw9H QmGkpu82LRk3zOyzmjdBBYg0k4ZIEfJz6ywxRFH0lg= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rDs0ns1Uw-9n; Mon, 8 Feb 2010 17:13:36 +0100 (CET) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 8E9FD1B17; Mon, 8 Feb 2010 17:13:36 +0100 (CET) Date: Mon, 8 Feb 2010 17:13:36 +0100 From: Guido Falsi To: Ivan Voras Message-ID: <20100208161336.GA43063@megatron.madpilot.net> References: <20100208143329.GA12057@megatron.madpilot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ATA_CAM + ZFS gives short 1-2 seconds system freeze on disk load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 16:13:40 -0000 On Mon, Feb 08, 2010 at 03:41:14PM +0100, Ivan Voras wrote: > On 02/08/10 15:33, Guido Falsi wrote: > > >It looks like it freezes the system for the second or two it takes > >to flush buffers to disk when there are big outputs. This happens > >when decompressiong big distfiles, mainly. The openoffice port > >triggers this almost continuosly every few seconds during compilation. > >I've also seen this when working with big files(for example graphic > >images in uncompressed formats). > > > >It gets very annoying and I don't remember this happening before > >activating the ATA_CAM flag. There was some slowdown with big disk > >access, but not a total freeze. > > I think ZFS does this all the time, i.e. regardless of underlying > device drivers. Can you test your theory by going to an older kernel > and keeping *everything* else the same? I have made the test and in fact I see the same freezes without ATA_CAM and the legacy ata system. Maybe my idea was due to selective memory :) The other problem at boot still exists with ATA_CAM and does not without it. I'll create a new thread about this as suggested by Jeremy Chadwick. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 16:17:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A2E11065670 for ; Mon, 8 Feb 2010 16:17:40 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id DB4448FC0A for ; Mon, 8 Feb 2010 16:17:39 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id E1F4D1B2F; Mon, 8 Feb 2010 17:17:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mail; t=1265645856; x= 1267460256; bh=QGlgENip+KbAxx3+twTJLTzChlFYK4BtthXxmouVPG8=; b=n bCKl9k5sD7cl0noLa4FMse8ouEspbCMNuYo/jniFPkZxwgpOQo9hEQ1vWUlK2EKL TauYMdTIZSoj6WP4dLG722kZKME8OMQ65lHtSogLebSYL6f+hnPyuANcQda6qpZr 6uDdpE4C9LzdfAzlJv/aoZYvfMQy+B3f8ph7XdX30g= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aMLcyMzI3vHm; Mon, 8 Feb 2010 17:17:36 +0100 (CET) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 199A41B28; Mon, 8 Feb 2010 17:17:36 +0100 (CET) Date: Mon, 8 Feb 2010 17:17:35 +0100 From: Guido Falsi To: Jeremy Chadwick Message-ID: <20100208161735.GB43063@megatron.madpilot.net> References: <20100208143329.GA12057@megatron.madpilot.net> <20100208145147.GA3733@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100208145147.GA3733@icarus.home.lan> X-Operating-System: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ATA_CAM + ZFS gives short 1-2 seconds system freeze on disk load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 16:17:40 -0000 On Mon, Feb 08, 2010 at 06:51:47AM -0800, Jeremy Chadwick wrote: > On Mon, Feb 08, 2010 at 03:33:29PM +0100, Guido Falsi wrote: > > > > It gets very annoying and I don't remember this happening before > > activating the ATA_CAM flag. There was some slowdown with big disk > > access, but not a total freeze. > > This happens without ATA_CAM (e.g. using ataahci(4) or any other > controller driver). > > The behaviour you're describing (bursty heavy disk I/O that stalls the > subsystem) is pretty much the norm on all FreeBSD systems I've seen with > ZFS. When it starts happening, it's easy to notice/follow using "zpool > iostat 1" or "gstat -I500ms". Lots of I/O will happen (read or write) > and the ARC is essentially being thrashed -- said utilities won't show > any I/O counters incrementing until some threshold is reached, where > you'll see a massive amount of I/O reported, during which time the > system is sluggish (beyond acceptable levels, IMHO). A few seconds > later, the I/O counters start reporting 0 as the ARC gets used, then > a few seconds massive I/O, rinse lather repeat. > > I've seen Solaris 10 systems which behave the same way, and others which > don't. I don't know what causes things to start behaving this way. Thank you for the explanation. I in fact see the same problem with the legacy ata driver. I see this is something not trivial to fix, so I don't want to put too much burden on the pople who brought us zfs, which is anyway a great thing! Anyway the sluggish responsiveness of the system during these bursts is a problem for desktop use. I see that ZFS is mainly a server oriented FS, but this should be addressed sometime in the future I think. > > > BTW there's another thing that shows up on this machine. Lately, this > > too after putting the option ATA_CAM in the kernel, during boot there is > > a long pause(exactly one minute, as the message below states) in this > > point of the dmesg: > > This should probably be discussed in a different thread. I'll follow your suggestion and post a new thread about this. Thank you again! -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 16:20:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9840106566B; Mon, 8 Feb 2010 16:20:35 +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 650428FC15; Mon, 8 Feb 2010 16:20:35 +0000 (UTC) Received: from [195.4.92.27] (helo=17.mx.freenet.de) by mout4.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NeWLi-0002Iw-3N; Mon, 08 Feb 2010 17:20:34 +0100 Received: from p57ae002b.dip0.t-ipconnect.de ([87.174.0.43]:56285 helo=ernst.jennejohn.org) by 17.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #1) id 1NeWLh-00041j-SW; Mon, 08 Feb 2010 17:20:34 +0100 Date: Mon, 8 Feb 2010 17:20:33 +0100 From: Gary Jennejohn To: "O. Hartmann" Message-ID: <20100208172033.112629f7@ernst.jennejohn.org> In-Reply-To: <4B701269.9070703@zedat.fu-berlin.de> References: <4B701269.9070703@zedat.fu-berlin.de> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: Re: www/firefox: Firefox 3.6 crashes, Firefox 3.5.7 not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 16:20:35 -0000 On Mon, 08 Feb 2010 13:32:25 +0000 "O. Hartmann" wrote: > Today, I upgraded Firefox 3.5.7 (built yesterday) to Firefox 3.6. After > deleting ~/.mozilla (after I did a buckup, of course), I tried a fresh > start of 'firefox3'. After firefox showed up, I realized that no > option-field (File, Extras etc) can be used, they are dead and after a > few seconds I clicked them, firefox3 is crashing. > > Since I recompiled firefox 3.5.7 yesterday I was wondering if this is > due to some 'false' lib or dependency. Since I figured that I have > similar trouble with Thunderbird 3.0.1 after I installed it, I suspect a > faulty library causing this behaviour. With Thunderbird 3, I never > solved the problem although I tried to rebuild everything with > thunderbird via 'portmaster -f'. I'll did this with firefox 3.6 also, > but with no success. > > The crashing is observed on two nearly identical SMP FreeBSD 8.0/amd64 > STABLE boxes (make world of today), up-to-date ports. The crash is NOT > observed on my private oldish UP box, nearly the same setup, OS at the > same revision and ports up to date as of yesterday. Maybe this could be > a hint. > > Any hints or suggestions? > Try doing "ldd /usr/local/lib/firefox3/firefox-bin" and see if anything looks weird. You can porbably ignore /usr/local/lib/firefox3/firefox-bin: libxul.so => not found (0x0) libmozjs.so => not found (0x0) libxpcom.so => not found (0x0) because run-mozilla.sh sets LD_LIBRARY_PATH to include /usr/local/lib/firefox3 where these libraries are installed. I merely deleted my old firefox 3.6 and reinstalled from the port (on 9-CURRENT AMD64) and haven't seen any problems. But of course, I've been running various incarnations of 3.6 for a while and may have gotten all the dependencies already correctly installed. --- Gary Jennejohn From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 16:29:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF28E1065695 for ; Mon, 8 Feb 2010 16:29:14 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by mx1.freebsd.org (Postfix) with ESMTP id 59FC28FC1C for ; Mon, 8 Feb 2010 16:29:14 +0000 (UTC) Received: from [87.79.193.4] (helo=r500.local) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1NeWJ1-0002Ko-N9 for freebsd-stable@freebsd.org; Mon, 08 Feb 2010 17:17:47 +0100 Date: Mon, 8 Feb 2010 17:18:22 +0100 From: Fabian Keil To: freebsd-stable@freebsd.org Message-ID: <20100208171822.12773278@r500.local> In-Reply-To: <20100208145147.GA3733@icarus.home.lan> References: <20100208143329.GA12057@megatron.madpilot.net> <20100208145147.GA3733@icarus.home.lan> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.18.6; amd64-portbld-freebsd9.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; micalg=PGP-SHA1; boundary="Sig_/CV70vSwVb2oMLr7jxC3nJA4"; protocol="application/pgp-signature" X-Df-Sender: 775067 Subject: Re: ATA_CAM + ZFS gives short 1-2 seconds system freeze on disk load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 16:29:14 -0000 --Sig_/CV70vSwVb2oMLr7jxC3nJA4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Jeremy Chadwick wrote: > On Mon, Feb 08, 2010 at 03:33:29PM +0100, Guido Falsi wrote: > > I'm seeing this problem on my machine at work. It's an HP DC 7800, > > mounts an ich9 chipset(not ahci capable). I'm attaching the dmesg. > >=20 > > I noticed this in the past, but it got evident(and very annoying) > > while recompiling many ports today after the jpeg-8 update. > >=20 > > It looks like it freezes the system for the second or two it takes > > to flush buffers to disk when there are big outputs. This happens > > when decompressiong big distfiles, mainly. The openoffice port > > triggers this almost continuosly every few seconds during compilation. > > I've also seen this when working with big files(for example graphic > > images in uncompressed formats). > >=20 > > It gets very annoying and I don't remember this happening before > > activating the ATA_CAM flag. There was some slowdown with big disk > > access, but not a total freeze. >=20 > This happens without ATA_CAM (e.g. using ataahci(4) or any other > controller driver). Indeed. > The behaviour you're describing (bursty heavy disk I/O that stalls the > subsystem) is pretty much the norm on all FreeBSD systems I've seen with > ZFS. When it starts happening, it's easy to notice/follow using "zpool > iostat 1" or "gstat -I500ms". Lots of I/O will happen (read or write) > and the ARC is essentially being thrashed -- said utilities won't show > any I/O counters incrementing until some threshold is reached, where > you'll see a massive amount of I/O reported, during which time the > system is sluggish (beyond acceptable levels, IMHO). A few seconds > later, the I/O counters start reporting 0 as the ARC gets used, then > a few seconds massive I/O, rinse lather repeat. I experienced what I think is the same problem. ZFS's bulk disk flushes caused vlc to occasionally stutter when viewing a DVD rip from disk while ripping a DVD at the same time. My workaround is to put "vfs.zfs.txg.timeout=3D3" in /boot/loader.conf. I think I read about this on zfs-discuss@. I assume on faster systems one can use a higher value. I'm currently updating the jpeg dependencies, too: fk@r500 ~ $zpool iostat 1 capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- tank 176G 52.1G 22 40 1.40M 1.85M tank 176G 52.1G 73 0 9.24M 0 tank 176G 52.1G 73 0 9.05M 0 tank 176G 52.1G 42 176 5.12M 11.3M tank 176G 52.1G 68 0 8.62M 0 tank 176G 52.1G 67 0 8.43M 0 tank 176G 52.1G 57 106 7.11M 9.54M tank 176G 52.1G 75 0 9.50M 0 tank 176G 52.1G 76 0 9.62M 0 tank 176G 52.1G 46 167 5.74M 11.7M tank 176G 52.1G 79 0 9.99M 0 tank 176G 52.1G 81 0 10.2M 0 tank 176G 52.1G 43 164 5.43M 11.7M tank 176G 52.1G 71 0 9.00M 0 tank 176G 52.1G 61 39 7.74M 5.00M tank 176G 52.1G 46 111 5.74M 9.17M tank 176G 52.1G 71 0 8.99M 0 tank 176G 52.1G 80 0 10.1M 0 tank 176G 52.1G 47 113 5.87M 9.68M tank 176G 52.1G 70 0 8.87M 0 tank 176G 52.1G 78 0 9.80M 0 tank 176G 52.1G 42 164 5.24M 11.3M tank 176G 52.1G 76 0 9.62M 0 tank 176G 52.1G 79 0 9.99M 0 tank 176G 52.1G 49 153 6.11M 10.8M tank 176G 52.1G 72 0 9.12M 0 Fabian --Sig_/CV70vSwVb2oMLr7jxC3nJA4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktwOVcACgkQBYqIVf93VJ3u+QCgnudevzboYRjzkRajHNanpHWP 72wAoKiezne4xZRxYAsKdON8OqR6DnxR =t8D8 -----END PGP SIGNATURE----- --Sig_/CV70vSwVb2oMLr7jxC3nJA4-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 16:30:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B0EE106566C for ; Mon, 8 Feb 2010 16:30:32 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id E9D228FC23 for ; Mon, 8 Feb 2010 16:30:30 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id CFBCD1B66 for ; Mon, 8 Feb 2010 17:30:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:content-disposition:content-type:content-type :mime-version:message-id:subject:subject:from:from:date:date :received:received; s=mail; t=1265646626; x=1267461026; bh=IHU89 BXVrFAWCdlYuUVxphnOVpUrLzn7ctJxfnCc1cU=; b=rPk/W/RsbZ96EnQT9YBhb SDdGr5m4R4txO8iOlZerHkMRq/PtqAZW2K2YiCH3hAtfyNlqYeBUE+hhM01DZYj+ SsoMDcHNGDmVKtfRIw1GDFsC5SFE+z6DkV2e41BDKn6P26vxBV94RMDANDn9lL/E I5CZNyOuQurXvYHwsrv4NE= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Kf3XumLuP7Gw for ; Mon, 8 Feb 2010 17:30:26 +0100 (CET) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 327E71B5A; Mon, 8 Feb 2010 17:30:26 +0100 (CET) Date: Mon, 8 Feb 2010 17:30:26 +0100 From: Guido Falsi To: FreeBSD-STABLE Mailing List Message-ID: <20100208163026.GC43063@megatron.madpilot.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline X-Operating-System: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Subject: ATA_CAM run_interrupt_driven_hooks waiting for xpt_config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 16:30:32 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I'm opening this new thread about this strange problem on boot that I have. I'm attaching 2 dmesg. One without ATA_CAM and one with. Botting with ATA__CAM on this machine creates a 60 second pause in the kernel boot just after the line: ubt0: on usbus1 After sixty seconds the following message appears: run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config a few moments later the boot process goes on as usual. The machine is an HP DC7800 PC, with an ich7 southbridge not ahci capable. I've also seen this same problem on an HP Proliant 150G6 desktop server. I am available to provide any further details if needed. Thanks for any answer and time spent on this problem! -- Guido Falsi --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.oldata" Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #39: Mon Feb 8 15:59:14 CET 2010 root@vwg82.xxx.it:/usr/obj/usr/src/sys/VWG82 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz (2327.51-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4299161600 (4100 MB) avail memory = 4037160960 (3850 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard netsmb_dev: loaded iscsi: version 2.1.0 kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1230-0x1237 mem 0xf0100000-0xf017ffff,0xe0000000-0xefffffff,0xf0000000-0xf00fffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 6140k stolen memory agp0: aperture size is 256M drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xe0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 pci0: at device 3.0 (no driver attached) atapci0: port 0x1238-0x123f,0x1270-0x1273,0x1240-0x1247,0x1274-0x1277,0x11e0-0x11ef irq 18 at device 3.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 3.3 (no driver attached) em0: port 0x1100-0x111f mem 0xf0180000-0xf019ffff,0xf01a5000-0xf01a5fff irq 19 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1e:0b:ab:e6:a7 uhci0: port 0x1120-0x113f irq 20 at device 26.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1140-0x115f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1160-0x117f irq 22 at device 26.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xf01a6000-0xf01a63ff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 hdac0: mem 0xf01a0000-0xf01a3fff irq 21 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100122_0141 hdac0: [ITHREAD] pcib1: at device 28.0 on pci0 pci32: on pcib1 pcib2: irq 21 at device 28.1 on pci0 pci48: on pcib2 uhci3: port 0x1180-0x119f irq 20 at device 29.0 on pci0 uhci3: [ITHREAD] usbus4: on uhci3 uhci4: port 0x11a0-0x11bf irq 21 at device 29.1 on pci0 uhci4: [ITHREAD] usbus5: on uhci4 ehci1: mem 0xf01a6400-0xf01a67ff irq 20 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: on ehci1 pcib3: at device 30.0 on pci0 pci7: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x11f0-0x11ff,0x1200-0x120f irq 18 at device 31.2 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] atapci2: port 0x1260-0x1267,0x1280-0x1283,0x1268-0x126f,0x1284-0x1287,0x1210-0x121f,0x1220-0x122f irq 18 at device 31.5 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: port 0x378-0x37f,0x778-0x77d irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/13 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 ppi0: on ppbus0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version 3 ZFS storage pool version 14 Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0xfc offMax=0x333 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ad0: 152627MB at ata0-master UDMA100 SATA 3Gb/s ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 4 ports with 4 removable, self powered uhub3: 6 ports with 6 removable, self powered acd0: DVDR at ata1-master UDMA100 SATA 1.5Gb/s ad8: 152627MB at ata4-master UDMA100 SATA 3Gb/s hdac0: HDA Codec #0: Analog Devices AD1884 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 SMP: AP CPU #1 Launched! Root mount waiting for: usbus3 Root mount waiting for: usbus3 Trying to mount root from zfs:tank ugen1.2: at usbus1 ubt0: on usbus1 ugen2.2: at usbus2 ums0: on usbus2 ums0: 16 buttons and [XYZ] coordinates ID=0 uhid0: on usbus2 em0: link state changed to UP --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.ATA_CAM" Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #38: Mon Feb 8 10:27:55 CET 2010 root@vwg82.xxx.it:/usr/obj/usr/src/sys/VWG82 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz (2327.51-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4299161600 (4100 MB) avail memory = 4037332992 (3850 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard netsmb_dev: loaded iscsi: version 2.1.0 kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1230-0x1237 mem 0xf0100000-0xf017ffff,0xe0000000-0xefffffff,0xf0000000-0xf00fffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 6140k stolen memory agp0: aperture size is 256M drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xe0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 pci0: at device 3.0 (no driver attached) atapci0: port 0x1238-0x123f,0x1270-0x1273,0x1240-0x1247,0x1274-0x1277,0x11e0-0x11ef irq 18 at device 3.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 3.3 (no driver attached) em0: port 0x1100-0x111f mem 0xf0180000-0xf019ffff,0xf01a5000-0xf01a5fff irq 19 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1e:0b:ab:e6:a7 uhci0: port 0x1120-0x113f irq 20 at device 26.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1140-0x115f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1160-0x117f irq 22 at device 26.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xf01a6000-0xf01a63ff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 hdac0: mem 0xf01a0000-0xf01a3fff irq 21 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100122_0141 hdac0: [ITHREAD] pcib1: at device 28.0 on pci0 pci32: on pcib1 pcib2: irq 21 at device 28.1 on pci0 pci48: on pcib2 uhci3: port 0x1180-0x119f irq 20 at device 29.0 on pci0 uhci3: [ITHREAD] usbus4: on uhci3 uhci4: port 0x11a0-0x11bf irq 21 at device 29.1 on pci0 uhci4: [ITHREAD] usbus5: on uhci4 ehci1: mem 0xf01a6400-0xf01a67ff irq 20 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: on ehci1 pcib3: at device 30.0 on pci0 pci7: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x11f0-0x11ff,0x1200-0x120f irq 18 at device 31.2 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] atapci2: port 0x1260-0x1267,0x1280-0x1283,0x1268-0x126f,0x1284-0x1287,0x1210-0x121f,0x1220-0x122f irq 18 at device 31.5 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: port 0x378-0x37f,0x778-0x77d irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/13 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version 3 ZFS storage pool version 14 Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0xfc offMax=0x25a Waiting 5 seconds for SCSI devices to settle hdac0: HDA Codec #0: Analog Devices AD1884 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 4 ports with 4 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen2.2: at usbus2 ums0: on usbus2 ums0: 16 buttons and [XYZ] coordinates ID=0 uhid0: on usbus2 ugen1.2: at usbus1 ubt0: on usbus1 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config ada0 at ata0 bus 0 scbus2 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO size 8192bytes)cd0 at ata1 bus 0 scbus3 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO size 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada0: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) ada1 at ata4 bus 0 scbus4 target 0 lun 0 ada1: ATA-7 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO size 8192bytes) ada1: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched! Trying to mount root from zfs:tank em0: link state changed to UP --OXfL5xGRrasGEqWY-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 16:59:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD74E1065670 for ; Mon, 8 Feb 2010 16:59:01 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 71F298FC2E for ; Mon, 8 Feb 2010 16:59:01 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 4A3CE1BBE; Mon, 8 Feb 2010 17:59:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mail; t=1265648334; x= 1267462734; bh=h/RUGr/46FaBwX5OTAxow7I0qcbIceXw1Mql79ItN3Q=; b=o 71RSCchB8YvhUq8xgVGL0nVeJOKlLJwvEqT4LPAOQtMP8ymvb92/iQwgIv1gh9Y8 CE6Byr8XmFw3wlKBL+Jny42UTcHf+3CiwrxuUtcum35e8i+Agu9rhUu2t8JX+UrQ yGKIEkQPZyLBHIBDTEn5LQW9NlvNAU4zzQ0ARmv9q4= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fx6vlrKemBe5; Mon, 8 Feb 2010 17:58:54 +0100 (CET) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 1C0EC1BB7; Mon, 8 Feb 2010 17:58:54 +0100 (CET) Date: Mon, 8 Feb 2010 17:58:53 +0100 From: Guido Falsi To: Fabian Keil Message-ID: <20100208165853.GA43617@megatron.madpilot.net> References: <20100208143329.GA12057@megatron.madpilot.net> <20100208145147.GA3733@icarus.home.lan> <20100208171822.12773278@r500.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100208171822.12773278@r500.local> X-Operating-System: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ATA_CAM + ZFS gives short 1-2 seconds system freeze on disk load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 16:59:01 -0000 On Mon, Feb 08, 2010 at 05:18:22PM +0100, Fabian Keil wrote: > > I experienced what I think is the same problem. ZFS's bulk disk flushes > caused vlc to occasionally stutter when viewing a DVD rip from disk while > ripping a DVD at the same time. > > My workaround is to put "vfs.zfs.txg.timeout=3" in /boot/loader.conf. > I think I read about this on zfs-discuss@. I assume on faster systems > one can use a higher value. This was a very good idea. I'm trying this and the system freezes much less if at all. Are there any drawbacks I should be aware of? I can imagine that forcing more disk writes somewhat slows down normal disk activity, but I can bear that on a desktop system. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 17:19:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97144106566C; Mon, 8 Feb 2010 17:19:38 +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 50E2C8FC0C; Mon, 8 Feb 2010 17:19:38 +0000 (UTC) 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 <1NeXGr-000830-CX>; Mon, 08 Feb 2010 18:19:37 +0100 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 <1NeXGr-0004aT-At>; Mon, 08 Feb 2010 18:19:37 +0100 Message-ID: <4B704804.4030802@zedat.fu-berlin.de> Date: Mon, 08 Feb 2010 17:21:08 +0000 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100206 Thunderbird/3.0.1 MIME-Version: 1.0 To: Rick Macklem References: <4B6FE550.9020506@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: NFSv4: mount -t nsf4 not the same as mount_newnfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 17:19:38 -0000 On 02/08/10 15:08, Rick Macklem wrote: > > > On Mon, 8 Feb 2010, O. Hartmann wrote: > >> >> Mounting the filessystem via >> >> mount_newnfs host:/path /path >> > Oh, and you should set: > sysctl vfs.newnfs.locallocks_enable=0 > in the server, since I haven't fixed the local locking yet. (This implies > that apps/daemons running locally on the server won't see byte range > locks performed by NFSv4 clients.) However, byte range locking between > NFSv4 clients should work ok. > > rick > _______________________________________________ > 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" Interesting, I see a lot of vfs.newfs-stuff on server-side, but not this specific OID. Do I miss something here? Regards, Oliver From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 17:25:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0579D106566C; Mon, 8 Feb 2010 17:25:59 +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 4AE188FC13; Mon, 8 Feb 2010 17:25:53 +0000 (UTC) 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 <1NeXMv-0000Yp-4W>; Mon, 08 Feb 2010 18:25:53 +0100 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 <1NeXMv-0004xH-2W>; Mon, 08 Feb 2010 18:25:53 +0100 Message-ID: <4B70497B.1000908@zedat.fu-berlin.de> Date: Mon, 08 Feb 2010 17:27:23 +0000 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100206 Thunderbird/3.0.1 MIME-Version: 1.0 To: Rick Macklem References: <4B6FE550.9020506@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: NFSv4: mount -t nsf4 not the same as mount_newnfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 17:25:59 -0000 On 02/08/10 15:01, Rick Macklem wrote: > > > On Mon, 8 Feb 2010, O. Hartmann wrote: > >> >> Mounting the filessystem via >> >> mount_newnfs host:/path /path >> >> works fine, but not >> >> mount -t nfs4 host:/path /path. >> > > The mount command can be either: > mount -t nfs -o nfsv4 host:/path /path > or > mount -t newnfs -o nfsv4 host:/path /path > (The above was what the old now removed nfs4 used.) > > Have fun with it, rick So I guess the above one is the more 'transparent' one with respect to the future, when NFSv4 gets mature and its way as matured into the kernel? I tried the above and it works. But it seems, that only UFS2 filesystems can be mounted by the client. When trying mounting a filesystem residing on ZFS, it fails. Mounting works, but when try to access or doing a simple 'ls', I get ls: /backup: Permission denied On server side, /etc/exports looks like -- V4: / -sec=sys:krb5 #IPv4# /backup #IPv4# -- Is there still an issue with ZFS? Regards, Oliver From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 17:50:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04FA11065676; Mon, 8 Feb 2010 17:50:13 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9888FC15; Mon, 8 Feb 2010 17:50:12 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o18HoA10071786; Mon, 8 Feb 2010 19:50:10 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B704ECD.1060902@eng.auth.gr> Date: Mon, 08 Feb 2010 19:50:05 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: Rick Macklem References: <4B6BE7A2.6000402@eng.auth.gr> <4B6D3A18.2030304@eng.auth.gr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: Kerberized NFSv3 incorrect behavior X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 17:50:13 -0000 On 08/02/2010 00:34, Rick Macklem wrote: > > > On Sat, 6 Feb 2010, George Mamalakis wrote: > >> >> thank you for all your answers. I am planning on setting up the >> computer labs of my department using kerberized nfsv3 (since v4 seems >> to be "more" experimental) with a FreeBSD nfs server and Linux nfs >> clients. I was wondering "how stable" such an implementation would >> be; meaning that I wouldn't want to end up with an unstsable setup >> when receiving requests from 50-60 simultaneous clients, because that >> would be my everyday scenario. >> > > I believe that the above should be stable, but your mileage may vary, as > they say. The main issue will be what your TGT lifetime will be, since > client access to the server will normally stop when the TGT expires. Some > systems (Mac OS X) will automagically renew the TGT before it expires, > if your KDC allows that. I don't think most/all Linux systems do this > by default, but there are some utilities out there (try a search for > krenew) that will do so. > I think that this I can be overcome with a default timeout option in my shell variables (at least for the 'pilot phase'). > Basically, I think you'll want to avoid TGTs expiring before the user > logs out. You also need a unique uid<->user principal mapping for all > users logging in. I am planning on using LDAP as my backend with kerberos attributes (I have already setup my ldap like that). To be honest, I have done something funny. My heimdal's backend is openldap; this LDAP is only for heimdal access (inside a jail). Then, I have another jail which serves its openldap instance to all my clients. This ldap (which stores a totally different DIT then heimdal's LDAP) is kerberized (it uses gssapi authentication via cyrus-sasl), using the heimdal jail. It's a bit dramatic, but it seems to work fine-until now-, it seems quite secure, and allows me to synchronize the heimdal backend easily through openldap replication. Moreover, keeping the user credentials in ldap helps for having a generic user/password store for other services I use (like samba, (for my windows hosts)). So, I use a different ldap attribute for samba-semantics and another ldap attribute for kerberos. Lastly, openldap caters for storing uids,gids,home_folder_locations,etc for my users, where my clients have access to this information via their respective nsswitch.conf files. I think that this answers your question regarding uid<->user principal mapping, unless I misunderstood something. > > You definitely want to do some testing with whatever Linux system you > are using for the client. > > Good luck with it, rick > ps: Choosing nfsv3 vs nfsv4 is basically independent of using RPCSEC_GSS > except for the host based initiator credential needed by some clients > (Linux and Solaris10 are among those) for NFSv4. > To tell you the truth, when I recompiled my kernel with: options NFSD options KGSSAPI device crypto to setup an nvsv4 server, nfsd refused to start because mountd was segfaulting. I didn't play much with this setup, because I was in a hurry, so I commented out NFSD and put back NFSSERVER, to be able to test my server. Now a last question: Does gssapi/nfs setup work with the automounter (bsd/linux nfs-client)? Thanx again for your answer. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 18:16:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FDFB106568D for ; Mon, 8 Feb 2010 18:16: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 F3C848FC13 for ; Mon, 8 Feb 2010 18:16:16 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8FEC846B1A; Mon, 8 Feb 2010 13:16:16 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id BCF438A021; Mon, 8 Feb 2010 13:16:15 -0500 (EST) From: John Baldwin To: Kostik Belousov Date: Mon, 8 Feb 2010 13:15:06 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B6B89E7.8030002@sdf.lonestar.org> <201002081032.37841.jhb@freebsd.org> <20100208160600.GN9991@deviant.kiev.zoral.com.ua> In-Reply-To: <20100208160600.GN9991@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201002081315.06445.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 08 Feb 2010 13:16:15 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Tom McLaughlin , freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 18:16:17 -0000 On Monday 08 February 2010 11:06:00 am Kostik Belousov wrote: > On Mon, Feb 08, 2010 at 10:32:37AM -0500, John Baldwin wrote: > > On Monday 08 February 2010 9:56:36 am Kostik Belousov wrote: > > > On Mon, Feb 08, 2010 at 09:49:00AM -0500, John Baldwin wrote: > > > > On Saturday 06 February 2010 4:47:16 pm Tom McLaughlin wrote: > > > > > John Baldwin wrote, On 02/05/2010 08:27 AM: > > > > > > On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: > > > > > >> Hi all, a recent MFC to 7-STABLE has started to cause issues for my VMs > > > > > >> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk > > > > > >> controller the VM just shuts off. The workaround is to change the disk > > > > > >> controller to the BusLogic type. Still, it used to work up until last > > > > > >> week. The change was made around January 26th and based on the commits > > > > > >> that day I'm guessing it's either r203047 or r203073 > > > > > >> > > > > > >> I have the same issue with both amd64 and i386 VMs. This affects HEAD > > > > > >> and 8-STABLE as well and first affected HEAD over the summer. (I just > > > > > >> worked around it and went about my business at the time. :-/) I've > > > > > >> attached a dmesg from a kernel before the problem and one from after it > > > > > >> started. > > > > > > > > > > > > What if you set 'hw.clfush_disable=1' from the loader? > > > > > > > > > > > > > > > > Yes, that corrected it on all my VMs. I've talked to people on ESXi 4 > > > > > and they do not see the problem. I have yet to try 3.5u5 to see if this > > > > > is a non-issue. 3.5 will be supported for awhile longer from VMware. > > > > > I'm going to try upgrading the box during the week. > > > > > > > > I believe folks had to do this on HEAD/8.x as well. Perhaps we can > > > > automatically disable clflush if we are executing under VMware or Xen: > > > > > > > > Index: amd64/amd64/initcpu.c > > > > =================================================================== > > > > --- amd64/amd64/initcpu.c (revision 203430) > > > > +++ amd64/amd64/initcpu.c (working copy) > > > > @@ -177,17 +177,16 @@ > > > > if ((cpu_feature & CPUID_CLFSH) != 0) > > > > cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; > > > > /* > > > > - * XXXKIB: (temporary) hack to work around traps generated when > > > > - * CLFLUSHing APIC registers window. > > > > + * XXXKIB: (temporary) hack to work around traps generated > > > > + * when CLFLUSHing APIC registers window under virtualization > > > > + * environments. > > > > */ > > > > TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > > > > - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && > > > > - hw_clflush_disable == -1) > > > > + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) > > > > cpu_feature &= ~CPUID_CLFSH; > > > > /* > > > > * Allow to disable CLFLUSH feature manually by > > > > - * hw.clflush_disable tunable. This may help Xen guest on some AMD > > > > - * CPUs. > > > > + * hw.clflush_disable tunable. > > > > */ > > > > if (hw_clflush_disable == 1) > > > > cpu_feature &= ~CPUID_CLFSH; > > > > Index: i386/i386/initcpu.c > > > > =================================================================== > > > > --- i386/i386/initcpu.c (revision 203430) > > > > +++ i386/i386/initcpu.c (working copy) > > > > @@ -724,17 +724,16 @@ > > > > if ((cpu_feature & CPUID_CLFSH) != 0) > > > > cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; > > > > /* > > > > - * XXXKIB: (temporary) hack to work around traps generated when > > > > - * CLFLUSHing APIC registers window. > > > > + * XXXKIB: (temporary) hack to work around traps generated > > > > + * when CLFLUSHing APIC registers window under virtualization > > > > + * environments. > > > > */ > > > > TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > > > > - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && > > > > - hw_clflush_disable == -1) > > > > + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) > > > > cpu_feature &= ~CPUID_CLFSH; > > > > /* > > > > * Allow to disable CLFLUSH feature manually by > > > > - * hw.clflush_disable tunable. This may help Xen guest on some AMD > > > > - * CPUs. > > > > + * hw.clflush_disable tunable. > > > > */ > > > > if (hw_clflush_disable == 1) > > > > cpu_feature &= ~CPUID_CLFSH; > > > > > > It might be better to "or" old condition, i.e. Intel without SS, and > > > new one, vm_guest != 0, instead of replacing the old ? > > > > I thought the old condition only happened under VMware? > > Reports I got where from XEN. Ok. Those would also be covered under the vm_guest test as it is non-zero for Xen, VMware, Parallels, etc. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 18:51:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EC771065672; Mon, 8 Feb 2010 18:51:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D5CE28FC08; Mon, 8 Feb 2010 18:51:51 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o18IplY2034992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 20:51:47 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o18IpkcQ074553; Mon, 8 Feb 2010 20:51:46 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o18IpkNN074552; Mon, 8 Feb 2010 20:51:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Feb 2010 20:51:46 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20100208185146.GO9991@deviant.kiev.zoral.com.ua> References: <4B6B89E7.8030002@sdf.lonestar.org> <201002081032.37841.jhb@freebsd.org> <20100208160600.GN9991@deviant.kiev.zoral.com.ua> <201002081315.06445.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ZQ/M1iA+qg8otEW" Content-Disposition: inline In-Reply-To: <201002081315.06445.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Tom McLaughlin , freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 18:51:52 -0000 --4ZQ/M1iA+qg8otEW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 08, 2010 at 01:15:06PM -0500, John Baldwin wrote: > On Monday 08 February 2010 11:06:00 am Kostik Belousov wrote: > > On Mon, Feb 08, 2010 at 10:32:37AM -0500, John Baldwin wrote: > > > On Monday 08 February 2010 9:56:36 am Kostik Belousov wrote: > > > > On Mon, Feb 08, 2010 at 09:49:00AM -0500, John Baldwin wrote: > > > > > On Saturday 06 February 2010 4:47:16 pm Tom McLaughlin wrote: > > > > > > John Baldwin wrote, On 02/05/2010 08:27 AM: > > > > > > > On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: > > > > > > >> Hi all, a recent MFC to 7-STABLE has started to cause issues= for=20 > my VMs > > > > > > >> on VMware ESXi 3.5u4. After loading the mpt driver for the = LSI=20 > disk > > > > > > >> controller the VM just shuts off. The workaround is to chan= ge=20 > the disk > > > > > > >> controller to the BusLogic type. Still, it used to work up = until=20 > last > > > > > > >> week. The change was made around January 26th and based on = the=20 > commits > > > > > > >> that day I'm guessing it's either r203047 or r203073 > > > > > > >> > > > > > > >> I have the same issue with both amd64 and i386 VMs. This af= fects=20 > HEAD > > > > > > >> and 8-STABLE as well and first affected HEAD over the summer= . (I=20 > just > > > > > > >> worked around it and went about my business at the time. :-/= ) =20 > I've > > > > > > >> attached a dmesg from a kernel before the problem and one fr= om=20 > after it > > > > > > >> started. > > > > > > >=20 > > > > > > > What if you set 'hw.clfush_disable=3D1' from the loader? > > > > > > >=20 > > > > > >=20 > > > > > > Yes, that corrected it on all my VMs. I've talked to people on= ESXi=20 > 4 > > > > > > and they do not see the problem. I have yet to try 3.5u5 to se= e if=20 > this > > > > > > is a non-issue. 3.5 will be supported for awhile longer from= =20 > VMware. > > > > > > I'm going to try upgrading the box during the week. > > > > >=20 > > > > > I believe folks had to do this on HEAD/8.x as well. Perhaps we c= an=20 > > > > > automatically disable clflush if we are executing under VMware or= Xen: > > > > >=20 > > > > > Index: amd64/amd64/initcpu.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 > > > > > --- amd64/amd64/initcpu.c (revision 203430) > > > > > +++ amd64/amd64/initcpu.c (working copy) > > > > > @@ -177,17 +177,16 @@ > > > > > if ((cpu_feature & CPUID_CLFSH) !=3D 0) > > > > > cpu_clflush_line_size =3D ((cpu_procinfo >> 8) & 0xff) * 8; > > > > > /* > > > > > - * XXXKIB: (temporary) hack to work around traps generated when > > > > > - * CLFLUSHing APIC registers window. > > > > > + * XXXKIB: (temporary) hack to work around traps generated > > > > > + * when CLFLUSHing APIC registers window under virtualization > > > > > + * environments. > > > > > */ > > > > > TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > > > > > - if (cpu_vendor_id =3D=3D CPU_VENDOR_INTEL && !(cpu_feature & CP= UID_SS)=20 > && > > > > > - hw_clflush_disable =3D=3D -1) > > > > > + if (vm_guest !=3D 0 /* VM_GUEST_NO */ && hw_clflush_disable =3D= =3D -1) > > > > > cpu_feature &=3D ~CPUID_CLFSH; > > > > > /* > > > > > * Allow to disable CLFLUSH feature manually by > > > > > - * hw.clflush_disable tunable. This may help Xen guest on some= AMD > > > > > - * CPUs. > > > > > + * hw.clflush_disable tunable. > > > > > */ > > > > > if (hw_clflush_disable =3D=3D 1) > > > > > cpu_feature &=3D ~CPUID_CLFSH; > > > > > Index: i386/i386/initcpu.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 > > > > > --- i386/i386/initcpu.c (revision 203430) > > > > > +++ i386/i386/initcpu.c (working copy) > > > > > @@ -724,17 +724,16 @@ > > > > > if ((cpu_feature & CPUID_CLFSH) !=3D 0) > > > > > cpu_clflush_line_size =3D ((cpu_procinfo >> 8) & 0xff) * 8; > > > > > /* > > > > > - * XXXKIB: (temporary) hack to work around traps generated when > > > > > - * CLFLUSHing APIC registers window. > > > > > + * XXXKIB: (temporary) hack to work around traps generated > > > > > + * when CLFLUSHing APIC registers window under virtualization > > > > > + * environments. > > > > > */ > > > > > TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > > > > > - if (cpu_vendor_id =3D=3D CPU_VENDOR_INTEL && !(cpu_feature & CP= UID_SS)=20 > && > > > > > - hw_clflush_disable =3D=3D -1) > > > > > + if (vm_guest !=3D 0 /* VM_GUEST_NO */ && hw_clflush_disable =3D= =3D -1) > > > > > cpu_feature &=3D ~CPUID_CLFSH; > > > > > /* > > > > > * Allow to disable CLFLUSH feature manually by > > > > > - * hw.clflush_disable tunable. This may help Xen guest on some= AMD > > > > > - * CPUs. > > > > > + * hw.clflush_disable tunable. > > > > > */ > > > > > if (hw_clflush_disable =3D=3D 1) > > > > > cpu_feature &=3D ~CPUID_CLFSH; > > > >=20 > > > > It might be better to "or" old condition, i.e. Intel without SS, and > > > > new one, vm_guest !=3D 0, instead of replacing the old ? > > >=20 > > > I thought the old condition only happened under VMware? > >=20 > > Reports I got where from XEN. >=20 > Ok. Those would also be covered under the vm_guest test as it is > non-zero for Xen, VMware, Parallels, etc. What I said was suggestion and not objection. Ignore me. --4ZQ/M1iA+qg8otEW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktwXUIACgkQC3+MBN1Mb4jJiwCbBk2nq4+qqLeYoyRfviecLe1L sbUAoJ/t8OrLyHBWnRBX1AtJz36wGwoJ =sClO -----END PGP SIGNATURE----- --4ZQ/M1iA+qg8otEW-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 19:02:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C78C1065676; Mon, 8 Feb 2010 19:02:55 +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 CA68A8FC19; Mon, 8 Feb 2010 19:02:54 +0000 (UTC) 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 <1NeYsn-0005uD-P0>; Mon, 08 Feb 2010 20:02:53 +0100 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 <1NeYsn-0001Wk-NJ>; Mon, 08 Feb 2010 20:02:53 +0100 Message-ID: <4B706038.3030603@zedat.fu-berlin.de> Date: Mon, 08 Feb 2010 19:04:24 +0000 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100206 Thunderbird/3.0.1 MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <4B701269.9070703@zedat.fu-berlin.de> <20100208172033.112629f7@ernst.jennejohn.org> In-Reply-To: <20100208172033.112629f7@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: Re: www/firefox: Firefox 3.6 crashes, Firefox 3.5.7 not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 19:02:55 -0000 On 02/08/10 16:20, Gary Jennejohn wrote: > On Mon, 08 Feb 2010 13:32:25 +0000 > "O. Hartmann" wrote: > > >> Today, I upgraded Firefox 3.5.7 (built yesterday) to Firefox 3.6. After >> deleting ~/.mozilla (after I did a buckup, of course), I tried a fresh >> start of 'firefox3'. After firefox showed up, I realized that no >> option-field (File, Extras etc) can be used, they are dead and after a >> few seconds I clicked them, firefox3 is crashing. >> >> Since I recompiled firefox 3.5.7 yesterday I was wondering if this is >> due to some 'false' lib or dependency. Since I figured that I have >> similar trouble with Thunderbird 3.0.1 after I installed it, I suspect a >> faulty library causing this behaviour. With Thunderbird 3, I never >> solved the problem although I tried to rebuild everything with >> thunderbird via 'portmaster -f'. I'll did this with firefox 3.6 also, >> but with no success. >> >> The crashing is observed on two nearly identical SMP FreeBSD 8.0/amd64 >> STABLE boxes (make world of today), up-to-date ports. The crash is NOT >> observed on my private oldish UP box, nearly the same setup, OS at the >> same revision and ports up to date as of yesterday. Maybe this could be >> a hint. >> >> Any hints or suggestions? >> >> > Try doing "ldd /usr/local/lib/firefox3/firefox-bin" and see if anything > looks weird. > I did - and there is nothing weird. I checked the installed libraries and they are all rebuild when rebuilding necessary dependencies for firefox3. > You can porbably ignore > /usr/local/lib/firefox3/firefox-bin: > libxul.so => not found (0x0) > libmozjs.so => not found (0x0) > libxpcom.so => not found (0x0) > because run-mozilla.sh sets LD_LIBRARY_PATH to include > /usr/local/lib/firefox3 where these libraries are installed. > > I merely deleted my old firefox 3.6 and reinstalled from the port (on > 9-CURRENT AMD64) and haven't seen any problems. But of course, I've > been running various incarnations of 3.6 for a while and may have gotten > all the dependencies already correctly installed. > > --- > Gary Jennejohn > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > I tried again, left the 'make config'-options as they were set by default, delete/backuped .mozilla in my home and they restartet firefox3. Nothing better than previously seen. Try hitting Button 'Tools' at the top menu bar gives a menu after several seconds, then firefox crashes/core dumps. Oliver From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 19:42:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1BD51065670 for ; Mon, 8 Feb 2010 19:42:44 +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 925E78FC18 for ; Mon, 8 Feb 2010 19:42:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2DBDC46B35; Mon, 8 Feb 2010 14:42:44 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 685E38A01F; Mon, 8 Feb 2010 14:42:43 -0500 (EST) From: John Baldwin To: Kostik Belousov Date: Mon, 8 Feb 2010 14:42:33 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B6B89E7.8030002@sdf.lonestar.org> <201002081315.06445.jhb@freebsd.org> <20100208185146.GO9991@deviant.kiev.zoral.com.ua> In-Reply-To: <20100208185146.GO9991@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201002081442.33579.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 08 Feb 2010 14:42:43 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Tom McLaughlin , freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 19:42:44 -0000 On Monday 08 February 2010 1:51:46 pm Kostik Belousov wrote: > On Mon, Feb 08, 2010 at 01:15:06PM -0500, John Baldwin wrote: > > On Monday 08 February 2010 11:06:00 am Kostik Belousov wrote: > > > On Mon, Feb 08, 2010 at 10:32:37AM -0500, John Baldwin wrote: > > > > On Monday 08 February 2010 9:56:36 am Kostik Belousov wrote: > > > > > On Mon, Feb 08, 2010 at 09:49:00AM -0500, John Baldwin wrote: > > > > > > On Saturday 06 February 2010 4:47:16 pm Tom McLaughlin wrote: > > > > > > > John Baldwin wrote, On 02/05/2010 08:27 AM: > > > > > > > > On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: > > > > > > > >> Hi all, a recent MFC to 7-STABLE has started to cause issues for > > my VMs > > > > > > > >> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI > > disk > > > > > > > >> controller the VM just shuts off. The workaround is to change > > the disk > > > > > > > >> controller to the BusLogic type. Still, it used to work up until > > last > > > > > > > >> week. The change was made around January 26th and based on the > > commits > > > > > > > >> that day I'm guessing it's either r203047 or r203073 > > > > > > > >> > > > > > > > >> I have the same issue with both amd64 and i386 VMs. This affects > > HEAD > > > > > > > >> and 8-STABLE as well and first affected HEAD over the summer. (I > > just > > > > > > > >> worked around it and went about my business at the time. :-/) > > I've > > > > > > > >> attached a dmesg from a kernel before the problem and one from > > after it > > > > > > > >> started. > > > > > > > > > > > > > > > > What if you set 'hw.clfush_disable=1' from the loader? > > > > > > > > > > > > > > > > > > > > > > Yes, that corrected it on all my VMs. I've talked to people on ESXi > > 4 > > > > > > > and they do not see the problem. I have yet to try 3.5u5 to see if > > this > > > > > > > is a non-issue. 3.5 will be supported for awhile longer from > > VMware. > > > > > > > I'm going to try upgrading the box during the week. > > > > > > > > > > > > I believe folks had to do this on HEAD/8.x as well. Perhaps we can > > > > > > automatically disable clflush if we are executing under VMware or Xen: > > > > > > > > > > > > Index: amd64/amd64/initcpu.c > > > > > > =================================================================== > > > > > > --- amd64/amd64/initcpu.c (revision 203430) > > > > > > +++ amd64/amd64/initcpu.c (working copy) > > > > > > @@ -177,17 +177,16 @@ > > > > > > if ((cpu_feature & CPUID_CLFSH) != 0) > > > > > > cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; > > > > > > /* > > > > > > - * XXXKIB: (temporary) hack to work around traps generated when > > > > > > - * CLFLUSHing APIC registers window. > > > > > > + * XXXKIB: (temporary) hack to work around traps generated > > > > > > + * when CLFLUSHing APIC registers window under virtualization > > > > > > + * environments. > > > > > > */ > > > > > > TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > > > > > > - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) > > && > > > > > > - hw_clflush_disable == -1) > > > > > > + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) > > > > > > cpu_feature &= ~CPUID_CLFSH; > > > > > > /* > > > > > > * Allow to disable CLFLUSH feature manually by > > > > > > - * hw.clflush_disable tunable. This may help Xen guest on some AMD > > > > > > - * CPUs. > > > > > > + * hw.clflush_disable tunable. > > > > > > */ > > > > > > if (hw_clflush_disable == 1) > > > > > > cpu_feature &= ~CPUID_CLFSH; > > > > > > Index: i386/i386/initcpu.c > > > > > > =================================================================== > > > > > > --- i386/i386/initcpu.c (revision 203430) > > > > > > +++ i386/i386/initcpu.c (working copy) > > > > > > @@ -724,17 +724,16 @@ > > > > > > if ((cpu_feature & CPUID_CLFSH) != 0) > > > > > > cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; > > > > > > /* > > > > > > - * XXXKIB: (temporary) hack to work around traps generated when > > > > > > - * CLFLUSHing APIC registers window. > > > > > > + * XXXKIB: (temporary) hack to work around traps generated > > > > > > + * when CLFLUSHing APIC registers window under virtualization > > > > > > + * environments. > > > > > > */ > > > > > > TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > > > > > > - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) > > && > > > > > > - hw_clflush_disable == -1) > > > > > > + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) > > > > > > cpu_feature &= ~CPUID_CLFSH; > > > > > > /* > > > > > > * Allow to disable CLFLUSH feature manually by > > > > > > - * hw.clflush_disable tunable. This may help Xen guest on some AMD > > > > > > - * CPUs. > > > > > > + * hw.clflush_disable tunable. > > > > > > */ > > > > > > if (hw_clflush_disable == 1) > > > > > > cpu_feature &= ~CPUID_CLFSH; > > > > > > > > > > It might be better to "or" old condition, i.e. Intel without SS, and > > > > > new one, vm_guest != 0, instead of replacing the old ? > > > > > > > > I thought the old condition only happened under VMware? > > > > > > Reports I got where from XEN. > > > > Ok. Those would also be covered under the vm_guest test as it is > > non-zero for Xen, VMware, Parallels, etc. > > What I said was suggestion and not objection. Ignore me. Were there any reports of problems with Intel CPUs that weren't under a virtualization system? If so, we should keep the test, but my understanding was that the test was only true under specific virtualization environments. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 19:46:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59C751065670; Mon, 8 Feb 2010 19:46:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BA6158FC1E; Mon, 8 Feb 2010 19:46:58 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o18JkpF6039832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 21:46:51 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o18JkpbU074955; Mon, 8 Feb 2010 21:46:51 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o18JkpI5074954; Mon, 8 Feb 2010 21:46:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Feb 2010 21:46:51 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20100208194651.GP9991@deviant.kiev.zoral.com.ua> References: <4B6B89E7.8030002@sdf.lonestar.org> <201002081315.06445.jhb@freebsd.org> <20100208185146.GO9991@deviant.kiev.zoral.com.ua> <201002081442.33579.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3loezlmesXOUD0D5" Content-Disposition: inline In-Reply-To: <201002081442.33579.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Tom McLaughlin , freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 19:46:59 -0000 --3loezlmesXOUD0D5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 08, 2010 at 02:42:33PM -0500, John Baldwin wrote: > On Monday 08 February 2010 1:51:46 pm Kostik Belousov wrote: > > On Mon, Feb 08, 2010 at 01:15:06PM -0500, John Baldwin wrote: > > > > > I thought the old condition only happened under VMware? > > > >=20 > > > > Reports I got where from XEN. > > >=20 > > > Ok. Those would also be covered under the vm_guest test as it is > > > non-zero for Xen, VMware, Parallels, etc. > >=20 > > What I said was suggestion and not objection. Ignore me. >=20 > Were there any reports of problems with Intel CPUs that weren't under a= =20 > virtualization system? If so, we should keep the test, but my understand= ing=20 > was that the test was only true under specific virtualization environment= s. Forcing Intel CPU to use CLFLUSH, by clearing SS bit, caused reserved trap on Pentium M at least. My concern is that if Intel makes some stripped-down CPU with CLFLUSH but without SS logic, we would be affected. --3loezlmesXOUD0D5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktwaioACgkQC3+MBN1Mb4j7NQCg2vzX6SmnuV/PvJFHrCpaBhL7 pAQAoI1mFd+HsRCaNvUPtosZ3XRldJ02 =/ChU -----END PGP SIGNATURE----- --3loezlmesXOUD0D5-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 19:48:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2326106568B for ; Mon, 8 Feb 2010 19:48:30 +0000 (UTC) (envelope-from st0ma@sofiahouse.net) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id 5E79A8FC1A for ; Mon, 8 Feb 2010 19:48:30 +0000 (UTC) Received: by bwz3 with SMTP id 3so1005388bwz.13 for ; Mon, 08 Feb 2010 11:48:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.80.32 with SMTP id h32mr338639mul.59.1265658509199; Mon, 08 Feb 2010 11:48:29 -0800 (PST) In-Reply-To: <147432021002051039s16c72988n95e80f2e9ede0955@mail.gmail.com> References: <331b660a1002050941y256e3343i65afe78df5eba4e5@mail.gmail.com> <147432021002051039s16c72988n95e80f2e9ede0955@mail.gmail.com> Date: Mon, 8 Feb 2010 21:48:29 +0200 Message-ID: <331b660a1002081148r572e43d1k88d18f0ef83d64b2@mail.gmail.com> From: Spas Karabelov To: Nick Rogers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: PF Traffic Redirection issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 19:48:30 -0000 Thanks for the info Nick, I had the reflection working with PF + Inetd + NC. *in the inetd.conf I have the following:* #INTERNAL NC CONFIGURATION http stream tcp nowait root /usr/bin/nc nc -w 20 192.168.128.102 80 *in rc.conf in had to add the following to limit the proxy listening on the localhost Only:* inetd_flags="-wW -a 127.0.0.1" *the PF configuration is as follows:* TRANSLATION RULES: rdr pass on em0 inet proto tcp from any to 192.168.128.170 port = http -> 127.0.0.1 port 80 FILTER RULES: block drop log all pass in on lo0 inet6 proto tcp from any to fe80::1 port = http flags S/SA keep state pass in on lo0 inet6 proto tcp from any to ::1 port = http flags S/SA keep state pass in on lo0 inet proto tcp from any to 127.0.0.1 port = http flags S/SA keep state pass in on em0 inet proto tcp from any to 192.168.128.170 port = ssh flags S/SA keep state pass out all flags S/SA keep state Thanks for the heads up. Hope this works for someone. KR, Spas On Fri, Feb 5, 2010 at 8:39 PM, Nick Rogers wrote: > > > On Fri, Feb 5, 2010 at 9:41 AM, Spas Karabelov wrote: > >> Hello, >> >> I am trying to perform traffic redirection with PF on 7.2-RELEASE. >> The traffic is in the same subnet and I try doing that by using just one >> interface em0. > > > PF cannot redirect packets back out the interface they originated on. > > From pf.conf(5)... > > "Redirections cannot reflect packets back through the interface they arrive > on, they can only be redirected to hosts connected to different interfaces > or > to the firewall itself." > From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 19:56:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 767E51065692 for ; Mon, 8 Feb 2010 19:56:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 5D64A8FC1D for ; Mon, 8 Feb 2010 19:56:21 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta15.emeryville.ca.mail.comcast.net with comcast id fXj61d00E1smiN4AFXwNSi; Mon, 08 Feb 2010 19:56:22 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id fXwN1d0043S48mS8gXwNCT; Mon, 08 Feb 2010 19:56:22 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 092C11E3033; Mon, 8 Feb 2010 11:56:21 -0800 (PST) Date: Mon, 8 Feb 2010 11:56:21 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100208195620.GA10209@icarus.home.lan> References: <20100208143329.GA12057@megatron.madpilot.net> <20100208145147.GA3733@icarus.home.lan> <20100208171822.12773278@r500.local> <20100208165853.GA43617@megatron.madpilot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100208165853.GA43617@megatron.madpilot.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ATA_CAM + ZFS gives short 1-2 seconds system freeze on disk load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 19:56:22 -0000 On Mon, Feb 08, 2010 at 05:58:53PM +0100, Guido Falsi wrote: > On Mon, Feb 08, 2010 at 05:18:22PM +0100, Fabian Keil wrote: > > > > I experienced what I think is the same problem. ZFS's bulk disk flushes > > caused vlc to occasionally stutter when viewing a DVD rip from disk while > > ripping a DVD at the same time. > > > > My workaround is to put "vfs.zfs.txg.timeout=3" in /boot/loader.conf. > > I think I read about this on zfs-discuss@. I assume on faster systems > > one can use a higher value. > > This was a very good idea. I'm trying this and the system freezes much > less if at all. > > Are there any drawbacks I should be aware of? > > I can imagine that forcing more disk writes somewhat slows down normal > disk activity, but I can bear that on a desktop system. I'd like a technical explanation of exactly what this loader.conf tunable does. The sysctl -d explanation is useful if one has insight to what purpose it serves. I can find mention on Solaris lists about "txg timeout", but the context is over my head (intended for those very familiar with the inner workings of ZFS). I'd also like to know what vfs.zfs.txg.synctime does. I've been playing with vfs.zfs.txg.timeout (decreasing it from 30 to 5) and testing on a 3-disk raidz1 pool on a test machine I have, but I haven't finished my testing yet. A person said that decreasing the value increased throughput[1] for them, but in my brief test (using dd) it doesn't appear to improve I/O speed at all. Anyone know of a good (non-X-related) repro test case which can induce the ZFS "bursty sluggishness" problem so I can try it with different loader.conf tunables? Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 20:05:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B50E210656AA for ; Mon, 8 Feb 2010 20:05:45 +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 855AF8FC20 for ; Mon, 8 Feb 2010 20:05:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 380C946B0C; Mon, 8 Feb 2010 15:05:45 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 7B7C98A01F; Mon, 8 Feb 2010 15:05:44 -0500 (EST) From: John Baldwin To: Kostik Belousov Date: Mon, 8 Feb 2010 15:05:35 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B6B89E7.8030002@sdf.lonestar.org> <201002081442.33579.jhb@freebsd.org> <20100208194651.GP9991@deviant.kiev.zoral.com.ua> In-Reply-To: <20100208194651.GP9991@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201002081505.35643.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 08 Feb 2010 15:05:44 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Tom McLaughlin , freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 20:05:45 -0000 On Monday 08 February 2010 2:46:51 pm Kostik Belousov wrote: > On Mon, Feb 08, 2010 at 02:42:33PM -0500, John Baldwin wrote: > > On Monday 08 February 2010 1:51:46 pm Kostik Belousov wrote: > > > On Mon, Feb 08, 2010 at 01:15:06PM -0500, John Baldwin wrote: > > > > > > I thought the old condition only happened under VMware? > > > > > > > > > > Reports I got where from XEN. > > > > > > > > Ok. Those would also be covered under the vm_guest test as it is > > > > non-zero for Xen, VMware, Parallels, etc. > > > > > > What I said was suggestion and not objection. Ignore me. > > > > Were there any reports of problems with Intel CPUs that weren't under a > > virtualization system? If so, we should keep the test, but my understanding > > was that the test was only true under specific virtualization environments. > > Forcing Intel CPU to use CLFLUSH, by clearing SS bit, caused > reserved trap on Pentium M at least. My concern is that if Intel > makes some stripped-down CPU with CLFLUSH but without SS logic, > we would be affected. Hmm, I am content to just workaround things that we know are broken for enough. There are an infinite number of possibilities as far as if future products may be broken. I think for that case we should wait and add a workaround to disable it as new parts that are broken become available. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 22:05:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C90CC1065679 for ; Mon, 8 Feb 2010 22:05:26 +0000 (UTC) (envelope-from eitanadlerlist@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 500CE8FC0A for ; Mon, 8 Feb 2010 22:05:26 +0000 (UTC) Received: by fxm26 with SMTP id 26so1166578fxm.13 for ; Mon, 08 Feb 2010 14:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=nw2qOlqrsadMnuXaDv4mZeccpI1ExgiI7hM1xGywRCs=; b=n0nd3qvfd+3iLq+vy4WU+cfcZ75un7cAWxBnbW4BQgeBH8JYdDFBSZo3mx2kzoUj8L H5KAlZGd8aneUTTj5UNxGjeH0nXGAq5q7sLV9mKe0h8RtVCOLP9x0uxfEU0po7pOpAHO 4/hc9qydbMmatM/MA1xnB1Y7K1P4CM2uw9A0s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=F8choW6mpjA6KudJb9awLv+5FZxETXKouvF1z6DFXhrgXeTwwWSxVnlo6D99kWWeMm QlKqEHvIdz1+jWf57YiDgBLwp+2hSejkHGWuguMMfof6z8xjW5Un/eZ/fs5tfoUApr5g FB4g+gk7z6Ypq9/WkjYiTx0GANbTxcbdk99yo= MIME-Version: 1.0 Received: by 10.239.189.137 with SMTP id t9mr758272hbh.176.1265665395224; Mon, 08 Feb 2010 13:43:15 -0800 (PST) In-Reply-To: <4B706038.3030603@zedat.fu-berlin.de> References: <4B701269.9070703@zedat.fu-berlin.de> <20100208172033.112629f7@ernst.jennejohn.org> <4B706038.3030603@zedat.fu-berlin.de> From: Eitan Adler Date: Mon, 8 Feb 2010 23:42:55 +0200 Message-ID: To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, gary.jennejohn@freenet.de, freebsd-ports@freebsd.org Subject: Re: www/firefox: Firefox 3.6 crashes, Firefox 3.5.7 not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 22:05:26 -0000 I have no idea if this is related but from pkg-message Firefox 3.6 and HTML5 Certain functions used to display HTML5 elements need the sem module. If your Firefox crashes with the following message while viewing a HTML5 page: "Bad system call (core dumped)" you need to load the sem module (kldload sem). To load sem on every boot put the following into your /boot/loader.conf: sem_load="YES" On Mon, Feb 8, 2010 at 9:04 PM, O. Hartmann wrote: > On 02/08/10 16:20, Gary Jennejohn wrote: > >> On Mon, 08 Feb 2010 13:32:25 +0000 >> "O. Hartmann" wrote: >> >> >> >>> Today, I upgraded Firefox 3.5.7 (built yesterday) to Firefox 3.6. After >>> deleting ~/.mozilla (after I did a buckup, of course), I tried a fresh >>> start of 'firefox3'. After firefox showed up, I realized that no >>> option-field (File, Extras etc) can be used, they are dead and after a >>> few seconds I clicked them, firefox3 is crashing. >>> >>> Since I recompiled firefox 3.5.7 yesterday I was wondering if this is >>> due to some 'false' lib or dependency. Since I figured that I have >>> similar trouble with Thunderbird 3.0.1 after I installed it, I suspect a >>> faulty library causing this behaviour. With Thunderbird 3, I never >>> solved the problem although I tried to rebuild everything with >>> thunderbird via 'portmaster -f'. I'll did this with firefox 3.6 also, >>> but with no success. >>> >>> The crashing is observed on two nearly identical SMP FreeBSD 8.0/amd64 >>> STABLE boxes (make world of today), up-to-date ports. The crash is NOT >>> observed on my private oldish UP box, nearly the same setup, OS at the >>> same revision and ports up to date as of yesterday. Maybe this could be >>> a hint. >>> >>> Any hints or suggestions? >>> >>> >>> >> Try doing "ldd /usr/local/lib/firefox3/firefox-bin" and see if anything >> looks weird. >> >> > I did - and there is nothing weird. > > I checked the installed libraries and they are all rebuild when rebuilding > necessary dependencies for firefox3. > > > You can porbably ignore >> /usr/local/lib/firefox3/firefox-bin: >> libxul.so => not found (0x0) >> libmozjs.so => not found (0x0) >> libxpcom.so => not found (0x0) >> because run-mozilla.sh sets LD_LIBRARY_PATH to include >> /usr/local/lib/firefox3 where these libraries are installed. >> >> I merely deleted my old firefox 3.6 and reinstalled from the port (on >> 9-CURRENT AMD64) and haven't seen any problems. But of course, I've >> been running various incarnations of 3.6 for a while and may have gotten >> all the dependencies already correctly installed. >> >> --- >> Gary Jennejohn >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> > > I tried again, left the 'make config'-options as they were set by default, > delete/backuped .mozilla in my home and they restartet firefox3. Nothing > better than previously seen. Try hitting Button 'Tools' at the top menu bar > gives a menu after several seconds, then firefox crashes/core dumps. > > Oliver > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 22:17:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BCD4106568F; Mon, 8 Feb 2010 22:17:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id A188E8FC2B; Mon, 8 Feb 2010 22:17:42 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALMbcEuDaFvJ/2dsb2JhbADXHIRUBA X-IronPort-AV: E=Sophos;i="4.49,432,1262581200"; d="scan'208";a="64833033" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 08 Feb 2010 17:17:41 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 9E7F8FB808C; Mon, 8 Feb 2010 17:17:41 -0500 (EST) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJOpihBQ2MjL; Mon, 8 Feb 2010 17:17:40 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id D5A97FB8039; Mon, 8 Feb 2010 17:17:40 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o18MSvt17944; Mon, 8 Feb 2010 17:28:57 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 8 Feb 2010 17:28:57 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "O. Hartmann" In-Reply-To: <4B704804.4030802@zedat.fu-berlin.de> Message-ID: References: <4B6FE550.9020506@zedat.fu-berlin.de> <4B704804.4030802@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: NFSv4: mount -t nsf4 not the same as mount_newnfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 22:17:43 -0000 On Mon, 8 Feb 2010, O. Hartmann wrote: >> >> Oh, and you should set: >> sysctl vfs.newnfs.locallocks_enable=0 >> in the server, since I haven't fixed the local locking yet. (This implies >> that apps/daemons running locally on the server won't see byte range >> locks performed by NFSv4 clients.) However, byte range locking between >> NFSv4 clients should work ok. >> > > Interesting, I see a lot of vfs.newfs-stuff on server-side, but not this > specific OID. Do I miss something here? > Oops, make that vfs.newnfs.enable_locallocks=0 rick From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 22:26:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 259AA1065672; Mon, 8 Feb 2010 22:26:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id B6A9E8FC1A; Mon, 8 Feb 2010 22:26:14 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAsecEuDaFvI/2dsb2JhbADXI4RUBA X-IronPort-AV: E=Sophos;i="4.49,431,1262581200"; d="scan'208";a="64834009" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 08 Feb 2010 17:26:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id BEF80940100; Mon, 8 Feb 2010 17:26:13 -0500 (EST) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yj9ugIEvLwp7; Mon, 8 Feb 2010 17:26:12 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id CA23F9400FE; Mon, 8 Feb 2010 17:26:12 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o18MbT018620; Mon, 8 Feb 2010 17:37:29 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 8 Feb 2010 17:37:29 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "O. Hartmann" In-Reply-To: <4B70497B.1000908@zedat.fu-berlin.de> Message-ID: References: <4B6FE550.9020506@zedat.fu-berlin.de> <4B70497B.1000908@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: NFSv4: mount -t nsf4 not the same as mount_newnfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 22:26:15 -0000 On Mon, 8 Feb 2010, O. Hartmann wrote: > > So I guess the above one is the more 'transparent' one with respect to the > future, when NFSv4 gets mature and its way as matured into the kernel? > Yea, I'd only use "mount -t newnfs" if for some reason you want to test/use the experimental client for nfsv2,3 instead of the regular one. > I tried the above and it works. But it seems, that only UFS2 filesystems can > be mounted by the client. When trying mounting a filesystem residing on ZFS, > it fails. Mounting works, but when try to access or doing a simple 'ls', I > get > > ls: /backup: Permission denied > > > On server side, /etc/exports looks like > > -- > V4: / -sec=sys:krb5 #IPv4# > > /backup #IPv4# > -- > > Is there still an issue with ZFS? > For ZFS, everything from the "root" specified by the "V4:" line must be exported at this time. So, if "/" isn't exported, the above won't work for ZFS. You can either export "/" or move the NFSv4 root down to backup. For example, you could try: V4: /backup -sec=sys:krb5 /backup (assuming /backup is the ZFS volume) and then a mount like: mount -t nfs -o nfsv4 server:/ /mnt will mount /backup on /mnt rick ps: ZFS also has its own export stuff, but it is my understanding that putting a line in /etc/exports is sufficient. I've never used ZFS, so others will know more than I. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 22:32:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C1C4106568B for ; Mon, 8 Feb 2010 22:32:32 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id B505F8FC18 for ; Mon, 8 Feb 2010 22:32:31 +0000 (UTC) Received: by iwn36 with SMTP id 36so1503246iwn.3 for ; Mon, 08 Feb 2010 14:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=r3moLBgYJtJbjcgQEfkDfVKDF8j5SPtR98jvQD2KYao=; b=aIhQms3mhas7IhTnGoVk3vvznUqbHWQN2BcwFhTGLna9esP3YjZaqMbsQVgMQ3jKPP HX5nujZcIXKH43CjxyhZkRIUcdKxnrjRTRNWzF3NXJ71JZfQ0hAl/i5ncxl/BmFtMh3f OYSFnCyKmLa4DjvQrqzH8NCzdx3aJkj5wbEQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=eFS/2ghhDy5I2qD6/cRy0x6I3i3q7sfm072VKV9BcSfLE8mGBdm98esSearQHr1t5p dCV1mUJZWI3gUeFZh65Rr5XqukyJHoquuXRVUzfKflKv+CQPc8pLL0Bied8vZfvtJjDy UKxdgFxXIUFJhHSHDkUc/bq08qbduqapBDafg= MIME-Version: 1.0 Received: by 10.231.159.207 with SMTP id k15mr3190505ibx.75.1265668350992; Mon, 08 Feb 2010 14:32:30 -0800 (PST) In-Reply-To: References: <4B6FE550.9020506@zedat.fu-berlin.de> <4B70497B.1000908@zedat.fu-berlin.de> Date: Mon, 8 Feb 2010 14:32:30 -0800 Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: NFSv4: mount -t nsf4 not the same as mount_newnfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 22:32:32 -0000 On Mon, Feb 8, 2010 at 2:37 PM, Rick Macklem wrote: > ps: ZFS also has its own export stuff, but it is my understanding that > putting a line in /etc/exports is sufficient. I've never used ZFS, > so others will know more than I. > My understanding (from having used NFS and ZFS, haven't looked at the code) is that: The sharenfs property for a ZFS dataset gets written out to /etc/zfs/exports, which gets appended to the mountd command-line by default. Thus, you can use /etc/exports or sharenfs property, whichever is easier. # zfs get sharenfs storage/backup NAME PROPERTY VALUE SOURCE storage/backup sharenfs -maproot=root 192.168.0.12 local # cat /etc/exports # cat /etc/zfs/exports # !!! DO NOT EDIT THIS FILE MANUALLY !!! /storage/backup -maproot=root 192.168.0.12 # pgrep -lf exports 1381 /usr/sbin/mountd -r -p 32000 /etc/exports /etc/zfs/exports -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 22:35:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3BED1065692; Mon, 8 Feb 2010 22:35:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 814568FC17; Mon, 8 Feb 2010 22:35:22 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANsgcEuDaFvJ/2dsb2JhbADJfwGNHYJfAYF0BA X-IronPort-AV: E=Sophos;i="4.49,432,1262581200"; d="scan'208";a="64707326" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 08 Feb 2010 17:35:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id DD484FB809C; Mon, 8 Feb 2010 17:35:08 -0500 (EST) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrNCMc0RFBEn; Mon, 8 Feb 2010 17:35:08 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 08873FB808D; Mon, 8 Feb 2010 17:35:08 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o18MkNS19638; Mon, 8 Feb 2010 17:46:24 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 8 Feb 2010 17:46:23 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: George Mamalakis In-Reply-To: <4B704ECD.1060902@eng.auth.gr> Message-ID: References: <4B6BE7A2.6000402@eng.auth.gr> <4B6D3A18.2030304@eng.auth.gr> <4B704ECD.1060902@eng.auth.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: Kerberized NFSv3 incorrect behavior X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 22:35:23 -0000 On Mon, 8 Feb 2010, George Mamalakis wrote: > > To tell you the truth, when I recompiled my kernel with: > > options NFSD > options KGSSAPI > device crypto > > to setup an nvsv4 server, nfsd refused to start because mountd was > segfaulting. I didn't play much with this setup, because I was in a hurry, so > I commented out NFSD and put back NFSSERVER, to be able to test my server. > Ok, I'll test the above case. It definitely should be fixed. > Now a last question: Does gssapi/nfs setup work with the automounter > (bsd/linux nfs-client)? > No idea. The Mac OS X client works ok with the automounter. The main issue I'm aware of is that, if you are automounting home directories, then the "kinit" has to happen before any access attempt to the home dir. occurs during the login sequence. (I've never tried to automount on either FreeBSD nor Linux.) Have fun, rick ps: The nfsv4@linux-nfs.org mailing list is a good place to ask, if you run into Linux client issues. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 22:38:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E5A51065672 for ; Mon, 8 Feb 2010 22:38:22 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id 22AC08FC0C for ; Mon, 8 Feb 2010 22:38:22 +0000 (UTC) Received: by iwn36 with SMTP id 36so1511535iwn.3 for ; Mon, 08 Feb 2010 14:38:21 -0800 (PST) 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=6e7W3Jh5Xd1dUYIMdRb5OF+jih2aEih67Vp+foL4MwY=; b=Sda5lmwUnRzIG9z9sve0U2VkHo6ePbdryZcR36Txn3NiyCq6KNaCRgAuKVGEb4+1Jk OMIXvyU0pjtJ/WrZTcW7+Kc2d9njEMisaW93GwnIMzFvmdA6ZN8aZkYRRpBm7LhJ9IWL AGmglGo6MZpfQNiv05rPq8T229eGJe71dotMk= 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=on//rAdf1WyrB0uKQ4QDGNQGhBCKzEcE9UYhi2jB0NeNZ7lS0OKziSG1HNbE7hcjOq goRHBVmfsDLHTHMbQDp4CL3gCE84htmPF+ICGJY/VU78wjjxdMz0mrNEfYRHLM3E/3QD 1remRWJs2XacAy5ev6zX2zjAFkNw/EqSa3ChE= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.191.135 with SMTP id dm7mr1227877ibb.46.1265668701542; Mon, 08 Feb 2010 14:38:21 -0800 (PST) In-Reply-To: <20100208195620.GA10209@icarus.home.lan> References: <20100208143329.GA12057@megatron.madpilot.net> <20100208145147.GA3733@icarus.home.lan> <20100208171822.12773278@r500.local> <20100208165853.GA43617@megatron.madpilot.net> <20100208195620.GA10209@icarus.home.lan> Date: Mon, 8 Feb 2010 14:38:21 -0800 X-Google-Sender-Auth: 81681c70a383cb33 Message-ID: From: Artem Belevich To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: ATA_CAM + ZFS gives short 1-2 seconds system freeze on disk load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 22:38:22 -0000 > I'd like a technical explanation of exactly what this loader.conf > tunable does. =A0The sysctl -d explanation is useful if one has insight t= o > what purpose it serves. =A0I can find mention on Solaris lists about "txg > timeout", but the context is over my head (intended for those very > familiar with the inner workings of ZFS). Ben Rockwood's blog has pretty decent explanation of how transaction groups in ZFS work: http://www.cuddletech.com/blog/pivot/entry.php?id=3D1015 --Artem From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 23:13:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 372131065679 for ; Mon, 8 Feb 2010 23:13:36 +0000 (UTC) (envelope-from christof.schulze@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 975618FC0A for ; Mon, 8 Feb 2010 23:13:35 +0000 (UTC) Received: (qmail invoked by alias); 08 Feb 2010 23:13:34 -0000 Received: from e181213141.adsl.alicedsl.de (EHLO klausdieter0815.dyndns.org) [85.181.213.141] by mail.gmx.com (mp-eu002) with SMTP; 09 Feb 2010 00:13:34 +0100 X-Authenticated: #56306756 X-Provags-ID: V01U2FsdGVkX19TKigklYFTLkA12knldyi+RDX6q9HERxQToA2sJq liQjkJ2pjhTmnZ Received: by myhost.mydomain.de (Postfix, from userid 1001) id 8C3187092; Tue, 9 Feb 2010 00:13:33 +0100 (CET) From: Christof Schulze To: freebsd-stable@freebsd.org Date: Tue, 9 Feb 2010 00:13:26 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1434020.8VnMdkaJn1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002090013.33363.christof.schulze@gmx.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64000000000000001 Cc: freebsd-acpi@freebsd.org Subject: suspend to disk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 23:13:36 -0000 --nextPart1434020.8VnMdkaJn1 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello everyone today I tried whether my samsung q35 laptop would suspend using acpiconf on= =20 RELENG_8. I was amazed that acpiconf -s3 works out of the box. However=20 acpiconf -s4 does not work which would be the useful side of hibernation fo= r=20 me. =46rom the manpage of acpiconf I understand that acpiconf -s4 should store = the=20 non-cache-parts from ram somewhere on disk. If called the system shuts down= =20 without writing much on the disk so something is odd there. I have 2,5 gb of ram and only 800MB of swap space which is labeled correctl= y. What do I have to do in order to make suspend to disk work? Is it possible to compress the contents of the ram like some programs from = the=20 linuxworld do it (tuxonice)? Or did I entirely miss some configuration here?=20 Please cc me while replying to this email as I am not on the freebsd-acpi=20 list. I do track -stable though. kind regards Christof =2D-=20 () ascii ribbon campaign - against html e-mail=20 /\ www.asciiribbon.org - against proprietary attachments --nextPart1434020.8VnMdkaJn1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEABECAAYFAktwmp0ACgkQpZfyPAmdZJmqcwCg4YH5a46PXhouYX3mNGHAs6Rt w5sAmwVvCxHDauJ5ivEObRyWucD4+SVM =5zXe -----END PGP SIGNATURE----- --nextPart1434020.8VnMdkaJn1-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 23:20:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40290106568B for ; Mon, 8 Feb 2010 23:20:40 +0000 (UTC) (envelope-from varga.michal@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id CAA978FC1C for ; Mon, 8 Feb 2010 23:20:39 +0000 (UTC) Received: by fxm26 with SMTP id 26so1228256fxm.13 for ; Mon, 08 Feb 2010 15:20:38 -0800 (PST) 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=BO3j7xKguYcw5lydUCsDZUG+1JMiMm+isSlDTp15C90=; b=CLzBq95h3vY9cn0qVx7JATHQjBlo991vhvmaZmEaUHCpEZmCAoIeNcjjtJD3AobO66 M9KNGqNNugi16jyCbNPE96PdpYgloTyw2tUpJ4Eg4Y4T0HJxMy2prsoRiSnMOZ7g0hFK F4HEPlBh5cIjieCcGztMA7uV8ogJMhu558+Kg= 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=OyuGk15XzndkpjPdt9s6ieiCOjFvXQnPwmt6reWeNnsCF4lzVamdmXgvzP4HKuX/Cq BWt25VsAHiyXINwjcOXbHjWT0QQTvIE2qO+VUf21grV0KsMre6mjh7x35OUYofpQZl2Y iBiSj/DSR54KiWwd43EYhZ7LeQBjzIS90lBQ8= MIME-Version: 1.0 Received: by 10.223.5.17 with SMTP id 17mr3080596fat.0.1265671238562; Mon, 08 Feb 2010 15:20:38 -0800 (PST) In-Reply-To: <201002090013.33363.christof.schulze@gmx.com> References: <201002090013.33363.christof.schulze@gmx.com> Date: Tue, 9 Feb 2010 00:20:38 +0100 Message-ID: <3f1fd1ea1002081520g128f1597j3ba2e44d208aca6c@mail.gmail.com> From: Michal Varga To: Christof Schulze Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: suspend to disk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 23:20:40 -0000 On Tue, Feb 9, 2010 at 12:13 AM, Christof Schulze wrote: > Hello everyone > > today I tried whether my samsung q35 laptop would suspend using acpiconf on > RELENG_8. I was amazed that acpiconf -s3 works out of the box. However > acpiconf -s4 does not work which would be the useful side of hibernation for > me. > http://www.freebsd.org/projects/acpi/ Excerpt: suspend to disk -- Implement a suspend/resume from disk mechanism. Possibly use the dump functions to dump pages to disk, then use ACPI to put the system in S4 or power-off. Resume would require changes to the loader to load the memory image directly and then begin executing again. -- Not done. Did anything change in recent years? m. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 8 23:24:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F2B61065672 for ; Mon, 8 Feb 2010 23:24:01 +0000 (UTC) (envelope-from pl@ninthfloor.org) Received: from mail.ninthfloor.org (ninthfloor.org [IPv6:2001:470:1f09:79c::1]) by mx1.freebsd.org (Postfix) with ESMTP id EFBA88FC12 for ; Mon, 8 Feb 2010 23:24:00 +0000 (UTC) Received: from ninthfloor.org (ninthfloor.org [IPv6:2001:470:1f09:79c::1]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pl) by mail.ninthfloor.org (Postfix) with ESMTPSA id BDB911C0E5 for ; Mon, 8 Feb 2010 23:23:59 +0000 (UTC) Date: Mon, 8 Feb 2010 23:23:55 +0000 From: Paride Legovini To: freebsd-stable@freebsd.org Message-ID: <20100208232355.GA11527@ninthfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: xorg big slowdown after upgrade (intel driver) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 23:24:01 -0000 Hello, yesterday I upgraded my 8.0-STABLE installation and noticed that xorg become a lot slower then it used to be. The previous upgrade dates back to about one month ago. I'm running freebsd on an amd64 and the graphic card is an integrated Intel Q45/Q43. Here is the relevant line from lspci: 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03) The kernel is an almost unmodified GENERIC. Has anybody noticed this problem too? Any idea? Thank you, Paride Legovini From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 00:29:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 838B5106566C for ; Tue, 9 Feb 2010 00:29:36 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id D53858FC12 for ; Tue, 9 Feb 2010 00:29:35 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o190TVlq042063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 9 Feb 2010 10:59:31 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 9 Feb 2010 10:59:21 +1030 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4814856.fuMKQumRO5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002091059.28625.doconnor@gsoft.com.au> X-Spam-Score: -3.641 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Dan Naumov Subject: Re: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 00:29:36 -0000 --nextPart4814856.fuMKQumRO5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 9 Feb 2010, Dan Naumov wrote: > which essentially solves the problem. Note that going this route will > probably involve rebuilding your entire array from scratch, because > applying WDIDLE3 to the disk is likely to very slightly affect disk > geometry, but just enough for hardware raid or ZFS or whatever to > bark at you and refuse to continue using the drive in an existing > pool (the affected disk can become very slightly smaller in > capacity). Backup data, apply WDIDLE3 to all disks. Recreate the > pool, restore backups. This will also void your warranty if used on > the new WD drives, although it will still work just fine. Errm.. Why would it change the geometry? I have used this tool to change the settings on all my disks and it did=20 not in any way cause a problem booting later. My disks are WDC WD10EADS-00L5B1/01.01A01 (1Tb "green" disks) AFAIK it just tunes EEPROM settings, it doesn't reflash the firmware. That said I have heard reports of it bricking a drive so I would test it=20 on one drive first (not that I did, I heard the bricking reports=20 later..) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart4814856.fuMKQumRO5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLcKxo5ZPcIHs/zowRAu6+AJ0YtVNOAg8LWLp2dgkv3x+NvnlNrACgmTot 0eibJt0w5WCP0RtCGnX0tMY= =oSmG -----END PGP SIGNATURE----- --nextPart4814856.fuMKQumRO5-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 00:31:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A52D1065670 for ; Tue, 9 Feb 2010 00:31:09 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A35B38FC1D for ; Tue, 9 Feb 2010 00:31:08 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o190V65W042347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 9 Feb 2010 11:01:06 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 9 Feb 2010 11:01:03 +1030 User-Agent: KMail/1.9.10 References: <20100208142259.GA3210@icarus.home.lan> <20100208155739.f2a51895.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100208155739.f2a51895.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1370700.7Uc9k03J5N"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002091101.04604.doconnor@gsoft.com.au> X-Spam-Score: -3.64 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Gerrit =?utf-8?q?K=C3=BChn?= , Jeremy Chadwick Subject: Re: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 00:31:09 -0000 --nextPart1370700.7Uc9k03J5N Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 9 Feb 2010, Gerrit K=FChn wrote: > :-))) > > I would really prefer to be able to set this stuff via camcontrol or > atacontrol. Alone having to boot DOS with this machine (no floppy, no > cdrom) will be a real pain. And most probably the DOS tool will not > be able to see the disks sitting behind my lsi-driven controller > anyway, so I have to plug them elsewhere, too. Great job, WD. :-( It does boggle the mind that they don't publish the spec for this :( I booted off a USB stick (syslinux booting freedos), although the BIOS=20 sees my disks.. (Although not all, I had to flash 4, then swap 2 and=20 flash the last one.. very stupid) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1370700.7Uc9k03J5N Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLcKzI5ZPcIHs/zowRAjSLAJ9CwJVo3FZqz6cWKHWYG7Mpnsof/ACgqlBu zPMh4hSGF8UXwGDrA4iCMs4= =WKTL -----END PGP SIGNATURE----- --nextPart1370700.7Uc9k03J5N-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 00:35:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21CDB1065670 for ; Tue, 9 Feb 2010 00:35:47 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id DD7E58FC08 for ; Tue, 9 Feb 2010 00:35:46 +0000 (UTC) Received: by iwn36 with SMTP id 36so1646303iwn.3 for ; Mon, 08 Feb 2010 16:35:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=2iJvvuaDkg2//QSBTIzO+XE9LaoPYG6YOgxiPFko5c0=; b=vliCz+uyxDn3AJ4UnN3XGwJkXyLaqWHY99cKGfjy5qepZ91daNPxbQ1k+/x5AnuaJZ 5bMud/Uwgm8nRo/6tZzrOzeWbKM0n647kJ+hArZ2HjiSSviW3rpeybm0kyEjTknRR4Fr 5XIQtWHTfK9ipHcs+HOuX3vyW+YUtftinY/C8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=bNQQ1qsH4DCO6ntEDtV+yi3FUqm0cWDet4J0UTh8guwUb9eGAzRpfS1EvWrpGgb6y6 1kYnYxECnc7eDcbSzoPjKTpIwtJUW0NnxYe3zWy0XgUwTCKcWy1p23YINNWJeWymET0V 6bv23e8f3drKJkiXrzMjX61qr6o1YyJtRgWuk= MIME-Version: 1.0 Received: by 10.231.85.198 with SMTP id p6mr356432ibl.65.1265675746128; Mon, 08 Feb 2010 16:35:46 -0800 (PST) In-Reply-To: <201002091059.28625.doconnor@gsoft.com.au> References: <201002091059.28625.doconnor@gsoft.com.au> Date: Mon, 8 Feb 2010 16:35:46 -0800 Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 00:35:47 -0000 On Mon, Feb 8, 2010 at 4:29 PM, Daniel O'Connor wrote: > On Tue, 9 Feb 2010, Dan Naumov wrote: > > which essentially solves the problem. Note that going this route will > > probably involve rebuilding your entire array from scratch, because > > applying WDIDLE3 to the disk is likely to very slightly affect disk > > geometry, but just enough for hardware raid or ZFS or whatever to > > bark at you and refuse to continue using the drive in an existing > > pool (the affected disk can become very slightly smaller in > > capacity). Backup data, apply WDIDLE3 to all disks. Recreate the > > pool, restore backups. This will also void your warranty if used on > > the new WD drives, although it will still work just fine. > > Errm.. Why would it change the geometry? > > I have used this tool to change the settings on all my disks and it did > not in any way cause a problem booting later. > > My disks are WDC WD10EADS-00L5B1/01.01A01 > > (1Tb "green" disks) > > I just did this to 8 of the 1.5 TB Caviar Green disks, without ZFS complaining in any way. I did test it on a spare drive before doing it to the 7 live drives. And I did replace them while the server was turned off, just to be safe (and to prevent a resilver from occuring). wdidle3 doesn't actually disable the idle timeout on these drives. Using /d just sets the timeout to 62 minutes. Effectively the same, but don't be surprised when it continues to say "idel 3 available and enabled". :) So far, things are running much smoother. Load_Cycle_Count has stopped increasing (50,000 in 8 weeks on 1 drive). Re-silver throughput for these drives has jumped from 7 MBps to over 40 MBps (90% full pool, so it's slower than normal right now, which is why we're swapping these drive into the pool). -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 02:01:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA7E2106566B for ; Tue, 9 Feb 2010 02:01:26 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 504648FC0C for ; Tue, 9 Feb 2010 02:01:26 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o1921MSg045587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 9 Feb 2010 12:31:22 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 9 Feb 2010 12:31:09 +1030 User-Agent: KMail/1.9.10 References: <201002091059.28625.doconnor@gsoft.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6058292.IhACCU3Alv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002091231.17551.doconnor@gsoft.com.au> X-Spam-Score: -3.64 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Subject: Re: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 02:01:26 -0000 --nextPart6058292.IhACCU3Alv Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 9 Feb 2010, Freddie Cash wrote: > > I just did this to 8 of the 1.5 TB Caviar Green disks, without ZFS > > complaining in any way. > > I did test it on a spare drive before doing it to the 7 live drives.=20 > And I did replace them while the server was turned off, just to be > safe (and to prevent a resilver from occuring). > > wdidle3 doesn't actually disable the idle timeout on these drives.=20 > Using /d just sets the timeout to 62 minutes. Effectively the same, > but don't be surprised when it continues to say "idel 3 available and > enabled". :) /d sets it (for me) to 6300 milliseconds (6.3 seconds). I took this as a=20 special value that disabled it entirely (no idea why they didn't use 0=20 or 255..) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart6058292.IhACCU3Alv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLcMHt5ZPcIHs/zowRArovAKCRgAX3cgpvGIX+/UkRRPkznG9DGQCgojhJ V8Fk6uVM0R0FPkoHZt/LMeA= =7X9m -----END PGP SIGNATURE----- --nextPart6058292.IhACCU3Alv-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 02:01:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80EE910656E7 for ; Tue, 9 Feb 2010 02:01:38 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 63FD38FC14 for ; Tue, 9 Feb 2010 02:01:38 +0000 (UTC) Received: from [192.168.1.107] (CPE0023695b905f-CM001a666aca96.cpe.net.cable.rogers.com [99.246.67.95]) by smtp.cyberfingers.net (Postfix) with ESMTP id 8AAA8AB6C7B for ; Mon, 8 Feb 2010 20:58:40 -0500 (EST) Message-ID: <4B70C1F8.8090809@pldrouin.net> Date: Mon, 08 Feb 2010 21:01:28 -0500 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD 8.0 i386 unable to boot... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 02:01:38 -0000 Hi, I have a hard time booting FreeBSD 8.0 on one of my machines. It is an older Pentium with HyperThreading. It was running fine with 7.2 but the kernel crashed after a buildworld/buildkernel/installkernel/reboot of 8.0. I had not updated FreeBSD on that machine for a while so I decided to burn a CD of 8.0 i386 (disc1) and boot the machine with it. This does not work either however as the kernel wants to automatically reboot the machine right after the "Probing Device" stage. Here is the error message I get: Going nowhere without my init cpuid = 1 Does anyone know what can be causing this and how to solve it? Thanks! From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 02:20:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31DC4106566B for ; Tue, 9 Feb 2010 02:20:43 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 0CCA68FC12 for ; Tue, 9 Feb 2010 02:20:42 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id F3D122BB33C; Mon, 8 Feb 2010 21:20:41 -0500 (EST) Date: Mon, 8 Feb 2010 21:20:40 -0500 From: "Peter C. Lai" To: Pierre-Luc Drouin Message-ID: <20100209022039.GE4648@cesium.hyperfine.info> References: <4B70C1F8.8090809@pldrouin.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B70C1F8.8090809@pldrouin.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.0 i386 unable to boot... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 02:20:43 -0000 Well try turning off ACPI, HyperThreading, etc.? On 2010-02-08 09:01:28PM -0500, Pierre-Luc Drouin wrote: > Hi, > > I have a hard time booting FreeBSD 8.0 on one of my machines. It is an > older Pentium with HyperThreading. It was running fine with 7.2 but the > kernel crashed after a buildworld/buildkernel/installkernel/reboot of 8.0. > I had not updated FreeBSD on that machine for a while so I decided to burn > a CD of 8.0 i386 (disc1) and boot the machine with it. This does not work > either however as the kernel wants to automatically reboot the machine > right after the "Probing Device" stage. Here is the error message I get: > > Going nowhere without my init cpuid = 1 > > Does anyone know what can be causing this and how to solve it? > > Thanks! > _______________________________________________ > 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" -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 02:28:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D4851065692 for ; Tue, 9 Feb 2010 02:28:34 +0000 (UTC) (envelope-from diizzyy@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 369BF8FC1A for ; Tue, 9 Feb 2010 02:28:33 +0000 (UTC) Received: by fxm24 with SMTP id 24so279750fxm.3 for ; Mon, 08 Feb 2010 18:28:33 -0800 (PST) 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=Tpn8e8VS2wxjA8FMirSgLCixv5MirVZ9APWiefTRQ48=; b=FHWtZbJvJRUSOIg3EC0kn1C9qPY19RRKQSqi3Jy4iE1ts+F0iO3P8vyY+AKXFFgxFX xbCWHwMSnlmRH9XnEHNDQ8qVRXaB9/8+jsjYByKxWmVeGM1WiMLasYYc0Szdwq8yULXN uSK8SVTWa5JNSTnEPPWrcwiNAOV8+FqX4s+a4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UGrAdG1a1B0IkaKp+j12WthGL8XZu2FzvB0+sBtEQB8faeG2GoLftC28LXTNxPE0T7 doOZZRVQLB59OShjiUh3pXMGigCmNBb2qJ9hp6gdYHE2v4h5nQA7cUdH8/WT9OVqiYTd HvRg2pIFcNBFmJNHIZEJEd78oIqWsA1uBrpzE= MIME-Version: 1.0 Received: by 10.223.15.23 with SMTP id i23mr4640763faa.53.1265680621267; Mon, 08 Feb 2010 17:57:01 -0800 (PST) Date: Tue, 9 Feb 2010 02:57:01 +0100 Message-ID: From: Daniel Engberg To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 02:28:34 -0000 While I'm not a heavy FreeBSD user I can offer you some advice on hardware at least based on my own experience. If you want things to work as good as possible go with Intel chipset and LAN. AMD chipsets works (mostly) but you'll have worse performance and you wont get an Intel NIC which performs much better than Realtek or Attansic. which you usually find on AMD motherboards. A general tip is to go for business chipsets as Intel like to call them, Q35 (I have a few of those and they work very good), Q45 and Q57. By doing so you can be sure to get Intel NIC and they aren't much more expensive than your average motherboard and also usually carries some kind of remote management. Having in mind that FreeBSD may/may not support the newest hardware around I'd guess that Q57 needs -CURRENT for now but I would highly recommend it as Socket 775 is slowly dying. ASUS P7Q57-M DO looks like a very nice board if you want "bleeding edge" have in mind though as time of writing support for NIC doesn't seem to be in FreeBSD but I guess its a short matter of time (82578DM). Pair it with the slowest Core i3 CPU you can find and you have a very nice solution. If you step up to i5 you get hardware encryption =) If you want legacy Intel DQ45CB should be a pretty nice choice with supported LAN out of the box. Intel Pentium E6300 should be more than enough for storage. Both MSI and Gigabyte also makes Q-chipsets motherboards but they don't seem to widely available in the US and their boards should be fine too. Since you want to have more than 5 HDDs you need a controller card of some sort, in that case I would recommend you to have a look at the Supermicro ones mentioned in the post. http://forums.freebsd.org/showpost.php?p=59735&postcount=5 UIO is just a backwards PCIe slot so turning it around till make it fit although you mean need to secure it somehow. They may be a bit hard to find but you can find a few sellers on eBay too. What I don't know is how the motherboards will react if you pop one in which you need to do some research on. As for memory you'll need at least 2Gb but 4Gb is highly recommended if you're going to use ZFS. Just make sure the sticks follows JEDEC standards and you'll be fine (Corsair Value Select series or stock Crucial are fine). //Daniel From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 02:28:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9093106566C for ; Tue, 9 Feb 2010 02:28:35 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id A91FC8FC0C for ; Tue, 9 Feb 2010 02:28:35 +0000 (UTC) Received: from [192.168.1.107] (CPE0023695b905f-CM001a666aca96.cpe.net.cable.rogers.com [99.246.67.95]) by smtp.cyberfingers.net (Postfix) with ESMTP id BAFE2AB6C68; Mon, 8 Feb 2010 21:25:37 -0500 (EST) Message-ID: <4B70C851.9010604@pldrouin.net> Date: Mon, 08 Feb 2010 21:28:33 -0500 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Peter C. Lai" References: <4B70C1F8.8090809@pldrouin.net> <20100209022039.GE4648@cesium.hyperfine.info> In-Reply-To: <20100209022039.GE4648@cesium.hyperfine.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.0 i386 unable to boot... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 02:28:35 -0000 After doing some more research, it seems that I am having the same problem than described by this person: http://forums.freebsd.org/showthread.php?t=4502 however I really don't understand why I would need to move partitions around to allow the installer to even start? This machine has 2GB of RAM which I guess should be plenty enough to start the installer without swapping... The hard drive is a 80GB WD IDE drive. The machine is not configured to use any RAID. Thanks! Peter C. Lai wrote: > Well try turning off ACPI, HyperThreading, etc.? > > On 2010-02-08 09:01:28PM -0500, Pierre-Luc Drouin wrote: > >> Hi, >> >> I have a hard time booting FreeBSD 8.0 on one of my machines. It is an >> older Pentium with HyperThreading. It was running fine with 7.2 but the >> kernel crashed after a buildworld/buildkernel/installkernel/reboot of 8.0. >> I had not updated FreeBSD on that machine for a while so I decided to burn >> a CD of 8.0 i386 (disc1) and boot the machine with it. This does not work >> either however as the kernel wants to automatically reboot the machine >> right after the "Probing Device" stage. Here is the error message I get: >> >> Going nowhere without my init cpuid = 1 >> >> Does anyone know what can be causing this and how to solve it? >> >> Thanks! >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 04:55:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5A991065679 for ; Tue, 9 Feb 2010 04:55:51 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from mail.jumbuck.com (p82.jumbuck.com [206.112.99.82]) by mx1.freebsd.org (Postfix) with ESMTP id A05258FC14 for ; Tue, 9 Feb 2010 04:55:51 +0000 (UTC) Received: from mail.jumbuck.com (mail.jumbuck.com [206.112.99.82]) by mail.jumbuck.com (Postfix) with ESMTP id F3CF9DDAB138; Tue, 9 Feb 2010 04:38:12 +0000 (UTC) Received: from [127.0.0.1] (ppp191-232.static.internode.on.net [59.167.191.232]) (Authenticated sender: hostmaster@jumbuck.com) by mail.jumbuck.com (Postfix) with ESMTPA id 3EFC4DDAAC1E; Tue, 9 Feb 2010 04:38:12 +0000 (UTC) Message-ID: <4B70E66F.2040203@thebeastie.org> Date: Tue, 09 Feb 2010 15:37:03 +1100 From: Michael Vince User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Jordi Espasa Clofent References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> <4B696360.3070209@minibofh.org> In-Reply-To: <4B696360.3070209@minibofh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ionice in FreeBSD? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 04:55:51 -0000 On 3/02/2010 10:52 PM, Jordi Espasa Clofent wrote: > On 02/03/2010 12:12 PM, Bruce Simpson wrote: >> On 02/02/2010 17:19, Jordi Espasa Clofent wrote: >>> >>> In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if >>> I'm understanding correctly, they're related to CPU priorty only, not >>> to I/O. >> >> That's not entirely true. >> >> A thread's CPU priority is still going to affect its ability to be >> scheduled on the CPU, and if it's waiting in the read() or write() >> syscalls, then this will make a difference to how quickly it can >> complete the next call. > > Yes. I've already supposed it. > >> However, it doesn't explicitly affect relative I/O prioritization. This >> is another story entirely. I suspect in a lot of cases adding a weight >> to per thread I/O, isn't going to make much difference for disk I/Os >> which are being sorted for the geometry (e.g. AHCI NCQ). >> >> So I guess my question is, 'why do you need I/O scheduling, and what >> aspect of system performance are you trying to solve with it' ? > > Some shell-scripts based on dd or rsync, for example. Even a daily > antivirus (ClamAV) scanner means an extensive I/O. > Programs like Rsync do provide --bwlimit= which work great in slowing it down to a desired level. I can't help but think every program that can use too much IO should have it's own IO/speed switch of some sort. I can only hope that in general nix evolution that all programs that can over use IO will offer a switch to slow it down like Rsync does. Using a while ionice can be a useful feature it can also be said that there are too many instances where it's being used as a hack to deal with a program that isn't offering all the functionality that it should. Cheers, Mike From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 05:38:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F11A106566B for ; Tue, 9 Feb 2010 05:38:33 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A93968FC15 for ; Tue, 9 Feb 2010 05:38:32 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o195cSAj052587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 9 Feb 2010 16:08:28 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 9 Feb 2010 16:08:16 +1030 User-Agent: KMail/1.9.10 References: <4B70C1F8.8090809@pldrouin.net> <20100209022039.GE4648@cesium.hyperfine.info> <4B70C851.9010604@pldrouin.net> In-Reply-To: <4B70C851.9010604@pldrouin.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5085511.ZW6pvqcdmh"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002091608.24051.doconnor@gsoft.com.au> X-Spam-Score: -3.64 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Pierre-Luc Drouin , "Peter C. Lai" Subject: Re: FreeBSD 8.0 i386 unable to boot... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 05:38:33 -0000 --nextPart5085511.ZW6pvqcdmh Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 9 Feb 2010, Pierre-Luc Drouin wrote: > After doing some more research, it seems that I am having the same > problem than described by this person: > http://forums.freebsd.org/showthread.php?t=3D4502 So you get the same "file system full" message and then a panic about=20 init? > however I really don't understand why I would need to move partitions > around to allow the installer to even start? This machine has 2GB of > RAM which I guess should be plenty enough to start the installer > without swapping... The hard drive is a 80GB WD IDE drive. The > machine is not configured to use any RAID. It is pretty odd, I've installed FreeBSD on a laptop with 60Gb=20 partitions and FreeBSD was last yet it worked fine.. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart5085511.ZW6pvqcdmh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLcPTP5ZPcIHs/zowRAqU0AJsG9K5mIUdA2+iQaqCWnQySOuxTZgCeOI3q D455p7ogmIpXgbbuD5Awx2E= =z4hX -----END PGP SIGNATURE----- --nextPart5085511.ZW6pvqcdmh-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 05:44:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60EC31065695 for ; Tue, 9 Feb 2010 05:44:32 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f180.google.com (mail-qy0-f180.google.com [209.85.221.180]) by mx1.freebsd.org (Postfix) with ESMTP id 0EF048FC14 for ; Tue, 9 Feb 2010 05:44:31 +0000 (UTC) Received: by qyk10 with SMTP id 10so267760qyk.4 for ; Mon, 08 Feb 2010 21:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=NKMzzs9yaxgLBWZbtzGquhzTniTjQRNH5AcNIiIKTnA=; b=wLvhMLK5i+50Bu8SxQvG8twxpjEFvnJxgeEifPUN4rLeePowFoxbUQLPFzZRPNMUiJ UwB2PZ/s8m7DuNtRjY/oUkmnmz/7id1IkQNAVIFenbDm9kJD35QjvhJswL5i1x26sfJb wLauBb+wYSYoYweLu790dyzr0F+stxOy+yk0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=wbLi4GRSoGlulLU4wSgfDpJeStxBrvkb8Cwq1bbwYR286yxLDh8XZ/GGA+7oEZwVjV eS1hvJUhy3aVtGWooI4ZDDFkSkUJIK6T6VG/Aultro0OHiIKldvrBv3lOU0Ca4mRmc2b 4Gf8k5VbbReqCiz4wFqTps+vOvs4+p26ZdUeA= Received: by 10.229.62.84 with SMTP id w20mr992160qch.96.1265694271402; Mon, 08 Feb 2010 21:44:31 -0800 (PST) Received: from centel.dataix.local (ppp-21.32.dialinfree.com [209.172.21.32]) by mx.google.com with ESMTPS id 20sm3577475qyk.13.2010.02.08.21.44.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Feb 2010 21:44:29 -0800 (PST) Sender: "J. Hellenthal" Date: Tue, 9 Feb 2010 00:44:31 -0500 From: jhell To: Michael Vince In-Reply-To: <4B70E66F.2040203@thebeastie.org> Message-ID: References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> <4B696360.3070209@minibofh.org> <4B70E66F.2040203@thebeastie.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jordi Espasa Clofent , freebsd-stable@freebsd.org Subject: Re: ionice in FreeBSD? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 05:44:32 -0000 On Mon, 8 Feb 2010 23:37, mv@ wrote: > On 3/02/2010 10:52 PM, Jordi Espasa Clofent wrote: >> On 02/03/2010 12:12 PM, Bruce Simpson wrote: >>> On 02/02/2010 17:19, Jordi Espasa Clofent wrote: >>>> >>>> In FreeBSD we've nice(1), renice(8) and even rtprio, idprio(1) but if >>>> I'm understanding correctly, they're related to CPU priorty only, not >>>> to I/O. >>> >>> That's not entirely true. >>> >>> A thread's CPU priority is still going to affect its ability to be >>> scheduled on the CPU, and if it's waiting in the read() or write() >>> syscalls, then this will make a difference to how quickly it can >>> complete the next call. >> >> Yes. I've already supposed it. >> >>> However, it doesn't explicitly affect relative I/O prioritization. This >>> is another story entirely. I suspect in a lot of cases adding a weight >>> to per thread I/O, isn't going to make much difference for disk I/Os >>> which are being sorted for the geometry (e.g. AHCI NCQ). >>> >>> So I guess my question is, 'why do you need I/O scheduling, and what >>> aspect of system performance are you trying to solve with it' ? >> >> Some shell-scripts based on dd or rsync, for example. Even a daily >> antivirus (ClamAV) scanner means an extensive I/O. >> > Programs like Rsync do provide --bwlimit= which work great in slowing it down > to a desired level. > > I can't help but think every program that can use too much IO should have > it's own IO/speed switch of some sort. > I can only hope that in general nix evolution that all programs that can over > use IO will offer a switch to slow it down like Rsync does. > > Using a while ionice can be a useful feature it can also be said that there > are too many instances where it's being used as a hack to deal with a program > that isn't offering all the functionality that it should. > > Cheers, > Mike > In this thread with due respect to the OP the following might be considered a fruitless hack but it works!. Piping a processes output to dd(1) if you have a choice is a pretty fair temporary solution if a program does not offer that capability. For instance, I don't know if you are familiar with dump(8) at all, but I use a -P or pipe from that process to dd(8) to slow down the traffic that it tries to write over the network for backup purposes and then also give dump(8) a different nice level so it plays along. So even if you can cat your output and then read it in from fd(4) using dd(8) you still have a chance at slowing things down a little or writing at smaller increments that wont impact your environment as hard. ;) -- jhell From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 05:45:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF4A71065670 for ; Tue, 9 Feb 2010 05:45:12 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 9BDE18FC13 for ; Tue, 9 Feb 2010 05:45:12 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.120] ([173.200.179.65]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KXK000ID7Z7EQ80@asmtp029.mac.com> for freebsd-stable@freebsd.org; Mon, 08 Feb 2010 21:45:12 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002080313 From: Chuck Swiger In-reply-to: <4B70C1F8.8090809@pldrouin.net> Date: Mon, 08 Feb 2010 21:45:07 -0800 Message-id: <1A21C3B1-B637-4DF9-92F1-AA659CA0D90A@mac.com> References: <4B70C1F8.8090809@pldrouin.net> To: Pierre-Luc Drouin X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.0 i386 unable to boot... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 05:45:12 -0000 Hi-- On Feb 8, 2010, at 6:01 PM, Pierre-Luc Drouin wrote: > Going nowhere without my init cpuid = 1 > > Does anyone know what can be causing this and how to solve it? I don't suppose you built a custom kernel without the COMPAT_FREEBSD7 option? You need it until you get a new R8 userland and all ports recompiled... -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 05:47:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08092106566B for ; Tue, 9 Feb 2010 05:47:44 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id D38588FC1C for ; Tue, 9 Feb 2010 05:47:43 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-123.hsd1.ms.comcast.net [75.65.60.123]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 5B23937B5E2; Mon, 8 Feb 2010 23:30:03 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id AC35361C41; Mon, 8 Feb 2010 23:30:02 -0600 (CST) Date: Mon, 8 Feb 2010 23:30:02 -0600 From: "Matthew D. Fuller" To: Daniel O'Connor Message-ID: <20100209053002.GA9449@over-yonder.net> References: <4B6F9A8D.4050907@langille.org> <201002081556.54782.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002081556.54782.doconnor@gsoft.com.au> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.20-fullermd.4 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org, Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 05:47:44 -0000 On Mon, Feb 08, 2010 at 03:56:46PM +1030 I heard the voice of Daniel O'Connor, and lo! it spake thus: > > I have something similar (5x1Tb) - I have a Gigabyte GA-MA785GM-US2H > with an Athlon X2 and 4Gb of RAM (only half filled - 2x2Gb) > > [...] > > Note that it doesn't support ECC, I don't know if that is a problem. How's that? Is the BIOS just stupid, or is the board physically missing traces? -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 06:07:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D25F31065672 for ; Tue, 9 Feb 2010 06:07:57 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id E12A28FC0A for ; Tue, 9 Feb 2010 06:07:56 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o1967sPJ053209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 9 Feb 2010 16:37:54 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "Matthew D. Fuller" Date: Tue, 9 Feb 2010 16:37:50 +1030 User-Agent: KMail/1.9.10 References: <4B6F9A8D.4050907@langille.org> <201002081556.54782.doconnor@gsoft.com.au> <20100209053002.GA9449@over-yonder.net> In-Reply-To: <20100209053002.GA9449@over-yonder.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4778613.t7ZNIXCfSn"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002091637.52002.doconnor@gsoft.com.au> X-Spam-Score: -3.64 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org, Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 06:07:57 -0000 --nextPart4778613.t7ZNIXCfSn Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 9 Feb 2010, Matthew D. Fuller wrote: > On Mon, Feb 08, 2010 at 03:56:46PM +1030 I heard the voice of > > Daniel O'Connor, and lo! it spake thus: > > I have something similar (5x1Tb) - I have a Gigabyte > > GA-MA785GM-US2H with an Athlon X2 and 4Gb of RAM (only half filled > > - 2x2Gb) > > > > [...] > > > > Note that it doesn't support ECC, I don't know if that is a > > problem. > > How's that? Is the BIOS just stupid, or is the board physically > missing traces? I don't know.. Some consumer Gigabyte motherboards seem to support it=20 (eg GA-MA770T-UD3P). Probably the result of idiotic penny pinching though :-/ =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart4778613.t7ZNIXCfSn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLcPu35ZPcIHs/zowRAgd8AKCF8suIXvAmCZ9ep0gQZFMYlFqLsACeKdUb AHmM1VI+rt3thiIeWh/rNNg= =9Ylf -----END PGP SIGNATURE----- --nextPart4778613.t7ZNIXCfSn-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 06:15:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E856B106566B for ; Tue, 9 Feb 2010 06:15:27 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id B4F418FC08 for ; Tue, 9 Feb 2010 06:15:27 +0000 (UTC) Received: (qmail 2222 invoked by uid 0); 9 Feb 2010 06:15:27 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Feb 2010 06:15:27 -0000 Date: Tue, 9 Feb 2010 01:15:24 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: Dan Langille In-Reply-To: <4B6F9A8D.4050907@langille.org> Message-ID: References: <4B6F9A8D.4050907@langille.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 06:15:28 -0000 On Mon, 8 Feb 2010, Dan Langille wrote: > Hi, > > I'm looking at creating a large home use storage machine. Budget is a > concern, but size and reliability are also a priority. Noise is also a > concern, since this will be at home, in the basement. That, and cost, pretty > much rules out a commercial case, such as a 3U case. It would be nice, but > it greatly inflates the budget. This pretty much restricts me to a tower > case. I recently had to put together something very cheap for a client for disk-only backups (rsync + zfs snapshots). As you noticed, rack enclosures that will hold a bunch of drives are insanely expensive. I put my "wishlist" from NewEgg below. While the $33 case is a bit flimsy, the extra high-cfm fan in the back and the fan that sits in front of the drive bays keeps the drives extremely cool. For $33, I lucked out. > The primary use of this machine will be a backup server[1]. It will do other > secondary use will include minor tasks such as samba, CIFS, cvsup, etc. > > I'm thinking of 8x1TB (or larger) SATA drives. I've found a case[2] with > hot-swap bays[3], that seems interesting. I haven't looked at power > supplies, but given that number of drives, I expect something beefy with a > decent reputation is called for. For home use is the hot-swap option really needed? Also, it seems like people who use zfs (or gmirror + gstripe) generally end up buying pricey hardware raid cards for compatibility reasons. There seem to be no decent add-on SATA cards that play nice with FreeBSD other than that weird supermicro card that has to be physically hacked about to fit. I did "splurge" for a server-class board from Supermicro since I wanted bios serial port console redirection, and as many SATA ports on-board that I could find. > Whether I use hardware or software RAID is undecided. I > > I think I am leaning towards software RAID, probably ZFS under FreeBSD 8.x > but I'm open to hardware RAID but I think the cost won't justify it given > ZFS. I've had two very different ZFS experiences so far. On the hardware I mention in this message, I had zero problems and excellent performance (bonnie++ showing 145MB/s reads, 132MB/s writes on a 4 disk RAIDZ1 array) with 8.0/amd64 w/4GB of RAM. I did no "tuning" at all - amd64 is the way to go for ZFS. On an old machine at home with 2 old (2003 era) 32-bit xeons, I ran into all the issues people see with i386+ZFS - kernel memory exhaustion resulting in a panic, screwing around with an old 3Ware RAID card (JBOD mode) that cannot properly scan for new drives, just a total mess without lots of futzing about. > Given that, what motherboard and RAM configuration would you recommend to > work with FreeBSD [and probably ZFS]. The lists seems to indicate that more > RAM is better with ZFS. Here's the list: http://secure.newegg.com/WishList/PublicWishDetail.aspx?WishListNumber=8441629 Just over $1K, and I've got 4 nice drives, ECC memory, and a server board. Going with the celeron saved a ton of cash with no impact on ZFS that I can discern, and again, going with a cheap tower case slashed the cost as well. That whole combo works great. Now when I use up those 6 SATA ports, I don't know how to get more cheaply, but I'll worry about that later... Charles > Thanks. > > > [1] - FYI running Bacula, but that's out of scope for this question > > [2] - http://www.newegg.com/Product/Product.aspx?Item=N82E16811192058 > > [3] - nice to have, especially for a failure. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 06:23:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9433D106566B for ; Tue, 9 Feb 2010 06:23:33 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (email.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 575098FC12 for ; Tue, 9 Feb 2010 06:23:33 +0000 (UTC) Received: by email.octopus.com.au (Postfix, from userid 1002) id 09BDB5CB947; Tue, 9 Feb 2010 17:23:16 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: * X-Spam-Status: No, score=1.9 required=10.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.3 Received: from [10.1.50.60] (ppp121-44-221-175.lns20.syd7.internode.on.net [121.44.221.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 4228D5CB963 for ; Tue, 9 Feb 2010 17:23:12 +1100 (EST) Message-ID: <4B70FEEC.6070007@modulus.org> Date: Tue, 09 Feb 2010 17:21:32 +1100 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B6F9A8D.4050907@langille.org> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 06:23:33 -0000 http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H Supermicro just released a new Mini-ITX fanless Atom server board with 6xSATA ports (based on Intel ICH9) and a PCIe 16x slot. It takes up to 4GB of RAM, and there's even a version with KVM-over-LAN for headless operation and remote management. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 06:33:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17A77106566C for ; Tue, 9 Feb 2010 06:33:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id F13658FC14 for ; Tue, 9 Feb 2010 06:33:11 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta13.emeryville.ca.mail.comcast.net with comcast id fiSe1d0071zF43QADiZCpg; Tue, 09 Feb 2010 06:33:12 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta24.emeryville.ca.mail.comcast.net with comcast id fiaW1d00C3S48mS8kiaWw6; Tue, 09 Feb 2010 06:34:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 870DF1E3033; Mon, 8 Feb 2010 22:33:10 -0800 (PST) Date: Mon, 8 Feb 2010 22:33:10 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100209063310.GA23387@icarus.home.lan> References: <4B6F9A8D.4050907@langille.org> <4B70FEEC.6070007@modulus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B70FEEC.6070007@modulus.org> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 06:33:12 -0000 On Tue, Feb 09, 2010 at 05:21:32PM +1100, Andrew Snow wrote: > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H > > Supermicro just released a new Mini-ITX fanless Atom server board > with 6xSATA ports (based on Intel ICH9) and a PCIe 16x slot. It > takes up to 4GB of RAM, and there's even a version with KVM-over-LAN > for headless operation and remote management. Neat hardware. But with regards to the KVM-over-LAN stuff: it's IPMI, and Supermicro has a very, *very* long history of having shoddy IPMI support. I've been told the latter by too many different individuals in the industry (some co-workers, some work at Yahoo, some at Rackable, etc.) for me to rely on it. If you *have* to go this route, make sure you get the IPMI module which has its own dedicated LAN port on the module and ***does not*** piggyback on top of an existing LAN port on the mainboard. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 06:47:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC7CA1065670 for ; Tue, 9 Feb 2010 06:47:22 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 227528FC16 for ; Tue, 9 Feb 2010 06:47:21 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o196lDQZ054591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 9 Feb 2010 17:17:13 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 9 Feb 2010 17:17:02 +1030 User-Agent: KMail/1.9.10 References: <4B6F9A8D.4050907@langille.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2165989.FWfVg3I9F9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002091717.10985.doconnor@gsoft.com.au> X-Spam-Score: -3.639 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Charles Sprickman , Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 06:47:22 -0000 --nextPart2165989.FWfVg3I9F9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 9 Feb 2010, Charles Sprickman wrote: > For home use is the hot-swap option really needed? =A0Also, it seems > like people who use zfs (or gmirror + gstripe) generally end up > buying pricey hardware raid cards for compatibility reasons. =A0There > seem to be no decent add-on SATA cards that play nice with FreeBSD > other than that weird supermicro card that has to be physically > hacked about to fit. A friend of mine is building one and I couldn't get the Supermicro card=20 to work (the older version). It being a black box driver I couldn't see=20 what the problem was. I had good success with the onboard SATA ports (AHCI compliant), however=20 there are only 6 ports on the board I picked. Hopefully port multipliers will be fully working when I need some more=20 disks ;) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2165989.FWfVg3I9F9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLcQTu5ZPcIHs/zowRAuroAJ92cwLRfwmK32XJC8rrFGhWLE7FuACeNbeb KH9FMffd4qP4p/Akkz5BUjc= =59Ie -----END PGP SIGNATURE----- --nextPart2165989.FWfVg3I9F9-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 09:29:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1A8A106566C; Tue, 9 Feb 2010 09:29:30 +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 38F7B8FC0C; Tue, 9 Feb 2010 09:29:29 +0000 (UTC) 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 <1NemPR-0004SA-4z>; Tue, 09 Feb 2010 10:29:29 +0100 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 <1NemPR-0006tJ-3G>; Tue, 09 Feb 2010 10:29:29 +0100 Message-ID: <4B712B54.4020000@zedat.fu-berlin.de> Date: Tue, 09 Feb 2010 09:31:00 +0000 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100206 Thunderbird/3.0.1 MIME-Version: 1.0 To: Rick Macklem References: <4B6FE550.9020506@zedat.fu-berlin.de> <4B70497B.1000908@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: NFSv4: mount -t nsf4 not the same as mount_newnfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 09:29:30 -0000 On 02/08/10 22:37, Rick Macklem wrote: > > > On Mon, 8 Feb 2010, O. Hartmann wrote: > >> >> So I guess the above one is the more 'transparent' one with respect >> to the future, when NFSv4 gets mature and its way as matured into the >> kernel? >> > > Yea, I'd only use "mount -t newnfs" if for some reason you want to > test/use the experimental client for nfsv2,3 instead of the regular one. > >> I tried the above and it works. But it seems, that only UFS2 >> filesystems can be mounted by the client. When trying mounting a >> filesystem residing on ZFS, it fails. Mounting works, but when try to >> access or doing a simple 'ls', I get >> >> ls: /backup: Permission denied >> >> >> On server side, /etc/exports looks like >> >> -- >> V4: / -sec=sys:krb5 #IPv4# >> >> /backup #IPv4# >> -- >> >> Is there still an issue with ZFS? >> > For ZFS, everything from the "root" specified by the "V4:" line > must be exported at this time. So, if "/" isn't exported, the > above won't work for ZFS. You can either export "/" or move the > NFSv4 root down to backup. For example, you could try: > > V4: /backup -sec=sys:krb5 > /backup > > (assuming /backup is the ZFS volume) > > and then a mount like: > mount -t nfs -o nfsv4 server:/ /mnt > will mount /backup on /mnt > > rick > ps: ZFS also has its own export stuff, but it is my understanding that > putting a line in /etc/exports is sufficient. I've never used ZFS, > so others will know more than I. > Well, I guess I havn't uderstood everything of NFSv4. The 'concept' of the 'root' is new to me, maybe there are some deeper explanation of the purpose? Are there supposed to be more than one 'root' enries or only one? At this very moment mounting seems to work, but I always get a 'permission denied' error on every ZFS exported filesystem. Doing the same with UFS2 filesystems, everything works as expected. Is there a way to inspect the exports and mounts for the used NFS-protocol? When issuing 'mount', the 'backup' mount is repoted to be 'newnfs', I assume this reflects NFSv4 being used, now I need to figure out what's going wrong with the ZFS export. NFS export of the ZFS filesystem is enabled, but as far as I know, this feature is not used in FreeBSD since ZFS in FreeBSD lacks of the capabilities of autonomously exporting its via NFS - well, I'm not an expert in this matter. Thanks a lot, Oliver From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 09:40:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22BBD1065672; Tue, 9 Feb 2010 09:40:05 +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 70A158FC1A; Tue, 9 Feb 2010 09:40:04 +0000 (UTC) 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 <1NemZf-0007MY-4L>; Tue, 09 Feb 2010 10:40:03 +0100 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 <1NemZf-0007lQ-2B>; Tue, 09 Feb 2010 10:40:03 +0100 Message-ID: <4B712DCE.7030500@zedat.fu-berlin.de> Date: Tue, 09 Feb 2010 09:41:34 +0000 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100206 Thunderbird/3.0.1 MIME-Version: 1.0 To: Eitan Adler References: <4B701269.9070703@zedat.fu-berlin.de> <20100208172033.112629f7@ernst.jennejohn.org> <4B706038.3030603@zedat.fu-berlin.de> In-Reply-To: X-Originating-IP: 130.133.86.198 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, gary.jennejohn@freenet.de, freebsd-ports@freebsd.org Subject: Re: www/firefox: Firefox 3.6 crashes, Firefox 3.5.7 not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 09:40:05 -0000 On 02/08/10 21:42, Eitan Adler wrote: > I have no idea if this is related but from pkg-message > Firefox 3.6 and HTML5 > > Certain functions used to display HTML5 elements need the sem module. > > If your Firefox crashes with the following message while viewing a > HTML5 page: > "Bad system call (core dumped)" > > you need to load the sem module (kldload sem). > > To load sem on every boot put the following into your > /boot/loader.conf: > sem_load="YES" > > On Mon, Feb 8, 2010 at 9:04 PM, O. Hartmann > > wrote: > > On 02/08/10 16:20, Gary Jennejohn wrote: > > On Mon, 08 Feb 2010 13:32:25 +0000 > "O. Hartmann" > wrote: > > > Today, I upgraded Firefox 3.5.7 (built yesterday) to > Firefox 3.6. After > deleting ~/.mozilla (after I did a buckup, of course), I > tried a fresh > start of 'firefox3'. After firefox showed up, I realized > that no > option-field (File, Extras etc) can be used, they are dead > and after a > few seconds I clicked them, firefox3 is crashing. > > Since I recompiled firefox 3.5.7 yesterday I was wondering > if this is > due to some 'false' lib or dependency. Since I figured > that I have > similar trouble with Thunderbird 3.0.1 after I installed > it, I suspect a > faulty library causing this behaviour. With Thunderbird 3, > I never > solved the problem although I tried to rebuild everything with > thunderbird via 'portmaster -f'. I'll did this with > firefox 3.6 also, > but with no success. > > The crashing is observed on two nearly identical SMP > FreeBSD 8.0/amd64 > STABLE boxes (make world of today), up-to-date ports. The > crash is NOT > observed on my private oldish UP box, nearly the same > setup, OS at the > same revision and ports up to date as of yesterday. Maybe > this could be > a hint. > > Any hints or suggestions? > > > Try doing "ldd /usr/local/lib/firefox3/firefox-bin" and see if > anything > looks weird. > > I did - and there is nothing weird. > > I checked the installed libraries and they are all rebuild when > rebuilding necessary dependencies for firefox3. > > > You can porbably ignore > /usr/local/lib/firefox3/firefox-bin: > libxul.so => not found (0x0) > libmozjs.so => not found (0x0) > libxpcom.so => not found (0x0) > because run-mozilla.sh sets LD_LIBRARY_PATH to include > /usr/local/lib/firefox3 where these libraries are installed. > > I merely deleted my old firefox 3.6 and reinstalled from the > port (on > 9-CURRENT AMD64) and haven't seen any problems. But of > course, I've > been running various incarnations of 3.6 for a while and may > have gotten > all the dependencies already correctly installed. > > --- > Gary Jennejohn > _______________________________________________ > freebsd-stable@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org > " > > > I tried again, left the 'make config'-options as they were set by > default, delete/backuped .mozilla in my home and they restartet > firefox3. Nothing better than previously seen. Try hitting Button > 'Tools' at the top menu bar gives a menu after several seconds, > then firefox crashes/core dumps. > > Oliver > SysV smaphore (or sem?) are built into my kernel by default. The error/system message when crashing is socket(): Protocol not supported Illegal instruction (core dumped) and a core is dumped. It is funny, as long as I do not drop down any menus, this crappy Firefox 3.6 on my box runs for several seconds, then crahses unmotivated - no matter whether .mozilla has been brand new or containing the old stuff from 3.5.7. Whenever I drop down a menu, the dead comes fast. Regards, Oliver From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 09:44:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B24531065670 for ; Tue, 9 Feb 2010 09:44:45 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 978C18FC0C for ; Tue, 9 Feb 2010 09:44:45 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta12.emeryville.ca.mail.comcast.net with comcast id fliN1d0011zF43QAClkmKs; Tue, 09 Feb 2010 09:44:46 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta24.emeryville.ca.mail.comcast.net with comcast id flm41d0023S48mS8klm4aU; Tue, 09 Feb 2010 09:46:04 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 13E5E1E3033; Tue, 9 Feb 2010 01:44:44 -0800 (PST) Date: Tue, 9 Feb 2010 01:44:44 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100209094444.GA31749@icarus.home.lan> References: <4B701269.9070703@zedat.fu-berlin.de> <20100208172033.112629f7@ernst.jennejohn.org> <4B706038.3030603@zedat.fu-berlin.de> <4B712DCE.7030500@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B712DCE.7030500@zedat.fu-berlin.de> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: www/firefox: Firefox 3.6 crashes, Firefox 3.5.7 not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 09:44:45 -0000 On Tue, Feb 09, 2010 at 09:41:34AM +0000, O. Hartmann wrote: > On 02/08/10 21:42, Eitan Adler wrote: > >I have no idea if this is related but from pkg-message > >Firefox 3.6 and HTML5 > > > >Certain functions used to display HTML5 elements need the sem module. > > > >If your Firefox crashes with the following message while viewing a > >HTML5 page: > >"Bad system call (core dumped)" > > > >you need to load the sem module (kldload sem). > > > >To load sem on every boot put the following into your > >/boot/loader.conf: > >sem_load="YES" > > > >On Mon, Feb 8, 2010 at 9:04 PM, O. Hartmann > >> > >wrote: > > > > On 02/08/10 16:20, Gary Jennejohn wrote: > > > > On Mon, 08 Feb 2010 13:32:25 +0000 > > "O. Hartmann" > > wrote: > > > > > > Today, I upgraded Firefox 3.5.7 (built yesterday) to > > Firefox 3.6. After > > deleting ~/.mozilla (after I did a buckup, of course), I > > tried a fresh > > start of 'firefox3'. After firefox showed up, I realized > > that no > > option-field (File, Extras etc) can be used, they are dead > > and after a > > few seconds I clicked them, firefox3 is crashing. > > > > Since I recompiled firefox 3.5.7 yesterday I was wondering > > if this is > > due to some 'false' lib or dependency. Since I figured > > that I have > > similar trouble with Thunderbird 3.0.1 after I installed > > it, I suspect a > > faulty library causing this behaviour. With Thunderbird 3, > > I never > > solved the problem although I tried to rebuild everything with > > thunderbird via 'portmaster -f'. I'll did this with > > firefox 3.6 also, > > but with no success. > > > > The crashing is observed on two nearly identical SMP > > FreeBSD 8.0/amd64 > > STABLE boxes (make world of today), up-to-date ports. The > > crash is NOT > > observed on my private oldish UP box, nearly the same > > setup, OS at the > > same revision and ports up to date as of yesterday. Maybe > > this could be > > a hint. > > > > Any hints or suggestions? > > > > > > Try doing "ldd /usr/local/lib/firefox3/firefox-bin" and see if > > anything > > looks weird. > > > > I did - and there is nothing weird. > > > > I checked the installed libraries and they are all rebuild when > > rebuilding necessary dependencies for firefox3. > > > > > > You can porbably ignore > > /usr/local/lib/firefox3/firefox-bin: > > libxul.so => not found (0x0) > > libmozjs.so => not found (0x0) > > libxpcom.so => not found (0x0) > > because run-mozilla.sh sets LD_LIBRARY_PATH to include > > /usr/local/lib/firefox3 where these libraries are installed. > > > > I merely deleted my old firefox 3.6 and reinstalled from the > > port (on > > 9-CURRENT AMD64) and haven't seen any problems. But of > > course, I've > > been running various incarnations of 3.6 for a while and may > > have gotten > > all the dependencies already correctly installed. > > > > --- > > Gary Jennejohn > > _______________________________________________ > > freebsd-stable@freebsd.org > > mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > > "freebsd-stable-unsubscribe@freebsd.org > > " > > > > > > I tried again, left the 'make config'-options as they were set by > > default, delete/backuped .mozilla in my home and they restartet > > firefox3. Nothing better than previously seen. Try hitting Button > > 'Tools' at the top menu bar gives a menu after several seconds, > > then firefox crashes/core dumps. > > > > Oliver > > > > > SysV smaphore (or sem?) are built into my kernel by default. The > error/system message when crashing is > > socket(): Protocol not supported > Illegal instruction (core dumped) > > and a core is dumped. Sounds more like your system doesn't have IPv6 support enabled. There was a recent thread here on the lists about the latest Thunderbird doing the same thing on a system/kernel without IPv6, and there's no way to disable IPv6 support in the software (it's all hard-coded/no --disable-ipv6 flag, etc.). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 10:32:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 261A51065676 for ; Tue, 9 Feb 2010 10:32:25 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 8D34B8FC17 for ; Tue, 9 Feb 2010 10:32:24 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o19AWJNu029681; Tue, 9 Feb 2010 11:32:20 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 3B1C324; Tue, 9 Feb 2010 11:32:19 +0100 (CET) Date: Tue, 9 Feb 2010 11:32:19 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Charles Sprickman Message-Id: <20100209113219.58e5d755.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <4B6F9A8D.4050907@langille.org> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.9.102119 Cc: FreeBSD Stable , Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 10:32:25 -0000 CS> pricey hardware raid cards for compatibility reasons. There seem to CS> be no decent add-on SATA cards that play nice with FreeBSD other than CS> that weird supermicro card that has to be physically hacked about to CS> fit. BTW: I recently built some more machines with this card. I can confirm now that you can use it with "standard" brackets, if you have some spare. The distance for the two holders is the same as for e.g. 3ware 95/96 controllers and I had some spares in standard height there because I use the 3wares in low profile setups. The brackets of Intel NICs seem to fit, too. The only thing that is different with the card now is the side on which the components are mounted. But this should not be a problem unless you want to place them next ti a graphics card. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 10:32:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95E8A106566B for ; Tue, 9 Feb 2010 10:32:30 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6AC6E8FC14 for ; Tue, 9 Feb 2010 10:32:30 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-123.hsd1.ms.comcast.net [75.65.60.123]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 299F537B68C; Tue, 9 Feb 2010 04:32:29 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 4CE5661C43; Tue, 9 Feb 2010 04:32:28 -0600 (CST) Date: Tue, 9 Feb 2010 04:32:28 -0600 From: "Matthew D. Fuller" To: Daniel O'Connor Message-ID: <20100209103228.GB9449@over-yonder.net> References: <4B6F9A8D.4050907@langille.org> <201002081556.54782.doconnor@gsoft.com.au> <20100209053002.GA9449@over-yonder.net> <201002091637.52002.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002091637.52002.doconnor@gsoft.com.au> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.20-fullermd.4 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org, Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 10:32:30 -0000 On Tue, Feb 09, 2010 at 04:37:50PM +1030 I heard the voice of Daniel O'Connor, and lo! it spake thus: > > Probably the result of idiotic penny pinching though :-/ Irritating. One of my favorite parts of AMD's amd64 chips is that I no longer have to spend through the nose or be a detective (or, often, both) to get ECC. So far, it seems like there are relatively few hidden holes on that path, and I haven't stepped in one, but every new one I hear about increases my terror of the day when there are more holes than solid ground :( -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 10:35:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEE5710656AC for ; Tue, 9 Feb 2010 10:35:52 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 52CC48FC08 for ; Tue, 9 Feb 2010 10:35:51 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o19AZm18029979; Tue, 9 Feb 2010 11:35:50 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 731B64F; Tue, 9 Feb 2010 11:35:48 +0100 (CET) Date: Tue, 9 Feb 2010 11:35:48 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Andrew Snow Message-Id: <20100209113548.3391f38e.gerrit@pmp.uni-hannover.de> In-Reply-To: <4B70FEEC.6070007@modulus.org> References: <4B6F9A8D.4050907@langille.org> <4B70FEEC.6070007@modulus.org> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.9.102418 Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 10:35:53 -0000 On Tue, 09 Feb 2010 17:21:32 +1100 Andrew Snow wrote about Re: hardware for home use large storage: AS> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H The good thing about this board is that the pineview atoms seem to be 64bit capable, which makes them attractive for zfs. I bought a board with VIA Nano processor for this reason last year, as I could not find a decent hardware with 64bit capable atom. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 10:51:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3012B1065672 for ; Tue, 9 Feb 2010 10:51:21 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id 0AF598FC17 for ; Tue, 9 Feb 2010 10:51:20 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o19ApA6K018847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Feb 2010 02:51:10 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o19ApAkM018846; Tue, 9 Feb 2010 02:51:10 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA28786; Tue, 9 Feb 10 02:44:52 PST Date: Tue, 09 Feb 2010 02:42:10 -0800 From: perryh@pluto.rain.com To: freebsd@jdc.parodius.com Message-Id: <4b713c02.ejMC00AVbJJ8gHAw%perryh@pluto.rain.com> References: <20100208145504.762eaa7b.gerrit@pmp.uni-hannover.de> <20100208142259.GA3210@icarus.home.lan> In-Reply-To: <20100208142259.GA3210@icarus.home.lan> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 10:51:21 -0000 Jeremy Chadwick wrote: > The DOS utilities submit custom ATA CMDs or data to all WD disks > to toggle or adjust these features. If someone could figure out > what the command(s) were, the feature(s) could be implemented into > atacontrol(8). Of course, that would require reverse-engineering > of the EXEs ... Or use of an ATA analyzer (think wireshark, but for ATA). From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 11:18:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB4DD1065676 for ; Tue, 9 Feb 2010 11:18:39 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5538FC08 for ; Tue, 9 Feb 2010 11:18:37 +0000 (UTC) Received: from vhoffman.lon.namesco.net (187.70-246-213.ippool.namesco.net [213.246.70.187]) (authenticated bits=0) by unsane.co.uk (8.14.3/8.14.3) with ESMTP id o19BIYqr091685 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 9 Feb 2010 11:18:35 GMT (envelope-from vince@unsane.co.uk) Message-ID: <4B71448A.1060102@unsane.co.uk> Date: Tue, 09 Feb 2010 11:18:34 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B685EBA.4020501@minibofh.org> <4B695A1A.1000505@incunabulum.net> <4B696360.3070209@minibofh.org> <4B70E66F.2040203@thebeastie.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: ionice in FreeBSD? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 11:18:39 -0000 On 09/02/2010 05:44, jhell wrote: > > On Mon, 8 Feb 2010 23:37, mv@ wrote: >> On 3/02/2010 10:52 PM, Jordi Espasa Clofent wrote: >>> >>> Some shell-scripts based on dd or rsync, for example. Even a daily >>> antivirus (ClamAV) scanner means an extensive I/O. >>> >> Programs like Rsync do provide --bwlimit= which work great in slowing >> it down to a desired level. >> >> I can't help but think every program that can use too much IO should >> have it's own IO/speed switch of some sort. >> I can only hope that in general nix evolution that all programs that >> can over use IO will offer a switch to slow it down like Rsync does. >> >> Using a while ionice can be a useful feature it can also be said that >> there are too many instances where it's being used as a hack to deal >> with a program that isn't offering all the functionality that it should. >> >> Cheers, >> Mike >> > > In this thread with due respect to the OP the following might be > considered a fruitless hack but it works!. > > Piping a processes output to dd(1) if you have a choice is a pretty > fair temporary solution if a program does not offer that capability. > > For instance, I don't know if you are familiar with dump(8) at all, > but I use a -P or pipe from that process to dd(8) to slow down the > traffic that it tries to write over the network for backup purposes > and then also give dump(8) a different nice level so it plays along. > > So even if you can cat your output and then read it in from fd(4) > using dd(8) you still have a chance at slowing things down a little or > writing at smaller increments that wont impact your environment as hard. > Something like Port: throttle-1.2 Path: /usr/ports/sysutils/throttle Info: A pipe bandwidth throttling utility Maint: ports@FreeBSD.org B-deps: R-deps: WWW: http://klicman.org/throttle/ Might work too. Vince Vince > ;) > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 11:22:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C59161065670 for ; Tue, 9 Feb 2010 11:22:10 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id AAB688FC13 for ; Tue, 9 Feb 2010 11:22:10 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta03.emeryville.ca.mail.comcast.net with comcast id fnHk1d0010b6N64A3nNBUm; Tue, 09 Feb 2010 11:22:11 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta03.emeryville.ca.mail.comcast.net with comcast id fnNA1d0013S48mS8PnNAaB; Tue, 09 Feb 2010 11:22:10 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id DCCDB1E3033; Tue, 9 Feb 2010 03:22:08 -0800 (PST) Date: Tue, 9 Feb 2010 03:22:08 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100209112208.GA33249@icarus.home.lan> References: <20100208145504.762eaa7b.gerrit@pmp.uni-hannover.de> <20100208142259.GA3210@icarus.home.lan> <4b713c02.ejMC00AVbJJ8gHAw%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4b713c02.ejMC00AVbJJ8gHAw%perryh@pluto.rain.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 11:22:10 -0000 On Tue, Feb 09, 2010 at 02:42:10AM -0800, perryh@pluto.rain.com wrote: > Jeremy Chadwick wrote: > > The DOS utilities submit custom ATA CMDs or data to all WD disks > > to toggle or adjust these features. If someone could figure out > > what the command(s) were, the feature(s) could be implemented into > > atacontrol(8). Of course, that would require reverse-engineering > > of the EXEs ... > > Or use of an ATA analyzer (think wireshark, but for ATA). 1) ...which are guaranteed to be outrageously expensive: - LeCroy SATAAnalyzer -- price unknown, requires you to mail company for quote. LeCroy bought out Catalyst (known for their STX Series). - SerialTek BusXpert Micro -- same situation. - SerialTek BusXpert PRO -- same situation. - DataTransit BusDoctor + BusDoctor Rx module -- same situation. - Xgig Bus Doctor 1.5G/3G SATA Protocol Analyser -- same situation. - Xgig 6G SAS/SATA Analyzer -- same situation. - Absolute Analysis Investigator SATA Analyser -- same situation. Usually this means the products are in the multi-thousand USD range, if not tens of thousands. Google Shopping turns up very few results, including one from eBay. I rest my case: - DataTransit DrSATA analyser (EOL'd long ago) -- US$1,200 - LeCroy SA005APA-X analyser -- US$4,992 - SerialTek BusXpert Micro -- US$20,521 - SerialTek BusXpert PRO -- US$52,889 2) ...which would still be sufficient grounds for WD to sue (under DMCA) whoever was responsible for the reverse-engineering efforts. My advice would be to RE the EXE, simply because the binary requires that the SATA controller be operating with AHCI disabled, or be in PATA Emulation mode. IDA Pro could probably make this task easier, but the binary runs using a DOS extender (protected mode wrapper; think DOS4GW). I've had WDTLER generate an exception error on first use but proceed to work fine during subsequent uses. Am I willing to do any of this? Absolutely not -- DMCA violation has serious repercussions to a person, both professionally and financially. It's not worth the risk; God bless the United States. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 11:37:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16D771065692 for ; Tue, 9 Feb 2010 11:37:46 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id E08C18FC28 for ; Tue, 9 Feb 2010 11:37:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 218F0508E7; Tue, 9 Feb 2010 11:37:45 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcr1Z7J3eoD5; Tue, 9 Feb 2010 11:37:44 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 7E81750823 ; Tue, 9 Feb 2010 11:37:44 +0000 (GMT) Message-ID: <4B71490B.6030602@langille.org> Date: Tue, 09 Feb 2010 06:37:47 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Charles Sprickman References: <4B6F9A8D.4050907@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 11:37:46 -0000 Charles Sprickman wrote: > On Mon, 8 Feb 2010, Dan Langille wrote: > >> I'm thinking of 8x1TB (or larger) SATA drives. I've found a case[2] >> with hot-swap bays[3], that seems interesting. I haven't looked at >> power supplies, but given that number of drives, I expect something >> beefy with a decent reputation is called for. > > For home use is the hot-swap option really needed? Is anything needed? The option is cheap and convenient. When it comes time to swap disks, you don't have to take the case apart, etc. Yes, it saves downtime, but it is also easier. > Also, it seems like > people who use zfs (or gmirror + gstripe) generally end up buying pricey > hardware raid cards for compatibility reasons. There seem to be no > decent add-on SATA cards that play nice with FreeBSD other than that > weird supermicro card that has to be physically hacked about to fit. They use software RAID and hardware RAID at the same time? I'm not sure what you mean by this. Compatibility with FreeBSD? From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 12:51:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00AC7106568B for ; Tue, 9 Feb 2010 12:51:37 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 860748FC0C for ; Tue, 9 Feb 2010 12:51:36 +0000 (UTC) Received: by ewy3 with SMTP id 3so4525135ewy.13 for ; Tue, 09 Feb 2010 04:51:35 -0800 (PST) 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 :content-transfer-encoding; bh=o6xRVeIj+CMgdrL5c7zc1QYUcxmyQU0txm3p4QhPP5I=; b=CDHerY9UzwTdUj7cSyiA0zvR3pR7fyCQd3CkPuck1JgaF9s96wk3LQTXufPGpRbvPh Nl1A/5ECU+o6+WTPZD+yMHUrLaXoIzl3EcygojJ7ALVPb0XCwLPEHEGUlw9yQ7FGLDGF zr87UJdrw308Qpaz4ZwgwJx505X8asYB+lzqc= 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:content-transfer-encoding; b=oZsPc+EgKLkY3TcFK6k151WyxUBmSZtx7owuDPN2jrCVdGu7axERg7d2MXlkED6guX 9RzQsFFvOvTjF8QxJhjY1HMXFdHXn25beF2J4b25NGBh/deDjLQktVeTEjoyNi02rFzM CaOjdvq3Y+14by+SWF7VLx8X5QSNtzKtkIQMw= MIME-Version: 1.0 Received: by 10.213.64.74 with SMTP id d10mr5044290ebi.7.1265719895287; Tue, 09 Feb 2010 04:51:35 -0800 (PST) In-Reply-To: References: <4B6F9A8D.4050907@langille.org> Date: Tue, 9 Feb 2010 12:51:35 +0000 Message-ID: <2e027be01002090451w2b4506a0ofb5ab55c647540a@mail.gmail.com> From: Tom Evans To: Charles Sprickman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable , Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 12:51:37 -0000 On Tue, Feb 9, 2010 at 6:15 AM, Charles Sprickman wrote: > .... > Here's the list: > > http://secure.newegg.com/WishList/PublicWishDetail.aspx?WishListNumber=3D= 8441629 > > Just over $1K, and I've got 4 nice drives, ECC memory, and a server board= . > Going with the celeron saved a ton of cash with no impact on ZFS that I c= an > discern, and again, going with a cheap tower case slashed the cost as wel= l. > =C2=A0That whole combo works great. =C2=A0Now when I use up those 6 SATA = ports, I > don't know how to get more cheaply, but I'll worry about that later... > > Charles > As long as those SATA ports are AHCI compliant, should work quite nicely with a SiI port multiplier. Failing that, a simple 2 port SiI PCI-E SATA card (supported by siis(4) driver) + 2 x SiI port multiplier would give you 10 extra SATA ports. My SiI PCI-E card cost =C2=A315, and the PM about =C2=A350, so it is about =C2=A313/port, or ~$20/port. Probably can get the components cheaper in the US actually. I also found some nice simple drive racks for =C2=A320/4 drives - not completely hotswappable, but much easier to replace than screwed into the case. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 12:53:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F4AA1065670 for ; Tue, 9 Feb 2010 12:53:44 +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 52EAA8FC17 for ; Tue, 9 Feb 2010 12:53:42 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA12694; Tue, 09 Feb 2010 14:53:28 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B715AC7.2090201@icyb.net.ua> Date: Tue, 09 Feb 2010 14:53:27 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: "Matthew D. Fuller" References: <4B6F9A8D.4050907@langille.org> <201002081556.54782.doconnor@gsoft.com.au> <20100209053002.GA9449@over-yonder.net> <201002091637.52002.doconnor@gsoft.com.au> <20100209103228.GB9449@over-yonder.net> In-Reply-To: <20100209103228.GB9449@over-yonder.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 12:53:44 -0000 on 09/02/2010 12:32 Matthew D. Fuller said the following: > On Tue, Feb 09, 2010 at 04:37:50PM +1030 I heard the voice of > Daniel O'Connor, and lo! it spake thus: >> Probably the result of idiotic penny pinching though :-/ > > Irritating. One of my favorite parts of AMD's amd64 chips is that I > no longer have to spend through the nose or be a detective (or, often, > both) to get ECC. So far, it seems like there are relatively few > hidden holes on that path, and I haven't stepped in one, but every new > one I hear about increases my terror of the day when there are more > holes than solid ground :( Yep. For sure, Gigabyte BIOS on this board is completely missing ECC initialization code. I mean not only the menus in setup, but the code that does memory controller programming. Not sure about the physical lanes though. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 12:54:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D4EC1065784; Tue, 9 Feb 2010 12:54:08 +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 BACE28FC17; Tue, 9 Feb 2010 12:54:07 +0000 (UTC) Received: from [195.4.92.23] (helo=13.mx.freenet.de) by mout0.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NepbS-00074r-Ke; Tue, 09 Feb 2010 13:54:06 +0100 Received: from p57ae1560.dip0.t-ipconnect.de ([87.174.21.96]:24025 helo=ernst.jennejohn.org) by 13.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #1) id 1NepbR-0000Wf-7a; Tue, 09 Feb 2010 13:54:05 +0100 Date: Tue, 9 Feb 2010 13:54:02 +0100 From: Gary Jennejohn To: "O. Hartmann" Message-ID: <20100209135402.02976be2@ernst.jennejohn.org> In-Reply-To: <4B712DCE.7030500@zedat.fu-berlin.de> References: <4B701269.9070703@zedat.fu-berlin.de> <20100208172033.112629f7@ernst.jennejohn.org> <4B706038.3030603@zedat.fu-berlin.de> <4B712DCE.7030500@zedat.fu-berlin.de> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: Re: www/firefox: Firefox 3.6 crashes, Firefox 3.5.7 not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 12:54:08 -0000 On Tue, 09 Feb 2010 09:41:34 +0000 "O. Hartmann" wrote: [snip maybe too much] > On 02/08/10 21:42, Eitan Adler wrote: > > you need to load the sem module (kldload sem). > > > SysV smaphore (or sem?) are built into my kernel by default. The > error/system message when crashing is > > socket(): Protocol not supported > Illegal instruction (core dumped) > > and a core is dumped. > So, have you looked at the core dump with gdb to see where it appears to be crashing? Could it be IPv6 related? Do you have IPv6 in the kernel and enabled? I do. You could try adding these options to MOZ_OPTIONS in the Makefile --enable-debug[=DBG] Enable building with developer debug info --enable-debug-modules Enable/disable debug info for specific modules --enable-debugger-info-modules Enable/disable debugger info for specific modules --- Gary Jennejohn From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 12:54:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2E14106568F for ; Tue, 9 Feb 2010 12:54:53 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id C155D8FC1E for ; Tue, 9 Feb 2010 12:54:53 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by FS.denninger.net (8.14.3/8.13.1) with SMTP id o19CsrFX054070 for ; Tue, 9 Feb 2010 06:54:53 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Tue Feb 9 06:54:53 2010 Message-ID: <4B715AC6.5090500@denninger.net> Date: Tue, 09 Feb 2010 06:53:26 -0600 From: Karl Denninger User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jeremy Chadwick References: <4B6F9A8D.4050907@langille.org> <4B70FEEC.6070007@modulus.org> <20100209063310.GA23387@icarus.home.lan> In-Reply-To: <20100209063310.GA23387@icarus.home.lan> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------050901070102000703020002" X-Antivirus: avast! (VPS 100208-2, 02/08/2010), Outbound message X-Antivirus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 12:54:54 -0000 This is a multi-part message in MIME format. --------------050901070102000703020002 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jeremy Chadwick wrote: > On Tue, Feb 09, 2010 at 05:21:32PM +1100, Andrew Snow wrote: > >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H >> >> Supermicro just released a new Mini-ITX fanless Atom server board >> with 6xSATA ports (based on Intel ICH9) and a PCIe 16x slot. It >> takes up to 4GB of RAM, and there's even a version with KVM-over-LAN >> for headless operation and remote management. >> > > Neat hardware. But with regards to the KVM-over-LAN stuff: it's IPMI, > and Supermicro has a very, *very* long history of having shoddy IPMI > support. I've been told the latter by too many different individuals in > the industry (some co-workers, some work at Yahoo, some at Rackable, > etc.) for me to rely on it. If you *have* to go this route, make sure > you get the IPMI module which has its own dedicated LAN port on the > module and ***does not*** piggyback on top of an existing LAN port on > the mainboard. > What's wrong with the Supermicro IPMI implementations? I have several - all have a SEPARATE LAN port on the main board for the IPMI KVM (separate and distinct from the board's primary LAN ports), and I've not had any trouble with any of them. -- Karl --------------050901070102000703020002-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 13:44:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6E9C106566C for ; Tue, 9 Feb 2010 13:44:57 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id AD7BF8FC12 for ; Tue, 9 Feb 2010 13:44:57 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta05.emeryville.ca.mail.comcast.net with comcast id fpYZ1d0011smiN4A5pkyU7; Tue, 09 Feb 2010 13:44:58 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id fpkx1d0063S48mS8gpkxc4; Tue, 09 Feb 2010 13:44:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3D5CC1E3033; Tue, 9 Feb 2010 05:44:56 -0800 (PST) Date: Tue, 9 Feb 2010 05:44:56 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100209134456.GA37029@icarus.home.lan> References: <4B6F9A8D.4050907@langille.org> <4B70FEEC.6070007@modulus.org> <20100209063310.GA23387@icarus.home.lan> <4B715AC6.5090500@denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B715AC6.5090500@denninger.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 13:44:58 -0000 On Tue, Feb 09, 2010 at 06:53:26AM -0600, Karl Denninger wrote: > Jeremy Chadwick wrote: > > On Tue, Feb 09, 2010 at 05:21:32PM +1100, Andrew Snow wrote: > > > >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H > >> > >> Supermicro just released a new Mini-ITX fanless Atom server board > >> with 6xSATA ports (based on Intel ICH9) and a PCIe 16x slot. It > >> takes up to 4GB of RAM, and there's even a version with KVM-over-LAN > >> for headless operation and remote management. > >> > > > > Neat hardware. But with regards to the KVM-over-LAN stuff: it's IPMI, > > and Supermicro has a very, *very* long history of having shoddy IPMI > > support. I've been told the latter by too many different individuals in > > the industry (some co-workers, some work at Yahoo, some at Rackable, > > etc.) for me to rely on it. If you *have* to go this route, make sure > > you get the IPMI module which has its own dedicated LAN port on the > > module and ***does not*** piggyback on top of an existing LAN port on > > the mainboard. > > > What's wrong with the Supermicro IPMI implementations? I have several - > all have a SEPARATE LAN port on the main board for the IPMI KVM > (separate and distinct from the board's primary LAN ports), and I've not > had any trouble with any of them. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2008-01/msg01206.html http://forums.freebsd.org/showthread.php?t=7750 http://www.beowulf.org/archive/2007-November/019925.html http://bivald.com/lessons-learned/2009/06/supermicro_ipmi_problems_web_i.html http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044248.html http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044237.html (Last thread piece does mention that the user was able to get keyboard working by disabling umass(4) of all things) It gets worse when you use one of the IPMI modules that piggybacks on an existing Ethernet port -- the NIC driver for the OS, from the ground up, has to be fully aware of ASF and any quirks/oddities involved. For example, on bge(4) and bce(4), you'll find this (bge mentioned below): hw.bge.allow_asf Allow the ASF feature for cooperating with IPMI. Can cause sys- tem lockup problems on a small number of systems. Disabled by default. So unless the administrator intentionally sets the loader tunable prior to booting the OS installation, they'll find all kinds of MAC problems as a result of the IPMI piggybacking. "Why isn't this enabled by default?" I believe because there were reports of failures/problems on people's systems who *did not* have IPMI cards. Lose-lose situation. If you really want me to dig up people at Yahoo who have dealt with IPMI on thousands of Supermicro servers and the insanity involved (due to bugs, quirks, or implementation differences between the IPMI firmwares and which revision/model of module used), I can do so. Most of the complaints I've heard of stem from serial-over-IPMI. I don't think it'd be a very positive/"supportive" thread, however. :-) One similar product that does seem to work well is iLO, available on HP/Compaq hardware. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 13:45:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11F431065702 for ; Tue, 9 Feb 2010 13:45:14 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id D87CB8FC12 for ; Tue, 9 Feb 2010 13:45:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 58535508B6; Tue, 9 Feb 2010 13:45:13 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Idz7MqiOiyzW; Tue, 9 Feb 2010 13:45:12 +0000 (GMT) Received: from nyi.unixathome.org (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id BA5B350830; Tue, 9 Feb 2010 13:45:11 +0000 (GMT) Received: from 68.64.144.211 (SquirrelMail authenticated user dan) by nyi.unixathome.org with HTTP; Tue, 9 Feb 2010 08:45:12 -0500 Message-ID: In-Reply-To: <2e027be01002090451w2b4506a0ofb5ab55c647540a@mail.gmail.com> References: <4B6F9A8D.4050907@langille.org> <2e027be01002090451w2b4506a0ofb5ab55c647540a@mail.gmail.com> Date: Tue, 9 Feb 2010 08:45:12 -0500 From: "Dan Langille" To: "Tom Evans" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Charles Sprickman , FreeBSD Stable , Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 13:45:14 -0000 On Tue, February 9, 2010 7:51 am, Tom Evans wrote: > On Tue, Feb 9, 2010 at 6:15 AM, Charles Sprickman wrote: >> .... >> Here's the list: >> >> http://secure.newegg.com/WishList/PublicWishDetail.aspx?WishListNumber=8441629 >> >> Just over $1K, and I've got 4 nice drives, ECC memory, and a server >> board. >> Going with the celeron saved a ton of cash with no impact on ZFS that I >> can >> discern, and again, going with a cheap tower case slashed the cost as >> well. >>  That whole combo works great.  Now when I use up those 6 SATA ports, >> I >> don't know how to get more cheaply, but I'll worry about that later... >> >> Charles >> > > As long as those SATA ports are AHCI compliant, should work quite > nicely with a SiI port multiplier. Failing that, a simple 2 port SiI > PCI-E SATA card (supported by siis(4) driver) + 2 x SiI port > multiplier would give you 10 extra SATA ports. > > My SiI PCI-E card cost £15, and the PM about £50, so it is about > £13/port, or ~$20/port. Probably can get the components cheaper in the > US actually. I also found some nice simple drive racks for £20/4 > drives - not completely hotswappable, but much easier to replace than > screwed into the case. Now there's an idea. Drive racks? Got a URL? -- Dan Langille -- http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 14:05:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58A6A1065693 for ; Tue, 9 Feb 2010 14:05:05 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id F03978FC1A for ; Tue, 9 Feb 2010 14:05:04 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by FS.denninger.net (8.14.3/8.13.1) with SMTP id o19E535R057626 for ; Tue, 9 Feb 2010 08:05:04 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Tue Feb 9 08:05:04 2010 Message-ID: <4B716B38.9010700@denninger.net> Date: Tue, 09 Feb 2010 08:03:36 -0600 From: Karl Denninger User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jeremy Chadwick References: <4B6F9A8D.4050907@langille.org> <4B70FEEC.6070007@modulus.org> <20100209063310.GA23387@icarus.home.lan> <4B715AC6.5090500@denninger.net> <20100209134456.GA37029@icarus.home.lan> In-Reply-To: <20100209134456.GA37029@icarus.home.lan> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------090804020601000003070405" X-Antivirus: avast! (VPS 100209-0, 02/09/2010), Outbound message X-Antivirus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 14:05:05 -0000 This is a multi-part message in MIME format. --------------090804020601000003070405 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jeremy Chadwick wrote: > On Tue, Feb 09, 2010 at 06:53:26AM -0600, Karl Denninger wrote: > >> Jeremy Chadwick wrote: >> >>> On Tue, Feb 09, 2010 at 05:21:32PM +1100, Andrew Snow wrote: >>> >>> >>>> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H >>>> >>>> Supermicro just released a new Mini-ITX fanless Atom server board >>>> with 6xSATA ports (based on Intel ICH9) and a PCIe 16x slot. It >>>> takes up to 4GB of RAM, and there's even a version with KVM-over-LAN >>>> for headless operation and remote management. >>>> >>>> >>> Neat hardware. But with regards to the KVM-over-LAN stuff: it's IPMI, >>> and Supermicro has a very, *very* long history of having shoddy IPMI >>> support. I've been told the latter by too many different individuals in >>> the industry (some co-workers, some work at Yahoo, some at Rackable, >>> etc.) for me to rely on it. If you *have* to go this route, make sure >>> you get the IPMI module which has its own dedicated LAN port on the >>> module and ***does not*** piggyback on top of an existing LAN port on >>> the mainboard. >>> >>> >> What's wrong with the Supermicro IPMI implementations? I have several - >> all have a SEPARATE LAN port on the main board for the IPMI KVM >> (separate and distinct from the board's primary LAN ports), and I've not >> had any trouble with any of them. >> > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2008-01/msg01206.html > http://forums.freebsd.org/showthread.php?t=7750 > http://www.beowulf.org/archive/2007-November/019925.html > http://bivald.com/lessons-learned/2009/06/supermicro_ipmi_problems_web_i.html > http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044248.html > http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044237.html > > (Last thread piece does mention that the user was able to get keyboard > working by disabling umass(4) of all things) > > It gets worse when you use one of the IPMI modules that piggybacks on an > existing Ethernet port -- the NIC driver for the OS, from the ground up, > has to be fully aware of ASF and any quirks/oddities involved. For > example, on bge(4) and bce(4), you'll find this (bge mentioned below): > > hw.bge.allow_asf > Allow the ASF feature for cooperating with IPMI. Can cause sys- > tem lockup problems on a small number of systems. Disabled by > default. > > So unless the administrator intentionally sets the loader tunable prior > to booting the OS installation, they'll find all kinds of MAC problems > as a result of the IPMI piggybacking. "Why isn't this enabled by > default?" I believe because there were reports of failures/problems on > people's systems who *did not* have IPMI cards. Lose-lose situation. > > If you really want me to dig up people at Yahoo who have dealt with IPMI > on thousands of Supermicro servers and the insanity involved (due to > bugs, quirks, or implementation differences between the IPMI firmwares > and which revision/model of module used), I can do so. Most of the > complaints I've heard of stem from serial-over-IPMI. I don't think > it'd be a very positive/"supportive" thread, however. :-) > > One similar product that does seem to work well is iLO, available on > HP/Compaq hardware. > I load these things over the IPKVM all the time. I leave a DVD-ROM in the drive when I install them and my initial load is done over the IPKVM on the board. It "just works." Maybe they have had trouble in the past (most of those complaints look to be 2007/2008 issues), but the current stuff I use from them (their dual XEON boards) haven't given me a lick of trouble. And you can't argue with the price of the boards I use, considering that they have dual gigabit networking ports plus a separate IPMI LAN interface, support ECC memory and dual Xeons. I don't use the IPMI protocol itself but I **DO** use the remote console and management over HTTPS. No problems at all and FreeBSD has yet to throw up on it in any way. -- Karl --------------090804020601000003070405-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 14:06:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03D0E106568D for ; Tue, 9 Feb 2010 14:06:10 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 8988E8FC17 for ; Tue, 9 Feb 2010 14:06:09 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o19E66o7007047 for ; Tue, 9 Feb 2010 15:06:08 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id BB86524 for ; Tue, 9 Feb 2010 15:06:06 +0100 (CET) Date: Tue, 9 Feb 2010 15:06:06 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-stable@freebsd.org Message-Id: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.9.135416 Subject: zpool vdev vs. glabel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 14:06:10 -0000 Hi, I have created a raidz2 with disk I labeled with glabel before. Right after creation this pool looked fine, using devices label/tank[1-6]. I did some tests with replacing/swapping disks and so on. After doing a zpool offline tank label/tank6 remove disk camcontrol rescan all insert disk camcontrol rescan all zpool online tank label/tank6 I got the disk back, but not under the requested label, but under the da device name: pool: tank state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:56:37 2010 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/tank1 ONLINE 0 0 0 8.50K resilvered label/tank2 ONLINE 0 0 0 7.50K resilvered label/tank3 ONLINE 0 0 0 8.50K resilvered label/tank4 ONLINE 0 0 0 7.50K resilvered label/tank5 ONLINE 0 0 0 9K resilvered da6 ONLINE 0 0 0 13.5K resilvered errors: No known data errors Why does this happen? Is there any way to get zfs to use the label again? After the device is in use, the label in /dev/label disappears. When taking the device offline again, the label is there, but cannot be used: pigpen# zpool offline tank da6 pigpen# zpool status pool: system state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:49:14 2010 config: NAME STATE READ WRITE CKSUM system ONLINE 0 0 0 mirror ONLINE 0 0 0 label/system1 ONLINE 3 617 0 126K resilvered label/system2 ONLINE 0 0 0 41K resilvered errors: No known data errors pool: tank state: DEGRADED status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:56:37 2010 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 label/tank1 ONLINE 0 0 0 8.50K resilvered label/tank2 ONLINE 0 0 0 7.50K resilvered label/tank3 ONLINE 0 0 0 8.50K resilvered label/tank4 ONLINE 0 0 0 7.50K resilvered label/tank5 ONLINE 0 0 0 9K resilvered da6 OFFLINE 0 38 0 13.5K resilvered errors: No known data errors pigpen# ll /dev/label/ total 0 crw-r----- 1 root operator 0, 104 Feb 9 14:04 lisacrypt1 crw-r----- 1 root operator 0, 112 Feb 9 14:04 lisacrypt2 crw-r----- 1 root operator 0, 113 Feb 9 14:04 lisacrypt3 crw-r----- 1 root operator 0, 134 Feb 9 14:48 system1 crw-r----- 1 root operator 0, 115 Feb 9 14:04 system2 crw-r----- 1 root operator 0, 116 Feb 9 14:04 tank1 crw-r----- 1 root operator 0, 117 Feb 9 14:04 tank2 crw-r----- 1 root operator 0, 118 Feb 9 14:04 tank3 crw-r----- 1 root operator 0, 101 Feb 9 14:04 tank4 crw-r----- 1 root operator 0, 102 Feb 9 14:04 tank5 crw-r----- 1 root operator 0, 103 Feb 9 15:02 tank6 pigpen# zpool online tank label/tank6 cannot online label/tank6: no such device in pool In a different thread I found the hint to use zpool replace to get to the usage of labels, but this seems not possible, either: pigpen# zpool replace tank label/tank6 invalid vdev specification use '-f' to override the following errors: /dev/label/tank6 is part of active pool 'tank' pigpen# zpool replace -f tank label/tank6 invalid vdev specification the following errors must be manually repaired: /dev/label/tank6 is part of active pool 'tank' pigpen# zpool replace -f tank da6 label/tank6 invalid vdev specification the following errors must be manually repaired: /dev/label/tank6 is part of active pool 'tank' I'm running out of ideas here... cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 14:09:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0006D1065672 for ; Tue, 9 Feb 2010 14:09:44 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 86F3B8FC1A for ; Tue, 9 Feb 2010 14:09:44 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 25so865962eya.3 for ; Tue, 09 Feb 2010 06:09:43 -0800 (PST) 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 :content-transfer-encoding; bh=PunBIPruX64gqRppkafaCtK85l+iVX4zGB6EtB8reTE=; b=mWUPscLVhZzrZG3/0LdJ2gbepHk/TfP30R94M1oay1GXt5F/cei1qPEt0oqT2nYWs5 GZKjGTfHLhHrPvzg7JdrsXSOjzCo3TN1lKiCF3BFcjqaSCgTk2CroobRePPiySw0Mqbq fElp8eapBUE8zl8dUzdMVcDV84EbF0M9mfGfU= 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:content-transfer-encoding; b=I+fqK0RRp6x/fo1ISeIUcmoUu93H3a/za8vBVh8I4FDrT9OPqd/xyglljHfgszlrLj yAp1H4nc4PHWmXwnpEIAnjBT1N4WyZduL4kkPyQibHLuqvnPzyUmiOIV1tK8AB+JKpAm QleeSWU8EEhbpHkz8X7L0YgTqcz1N0Ie5hpBY= MIME-Version: 1.0 Received: by 10.213.44.3 with SMTP id y3mr2418362ebe.62.1265724583361; Tue, 09 Feb 2010 06:09:43 -0800 (PST) In-Reply-To: References: <4B6F9A8D.4050907@langille.org> <2e027be01002090451w2b4506a0ofb5ab55c647540a@mail.gmail.com> Date: Tue, 9 Feb 2010 14:09:43 +0000 Message-ID: <2e027be01002090609y28be404dl1bb610d047b15f9b@mail.gmail.com> From: Tom Evans To: Dan Langille Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Charles Sprickman , FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 14:09:45 -0000 On Tue, Feb 9, 2010 at 1:45 PM, Dan Langille wrote: > > On Tue, February 9, 2010 7:51 am, Tom Evans wrote: >> On Tue, Feb 9, 2010 at 6:15 AM, Charles Sprickman wrote= : >>> .... >>> Here's the list: >>> >>> http://secure.newegg.com/WishList/PublicWishDetail.aspx?WishListNumber= =3D8441629 >>> >>> Just over $1K, and I've got 4 nice drives, ECC memory, and a server >>> board. >>> Going with the celeron saved a ton of cash with no impact on ZFS that I >>> can >>> discern, and again, going with a cheap tower case slashed the cost as >>> well. >>> =C2=A0That whole combo works great. =C2=A0Now when I use up those 6 SAT= A ports, >>> I >>> don't know how to get more cheaply, but I'll worry about that later... >>> >>> Charles >>> >> >> As long as those SATA ports are AHCI compliant, should work quite >> nicely with a SiI port multiplier. Failing that, a simple 2 port SiI >> PCI-E SATA card (supported by siis(4) driver) + 2 x SiI port >> multiplier would give you 10 extra SATA ports. >> >> My SiI PCI-E card cost =C2=A315, and the PM about =C2=A350, so it is abo= ut >> =C2=A313/port, or ~$20/port. Probably can get the components cheaper in = the >> US actually. I also found some nice simple drive racks for =C2=A320/4 >> drives - not completely hotswappable, but much easier to replace than >> screwed into the case. > > Now there's an idea. Drive racks? =C2=A0Got a URL? > > These aren't the exact racks I bought, they seem to be discontinued (glad I bought 3 at once!), slightly more expensive, but same idea: http://www.scan.co.uk/Products/Silverstone-SST-CFP51B-Aluminum-Bay-converte= r-3x525-to-4x35-in-Black-with-120mm-Fan-RoHS I got the SiI add-in card and port multiplier from the same place: http://www.scan.co.uk/Products/Lycom-PE-103-x2-Port-SATAII-3Gbps-PCI-E-Cont= roller-Card-with-NCQ-PC-MAC-Linux http://www.scan.co.uk/Products/Lycom-ST-126RM-SATA-II-3Gbps-1-To-5-Port-Mul= tiplier-bridge-board-(for-Rack-Mount) For fixing the portmultiplier into the case, I recommend No More Nails :) I bought one of those cases that has 5.25" bays all down the front - 10 bays on mine, 1 with a DVD recorder, 9 filled with three of those drive racks, which gives me 12 'easily accessible' drive bays, 2 internal ones. With 6 SATA ports on the motherboard, together with the SiI controller + one portmultiplier, I have 12 bays and 12 SATA ports for not too much. I currently have 6 of them filled with 1.5Tb SATA drives in a raidz pool, and can expand the pool by adding another 6 as I run out of space. Works very nicely for my needs :) One thing to point out about using a PM like this: you won't get fantastic bandwidth out of it. For my needs (home storage server), this really doesn't matter, I just want oodles of online storage, with redundancy and reliability. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 14:15:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D849106566B for ; Tue, 9 Feb 2010 14:15:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id E43C08FC16 for ; Tue, 9 Feb 2010 14:15:48 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta09.emeryville.ca.mail.comcast.net with comcast id fpU71d0041u4NiLA9qFprk; Tue, 09 Feb 2010 14:15:49 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta21.emeryville.ca.mail.comcast.net with comcast id fqFo1d00D3S48mS8hqFo1l; Tue, 09 Feb 2010 14:15:49 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 647321E3033; Tue, 9 Feb 2010 06:15:47 -0800 (PST) Date: Tue, 9 Feb 2010 06:15:47 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100209141547.GA37876@icarus.home.lan> References: <4B6F9A8D.4050907@langille.org> <2e027be01002090451w2b4506a0ofb5ab55c647540a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 14:15:49 -0000 On Tue, Feb 09, 2010 at 08:45:12AM -0500, Dan Langille wrote: > On Tue, February 9, 2010 7:51 am, Tom Evans wrote: > > On Tue, Feb 9, 2010 at 6:15 AM, Charles Sprickman wrote: > >> .... > >> Here's the list: > >> > >> http://secure.newegg.com/WishList/PublicWishDetail.aspx?WishListNumber=8441629 > >> > >> Just over $1K, and I've got 4 nice drives, ECC memory, and a server > >> board. > >> Going with the celeron saved a ton of cash with no impact on ZFS that I > >> can > >> discern, and again, going with a cheap tower case slashed the cost as > >> well. > >>  That whole combo works great.  Now when I use up those 6 SATA ports, > >> I > >> don't know how to get more cheaply, but I'll worry about that later... > >> > >> Charles > >> > > > > As long as those SATA ports are AHCI compliant, should work quite > > nicely with a SiI port multiplier. Failing that, a simple 2 port SiI > > PCI-E SATA card (supported by siis(4) driver) + 2 x SiI port > > multiplier would give you 10 extra SATA ports. > > > > My SiI PCI-E card cost £15, and the PM about £50, so it is about > > £13/port, or ~$20/port. Probably can get the components cheaper in the > > US actually. I also found some nice simple drive racks for £20/4 > > drives - not completely hotswappable, but much easier to replace than > > screwed into the case. > > Now there's an idea. Drive racks? Got a URL? http://www.supermicro.com/products/chassis/mobileRack/ I'd recommend staying away from anything with SAF-TE (for SCSI) or SES2 (for SAS or SATA) however. At least with regards to SCSI, I've seen quite a few of the QLogic SAF-TE chips get in the way of drive failures and start changing SCSI IDs of all the disks (yes you read that right) on the bus willy-nilly. That means that basically the CSE-M34T or CSE-M35T-1 would be good choices. Yes they come in Black. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 14:27:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A105A1065670 for ; Tue, 9 Feb 2010 14:27:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 88ED28FC12 for ; Tue, 9 Feb 2010 14:27:00 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta01.emeryville.ca.mail.comcast.net with comcast id fpzQ1d00C0FhH24A1qT0na; Tue, 09 Feb 2010 14:27:00 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta08.emeryville.ca.mail.comcast.net with comcast id fqSz1d00B3S48mS8UqSzLW; Tue, 09 Feb 2010 14:27:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4C2161E3033; Tue, 9 Feb 2010 06:26:58 -0800 (PST) Date: Tue, 9 Feb 2010 06:26:58 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100209142658.GA38072@icarus.home.lan> References: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: zpool vdev vs. glabel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 14:27:00 -0000 On Tue, Feb 09, 2010 at 03:06:06PM +0100, Gerrit Kühn wrote: > Hi, > > I have created a raidz2 with disk I labeled with glabel before. Right > after creation this pool looked fine, using devices label/tank[1-6]. > > I did some tests with replacing/swapping disks and so on. After doing a > > zpool offline tank label/tank6 > remove disk > camcontrol rescan all > insert disk > camcontrol rescan all > zpool online tank label/tank6 > > I got the disk back, but not under the requested label, but under the da > device name: > > pool: tank > state: ONLINE > scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:56:37 > 2010 config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > label/tank1 ONLINE 0 0 0 8.50K resilvered > label/tank2 ONLINE 0 0 0 7.50K resilvered > label/tank3 ONLINE 0 0 0 8.50K resilvered > label/tank4 ONLINE 0 0 0 7.50K resilvered > label/tank5 ONLINE 0 0 0 9K resilvered > da6 ONLINE 0 0 0 13.5K resilvered > > errors: No known data errors > > > > Why does this happen? Is there any way to get zfs to use the label again? > After the device is in use, the label in /dev/label disappears. When > taking the device offline again, the label is there, but cannot be used: > > pigpen# zpool offline tank da6 > pigpen# zpool status > pool: system > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are > unaffected. action: Determine if the device needs to be replaced, and > clear the errors using 'zpool clear' or replace the device with 'zpool > replace'. see: http://www.sun.com/msg/ZFS-8000-9P > scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:49:14 > 2010 config: > > NAME STATE READ WRITE CKSUM > system ONLINE 0 0 0 > mirror ONLINE 0 0 0 > label/system1 ONLINE 3 617 0 126K resilvered > label/system2 ONLINE 0 0 0 41K resilvered > > errors: No known data errors > > pool: tank > state: DEGRADED > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are > unaffected. action: Determine if the device needs to be replaced, and > clear the errors using 'zpool clear' or replace the device with 'zpool > replace'. see: http://www.sun.com/msg/ZFS-8000-9P > scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:56:37 > 2010 config: > > NAME STATE READ WRITE CKSUM > tank DEGRADED 0 0 0 > raidz2 DEGRADED 0 0 0 > label/tank1 ONLINE 0 0 0 8.50K resilvered > label/tank2 ONLINE 0 0 0 7.50K resilvered > label/tank3 ONLINE 0 0 0 8.50K resilvered > label/tank4 ONLINE 0 0 0 7.50K resilvered > label/tank5 ONLINE 0 0 0 9K resilvered > da6 OFFLINE 0 38 0 13.5K resilvered > > errors: No known data errors > pigpen# ll /dev/label/ > total 0 > crw-r----- 1 root operator 0, 104 Feb 9 14:04 lisacrypt1 > crw-r----- 1 root operator 0, 112 Feb 9 14:04 lisacrypt2 > crw-r----- 1 root operator 0, 113 Feb 9 14:04 lisacrypt3 > crw-r----- 1 root operator 0, 134 Feb 9 14:48 system1 > crw-r----- 1 root operator 0, 115 Feb 9 14:04 system2 > crw-r----- 1 root operator 0, 116 Feb 9 14:04 tank1 > crw-r----- 1 root operator 0, 117 Feb 9 14:04 tank2 > crw-r----- 1 root operator 0, 118 Feb 9 14:04 tank3 > crw-r----- 1 root operator 0, 101 Feb 9 14:04 tank4 > crw-r----- 1 root operator 0, 102 Feb 9 14:04 tank5 > crw-r----- 1 root operator 0, 103 Feb 9 15:02 tank6 > > pigpen# zpool online tank label/tank6 > cannot online label/tank6: no such device in pool > > In a different thread I found the hint to use zpool replace to get to the > usage of labels, but this seems not possible, either: > > pigpen# zpool replace tank label/tank6 > invalid vdev specification > use '-f' to override the following errors: > /dev/label/tank6 is part of active pool 'tank' > > pigpen# zpool replace -f tank label/tank6 > invalid vdev specification > the following errors must be manually repaired: > /dev/label/tank6 is part of active pool 'tank' > > pigpen# zpool replace -f tank da6 label/tank6 > invalid vdev specification > the following errors must be manually repaired: > /dev/label/tank6 is part of active pool 'tank' > > > I'm running out of ideas here... Would "zpool export" and "zpool import" be necessary in this case? Also, I'm a little confused as to the use of glabel in this case. In what condition do your disk indices (e.g. X of daX) change? Are you yanking multiple disks out of a system at the same time and then shoving them back into different drive bays? Are you switching between storage subsystem drivers (ahci(4) vs. ataahci(4), for example) regularly? I've yet to be convinced glabel is worth bothering with, unless the system adheres to one of the above situations (which are worthy of strangulation anyway ;-) ). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 14:37:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48AA81065676 for ; Tue, 9 Feb 2010 14:37:58 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id CC4878FC08 for ; Tue, 9 Feb 2010 14:37:57 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id E3B0219E019; Tue, 9 Feb 2010 15:37:55 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 78FDD19E023; Tue, 9 Feb 2010 15:37:53 +0100 (CET) Message-ID: <4B717340.6080901@quip.cz> Date: Tue, 09 Feb 2010 15:37:52 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.7) Gecko/20100104 SeaMonkey/2.0.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <4B6F9A8D.4050907@langille.org> <4B70FEEC.6070007@modulus.org> <20100209063310.GA23387@icarus.home.lan> <4B715AC6.5090500@denninger.net> <20100209134456.GA37029@icarus.home.lan> In-Reply-To: <20100209134456.GA37029@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 14:37:58 -0000 Jeremy Chadwick wrote: > On Tue, Feb 09, 2010 at 06:53:26AM -0600, Karl Denninger wrote: [...] > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2008-01/msg01206.html > http://forums.freebsd.org/showthread.php?t=7750 > http://www.beowulf.org/archive/2007-November/019925.html > http://bivald.com/lessons-learned/2009/06/supermicro_ipmi_problems_web_i.html > http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044248.html > http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044237.html > > (Last thread piece does mention that the user was able to get keyboard > working by disabling umass(4) of all things) > > It gets worse when you use one of the IPMI modules that piggybacks on an > existing Ethernet port -- the NIC driver for the OS, from the ground up, > has to be fully aware of ASF and any quirks/oddities involved. For > example, on bge(4) and bce(4), you'll find this (bge mentioned below): > > hw.bge.allow_asf > Allow the ASF feature for cooperating with IPMI. Can cause sys- > tem lockup problems on a small number of systems. Disabled by > default. > > So unless the administrator intentionally sets the loader tunable prior > to booting the OS installation, they'll find all kinds of MAC problems > as a result of the IPMI piggybacking. "Why isn't this enabled by > default?" I believe because there were reports of failures/problems on > people's systems who *did not* have IPMI cards. Lose-lose situation. > > If you really want me to dig up people at Yahoo who have dealt with IPMI > on thousands of Supermicro servers and the insanity involved (due to > bugs, quirks, or implementation differences between the IPMI firmwares > and which revision/model of module used), I can do so. Most of the > complaints I've heard of stem from serial-over-IPMI. I don't think > it'd be a very positive/"supportive" thread, however. :-) > > One similar product that does seem to work well is iLO, available on > HP/Compaq hardware. I can't agree with the last statement about HP's iLO. I have addon card in ML110 G5 (dedicated NIC), the card is "expensive" and bugs are amazing. The management NIC freezes once a day (or more often) with older firmware and must be restarted from inside the installed system by IPMI command on "localhost". With newer firmware, the interface is periodicaly restarded. The virtual media doesn't work at all. It is my worst experience with remote management cards. I believe that other HP servers with built-in card with different FW is working better, this is just my experience. Next one is eLOM in Sun Fire X2100 (shared NIC using bge + ASF). ASF works without problem, but virtual media works only if you are connecting by IP address, not by domain name (from Windows machines) and there is some issue with timeouts of virtual media / console. I reported this + 8 different bugs of web management interface to Sun more than year ago - none was fixed. Next place is for IBM 3650 + RSA II card (dedicated NIC). Expensive, something works, somthing not. For example the card can't read CPU temperature, so you will not recieve any alert in case of overheating. (it was 2 years ago, maybe newer firmware is fixed) Then I have one Supermicro Twin server 6016TT-TF with built-in IPMI / KVM with dedicated NIC port. I found one bug with fan rpm readings (half the number compared to BIOS numbers) and one problem with FreeBSD 7.x sysinstall (USB keyboard not working, but sysinstall from 8.x works without problem). In installed FreeBSD system keyboard and virtual media is working without problems. On the top is Dell R610 DRAC (dedicated NIC) - I didn't find any bugs and there are a lot more features compared to concurrent products. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 14:56:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A48921065697 for ; Tue, 9 Feb 2010 14:56:29 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 320818FC14 for ; Tue, 9 Feb 2010 14:56:28 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o19EuQck009365; Tue, 9 Feb 2010 15:56:27 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 17B3A4F; Tue, 9 Feb 2010 15:56:26 +0100 (CET) Date: Tue, 9 Feb 2010 15:56:25 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jeremy Chadwick Message-Id: <20100209155625.a255a34d.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100209142658.GA38072@icarus.home.lan> References: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> <20100209142658.GA38072@icarus.home.lan> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.9.144527 Cc: freebsd-stable@freebsd.org Subject: Re: zpool vdev vs. glabel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 14:56:29 -0000 On Tue, 9 Feb 2010 06:26:58 -0800 Jeremy Chadwick wrote about Re: zpool vdev vs. glabel: JC> > I'm running out of ideas here... JC> Would "zpool export" and "zpool import" be necessary in this case? I tried that several times, does not change anything. JC> Also, I'm a little confused as to the use of glabel in this case. In JC> what condition do your disk indices (e.g. X of daX) change? Are you JC> yanking multiple disks out of a system at the same time and then JC> shoving them back into different drive bays? I just did not want to do hard-wiring da-devices in the kernel. I have two lsi controllers, and they do not even come up in the same order every time I boot (mpt0/mpt1), let alone the disks picking up the same daX every time. I thought labeling the disks would be a good idea to prevent all these kinds of problems. JC> Are you switching JC> between storage subsystem drivers (ahci(4) vs. ataahci(4), for JC> example) regularly? No (not yet al least :-). JC> I've yet to be convinced glabel is worth bothering with, unless the JC> system adheres to one of the above situations (which are worthy of JC> strangulation anyway ;-) ). I would really like to know how this happened at all... meanwhile I used a spare disk under a different name to replace everything round-robin back to normal. However, I just recognized one more thing: pigpen# zpool status tank pool: tank state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 15:50:01 2010 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/tank1 ONLINE 0 0 0 11K resilvered label/tank2 ONLINE 0 0 0 10K resilvered label/tank3 ONLINE 0 0 0 11K resilvered label/tank4 ONLINE 0 0 0 10.5K resilvered label/tank5 ONLINE 0 0 0 11K resilvered label/tank6 ONLINE 0 0 0 15K resilvered errors: No known data errors pigpen# zpool offline tank label/tank5 pigpen# zpool status tank pool: tank state: DEGRADED status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 15:50:01 2010 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 label/tank1 ONLINE 0 0 0 11K resilvered label/tank2 ONLINE 0 0 0 10K resilvered label/tank3 ONLINE 0 0 0 11K resilvered label/tank4 ONLINE 0 0 0 10.5K resilvered label/tank5 ONLINE 0 0 0 11K resilvered label/tank6 OFFLINE 0 39 0 15K resilvered errors: No known data errors pigpen# zpool offline tank label/tank5 cannot offline label/tank5: no valid replicas Why can't I offline a second disk? This is a raidz2 volume, after all?! cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 14:59:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7148F1065676 for ; Tue, 9 Feb 2010 14:59:43 +0000 (UTC) (envelope-from ru@FreeBSD.org) Received: from mail.vega.ru (mail.vega.ru [90.156.167.5]) by mx1.freebsd.org (Postfix) with ESMTP id 2962B8FC2E for ; Tue, 9 Feb 2010 14:59:42 +0000 (UTC) Received: from [10.100.124.99] (helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NerM6-000L90-FO; Tue, 09 Feb 2010 17:46:22 +0300 Date: Tue, 9 Feb 2010 17:46:17 +0300 From: Ruslan Ermilov To: Ruslan Mahmatkhanov Message-ID: <20100209144617.GB72929@edoofus.dev.vega.ru> References: <4B5B5D46.3040400@yandex.ru> <20100124014528.GB28672@icarus.home.lan> <4B5BFB8E.4040209@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B5BFB8E.4040209@yandex.ru> Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Strange symbols in man-pages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 14:59:43 -0000 On Sun, Jan 24, 2010 at 10:49:34AM +0300, Ruslan Mahmatkhanov wrote: > On 24.01.2010 04:45, Jeremy Chadwick wrote: > > On Sat, Jan 23, 2010 at 11:34:14PM +0300, Ruslan Mahmatkhanov wrote: > >> I'm viewing dd man-page in gnome with gnome-terminal and i see some > >> strange symbols instead `-`. For example from man dd(1): > >> http://www.onlinedisk.ru/get_image.php?id=327964 > >> > >> The problem is rised only when i on ru_RU.UTF-8 locale. There is no > >> problem with C-locale. > >> > >> Is this known problem and does anybody have a solution? > >> > >> Thanks in advance and keep me in Cc: please (i'm not subscribed to > >> freebsd-stable@). > >> > >> PS. Using 8.0-STABLE. > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/053804.html > > > > So i can avoid this by setting alias in .cshrc: > alias man env LANG=C man > > Thanks. I've fixed this recently. -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 15:01:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7953C1065670 for ; Tue, 9 Feb 2010 15:01:25 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4A7A88FC25 for ; Tue, 9 Feb 2010 15:01:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id BA6D7508B6; Tue, 9 Feb 2010 15:01:24 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSUEdyH0EO+s; Tue, 9 Feb 2010 15:01:23 +0000 (GMT) Received: from nyi.unixathome.org (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 42E1F50830; Tue, 9 Feb 2010 15:01:23 +0000 (GMT) Received: from 68.64.144.211 (SquirrelMail authenticated user dan) by nyi.unixathome.org with HTTP; Tue, 9 Feb 2010 10:01:23 -0500 Message-ID: In-Reply-To: <2e027be01002090609y28be404dl1bb610d047b15f9b@mail.gmail.com> References: <4B6F9A8D.4050907@langille.org> <2e027be01002090451w2b4506a0ofb5ab55c647540a@mail.gmail.com> <2e027be01002090609y28be404dl1bb610d047b15f9b@mail.gmail.com> Date: Tue, 9 Feb 2010 10:01:23 -0500 From: "Dan Langille" To: "Tom Evans" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Charles Sprickman , FreeBSD Stable , Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 15:01:25 -0000 On Tue, February 9, 2010 9:09 am, Tom Evans wrote: > On Tue, Feb 9, 2010 at 1:45 PM, Dan Langille wrote: > One thing to point out about using a PM like this: you won't get > fantastic bandwidth out of it. For my needs (home storage server), > this really doesn't matter, I just want oodles of online storage, with > redundancy and reliability. A PM? What's that? Yes, my priority is reliable storage. Speed is secondary. What bandwidth are you getting? -- Dan Langille -- http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 15:03:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5BF0106568B for ; Tue, 9 Feb 2010 15:03:00 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (unknown [IPv6:2002:51af:3dc3:0:20c:29ff:fece:79f3]) by mx1.freebsd.org (Postfix) with ESMTP id 324DE8FC1A for ; Tue, 9 Feb 2010 15:03:00 +0000 (UTC) Received: from [IPv6:2002:51af:3dc3:0:3944:6121:5245:7458] (unknown [IPv6:2002:51af:3dc3:0:3944:6121:5245:7458]) (Authenticated sender: svein-listmail) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id 9BDDB22 for ; Tue, 9 Feb 2010 16:03:04 +0100 (CET) Message-ID: <4B717923.7050805@stillbilde.net> Date: Tue, 09 Feb 2010 16:02:59 +0100 From: "Svein Skogen (Listmail Account)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B6F9A8D.4050907@langille.org> <4B70FEEC.6070007@modulus.org> <20100209063310.GA23387@icarus.home.lan> <4B715AC6.5090500@denninger.net> <20100209134456.GA37029@icarus.home.lan> <4B717340.6080901@quip.cz> In-Reply-To: <4B717340.6080901@quip.cz> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 15:03:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09.02.2010 15:37, Miroslav Lachman wrote: *SNIP* > > I can't agree with the last statement about HP's iLO. I have addon card > in ML110 G5 (dedicated NIC), the card is "expensive" and bugs are > amazing. The management NIC freezes once a day (or more often) with > older firmware and must be restarted from inside the installed system by > IPMI command on "localhost". With newer firmware, the interface is > periodicaly restarded. The virtual media doesn't work at all. It is my > worst experience with remote management cards. > I believe that other HP servers with built-in card with different FW is > working better, this is just my experience. > > Next one is eLOM in Sun Fire X2100 (shared NIC using bge + ASF). ASF > works without problem, but virtual media works only if you are > connecting by IP address, not by domain name (from Windows machines) and > there is some issue with timeouts of virtual media / console. > I reported this + 8 different bugs of web management interface to Sun > more than year ago - none was fixed. > > Next place is for IBM 3650 + RSA II card (dedicated NIC). Expensive, > something works, somthing not. For example the card can't read CPU > temperature, so you will not recieve any alert in case of overheating. > (it was 2 years ago, maybe newer firmware is fixed) > > Then I have one Supermicro Twin server 6016TT-TF with built-in IPMI / > KVM with dedicated NIC port. I found one bug with fan rpm readings (half > the number compared to BIOS numbers) and one problem with FreeBSD 7.x > sysinstall (USB keyboard not working, but sysinstall from 8.x works > without problem). In installed FreeBSD system keyboard and virtual media > is working without problems. > > On the top is Dell R610 DRAC (dedicated NIC) - I didn't find any bugs > and there are a lot more features compared to concurrent products. > I think the general consensus here is "nice theory lousy implementation", and the added migraine of no such thing as a common standard. Maybe creating a common standard for this could be a nice GSOC project, to build a nice "remote console" based on SSH and arm/mips? p.s. I've seen the various proprietary remote console solutions. They didn't really impress me much, so I ended up using off-the-shelf components for building my servers. Not necessarily cheaper, but at least it's under _MY_ control. //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg Østli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktxeSIACgkQODUnwSLUlKQrFgCgoWo9wjqQoQMUe2WmTm8wwB19 1QYAoKHy8i8B+sBd6eCkAN+hdfMscJW4 =gzs3 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 15:07:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 526F51065764 for ; Tue, 9 Feb 2010 15:07:37 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 35D278FC29 for ; Tue, 9 Feb 2010 15:07:36 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta08.emeryville.ca.mail.comcast.net with comcast id fpT01d0061Y3wxoA8r7dHL; Tue, 09 Feb 2010 15:07:37 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id fr7c1d00P3S48mS8br7dvf; Tue, 09 Feb 2010 15:07:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D947E1E3033; Tue, 9 Feb 2010 07:07:35 -0800 (PST) Date: Tue, 9 Feb 2010 07:07:35 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100209150735.GA39878@icarus.home.lan> References: <4B6F9A8D.4050907@langille.org> <2e027be01002090451w2b4506a0ofb5ab55c647540a@mail.gmail.com> <2e027be01002090609y28be404dl1bb610d047b15f9b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 15:07:37 -0000 On Tue, Feb 09, 2010 at 10:01:23AM -0500, Dan Langille wrote: > On Tue, February 9, 2010 9:09 am, Tom Evans wrote: > > On Tue, Feb 9, 2010 at 1:45 PM, Dan Langille wrote: > > One thing to point out about using a PM like this: you won't get > > fantastic bandwidth out of it. For my needs (home storage server), > > this really doesn't matter, I just want oodles of online storage, with > > redundancy and reliability. > > A PM? What's that? Port multiplier. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 15:16:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0E36106568D for ; Tue, 9 Feb 2010 15:16:15 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 41EDC8FC0C for ; Tue, 9 Feb 2010 15:16:14 +0000 (UTC) Received: by ewy3 with SMTP id 3so4676200ewy.13 for ; Tue, 09 Feb 2010 07:16:14 -0800 (PST) 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 :content-transfer-encoding; bh=NphJEjZcHKGqbOF4ClyNCPhHXPBe13PdLBhccs5VAvU=; b=FZBX6lNH59pUhpbBexr4hyRJNbPjjOxazVejB06HOJOkJMeBeRbNgG+fTwNwAZW1kR RZOCud0t/TrxchBNFGXWQBwL22j39x9rL8LqZ9zxuJ8Up4SN3tdd8ScAw8wUp9o6as1P 1hwce3c5Qh6TFZ4vg+XuhLbGFozPhrRg2+P0Y= 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:content-transfer-encoding; b=HcJsRRIHYZ34Q7EgrIj4PGAeWLQsAhEdfexdCsbv3CBtMSJfgzvacCt/WROQ8vWA9c KDEoyz7i5TQVo7FAdv/hrJ4Imb9hESIVWSFctkY86uPtkYhGirM6vZC3pa/5NuYVzwta 5TFUNKYBvq+ZOqIUeDqyHOuTvsMrFYjlmm4po= MIME-Version: 1.0 Received: by 10.213.44.3 with SMTP id y3mr2492640ebe.62.1265728573978; Tue, 09 Feb 2010 07:16:13 -0800 (PST) In-Reply-To: References: <4B6F9A8D.4050907@langille.org> <2e027be01002090451w2b4506a0ofb5ab55c647540a@mail.gmail.com> <2e027be01002090609y28be404dl1bb610d047b15f9b@mail.gmail.com> Date: Tue, 9 Feb 2010 15:16:13 +0000 Message-ID: <2e027be01002090716y77213c45pb937e22151a2c238@mail.gmail.com> From: Tom Evans To: Dan Langille Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Charles Sprickman , FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 15:16:15 -0000 On Tue, Feb 9, 2010 at 3:01 PM, Dan Langille wrote: > > On Tue, February 9, 2010 9:09 am, Tom Evans wrote: >> On Tue, Feb 9, 2010 at 1:45 PM, Dan Langille wrote: >> One thing to point out about using a PM like this: you won't get >> fantastic bandwidth out of it. For my needs (home storage server), >> this really doesn't matter, I just want oodles of online storage, with >> redundancy and reliability. > > > A PM? =C2=A0What's that? > > Yes, my priority is reliable storage. =C2=A0Speed is secondary. > > What bandwidth are you getting? > PM =3D Port Multiplier I'm getting disk speed, as I only have one device behind the PM currently (just making sure it works properly :). The limits are that the link from siis to the PM is SATA (3Gb/s, 375MB/s), and the siis sits on a PCIe 1x bus (2Gb/s, 250 MB/s), so the bandwidth from that is shared amongst the up-to 5 disks behind the PM. Writing from /dev/zero to the pool, I get around 120MB/s. Reading from the pool, and writing to /dev/null, I get around 170 MB/s. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 16:18:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20ADE1065672 for ; Tue, 9 Feb 2010 16:18:22 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id DB59B8FC1F for ; Tue, 9 Feb 2010 16:18:21 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id A3BFC2BB341; Tue, 9 Feb 2010 11:18:20 -0500 (EST) Date: Tue, 9 Feb 2010 11:18:19 -0500 From: "Peter C. Lai" To: Dan Langille Message-ID: <20100209161817.GI4648@cesium.hyperfine.info> References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B71490B.6030602@langille.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Charles Sprickman , FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:18:22 -0000 On 2010-02-09 06:37:47AM -0500, Dan Langille wrote: > Charles Sprickman wrote: >> On Mon, 8 Feb 2010, Dan Langille wrote: > > Also, it seems like >> people who use zfs (or gmirror + gstripe) generally end up buying pricey >> hardware raid cards for compatibility reasons. There seem to be no decent >> add-on SATA cards that play nice with FreeBSD other than that weird >> supermicro card that has to be physically hacked about to fit. Mostly only because certain cards have issues w/shoddy JBOD implementation. Some cards (most notably ones like Adaptec 2610A which was rebranded by Dell as the "CERC SATA 1.5/6ch" back in the day) won't let you run the drives in passthrough mode and seem to all want to stick their grubby little RAID paws into your JBOD setup (i.e. the only way to have minimal participation from the "hardware" RAID is to set each disk as its own RAID-0/volume in the controller BIOS) which then cascades into issues with SMART, AHCI, "triple caching"/write reordering, etc on the FreeBSD side (the controller's own craptastic cache, ZFS vdev cache, vmm/app cache, oh my!). So *some* people go with something tried-and-true (basically bordering on server-level cards that let you ditch any BIOS type of RAID config and present the raw disk devices to the kernel). > > They use software RAID and hardware RAID at the same time? I'm not sure > what you mean by this. Compatibility with FreeBSD? > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 16:29:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 467361065672 for ; Tue, 9 Feb 2010 16:29:52 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1578D8FC13 for ; Tue, 9 Feb 2010 16:29:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 48FA8508B4; Tue, 9 Feb 2010 16:29:51 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-8WFhEMvU96; Tue, 9 Feb 2010 16:29:50 +0000 (GMT) Received: from nyi.unixathome.org (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 936CA508B0; Tue, 9 Feb 2010 16:29:49 +0000 (GMT) Received: from 68.64.144.211 (SquirrelMail authenticated user dan) by nyi.unixathome.org with HTTP; Tue, 9 Feb 2010 11:29:50 -0500 Message-ID: <7118399d109e0c1849ae17ffa8ee9c66.squirrel@nyi.unixathome.org> In-Reply-To: <2e027be01002090716y77213c45pb937e22151a2c238@mail.gmail.com> References: <4B6F9A8D.4050907@langille.org> <2e027be01002090451w2b4506a0ofb5ab55c647540a@mail.gmail.com> <2e027be01002090609y28be404dl1bb610d047b15f9b@mail.gmail.com> <2e027be01002090716y77213c45pb937e22151a2c238@mail.gmail.com> Date: Tue, 9 Feb 2010 11:29:50 -0500 From: "Dan Langille" To: "Tom Evans" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Charles Sprickman , FreeBSD Stable , Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:29:52 -0000 On Tue, February 9, 2010 10:16 am, Tom Evans wrote: > On Tue, Feb 9, 2010 at 3:01 PM, Dan Langille wrote: >> >> On Tue, February 9, 2010 9:09 am, Tom Evans wrote: >>> On Tue, Feb 9, 2010 at 1:45 PM, Dan Langille wrote: >>> One thing to point out about using a PM like this: you won't get >>> fantastic bandwidth out of it. For my needs (home storage server), >>> this really doesn't matter, I just want oodles of online storage, with >>> redundancy and reliability. >> >> >> A PM?  What's that? >> >> Yes, my priority is reliable storage.  Speed is secondary. >> >> What bandwidth are you getting? >> > > PM = Port Multiplier > > I'm getting disk speed, as I only have one device behind the PM > currently (just making sure it works properly :). The limits are that > the link from siis to the PM is SATA (3Gb/s, 375MB/s), and the siis > sits on a PCIe 1x bus (2Gb/s, 250 MB/s), so the bandwidth from that is > shared amongst the up-to 5 disks behind the PM. > > Writing from /dev/zero to the pool, I get around 120MB/s. Reading from > the pool, and writing to /dev/null, I get around 170 MB/s. > That leads me to conclude that a number of SATA cards is better than a port multiplier. But the impression I'm getting is that few of these work well with FreeBSD. Which is odd... I thought these cards would merely present the HDD to the hardware and no diver was required. As opposed to RAID cards for which OS-specific drivers are required. -- Dan Langille -- http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 16:30:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D47011065744; Tue, 9 Feb 2010 16:30:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6E0B68FC16; Tue, 9 Feb 2010 16:30:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKMbcUuDaFvG/2dsb2JhbADaV4RUBA X-IronPort-AV: E=Sophos;i="4.49,437,1262581200"; d="scan'208";a="64798280" Received: from amazon.cs.uoguelph.ca ([131.104.91.198]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 09 Feb 2010 11:30:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 664B32101A0; Tue, 9 Feb 2010 11:30:08 -0500 (EST) X-Virus-Scanned: amavisd-new at amazon.cs.uoguelph.ca Received: from amazon.cs.uoguelph.ca ([127.0.0.1]) by localhost (amazon.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fwn95C3UoX3; Tue, 9 Feb 2010 11:30:07 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 651DE21019D; Tue, 9 Feb 2010 11:30:07 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o19GfPW19098; Tue, 9 Feb 2010 11:41:25 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 9 Feb 2010 11:41:25 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "O. Hartmann" In-Reply-To: <4B712B54.4020000@zedat.fu-berlin.de> Message-ID: References: <4B6FE550.9020506@zedat.fu-berlin.de> <4B70497B.1000908@zedat.fu-berlin.de> <4B712B54.4020000@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: NFSv4: mount -t nsf4 not the same as mount_newnfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:30:10 -0000 On Tue, 9 Feb 2010, O. Hartmann wrote: > Well, I guess I havn't uderstood everything of NFSv4. The 'concept' of the > 'root' is new to me, maybe there are some deeper explanation of the purpose? > Are there supposed to be more than one 'root' enries or only one? > Only to specify different security flavours for different client host IP#s. There is only one "root" location in the file system tree. This was done for NFSv4 to avoid any need for the mount protocol. See below. > At this very moment mounting seems to work, but I always get a 'permission > denied' error on every ZFS exported filesystem. Doing the same with UFS2 > filesystems, everything works as expected. > In NFSv4 "mount" does very little, since it does not use the mount protocol. It basically passes a "pathname" from the NFSv4 "root" into the kernel for later use. (Since UFS doesn't actually check exports, the experimental server checks them, but "cheats" and allows a minimal set of NFSv4 Operations on non-exported volumes, so that this "pathname" can be traversed to the exported volume. At this time ZFS checks exports. As such everything in the tree from the "root" specified by the "V4:" line must be exported for ZFS to work. I believe others have gotten a ZFS export to work, but I have no experience with it at this time. > Is there a way to inspect the exports and mounts for the used NFS-protocol? Not that I am aware. (Excluding ZFS, which I don't know anything about, the /etc/exports file specifies the exports.) > When issuing 'mount', the 'backup' mount is repoted to be 'newnfs', I assume > this reflects NFSv4 being used, now I need to figure out what's going wrong > with the ZFS export. NFS export of the ZFS filesystem is enabled, but as far > as I know, this feature is not used in FreeBSD since ZFS in FreeBSD lacks of > the capabilities of autonomously exporting its via NFS - well, I'm not an > expert in this matter. > I'm definitely not a ZFS expert either:-) I think the mount command is showing you that the mount point was created ("newnfs" refers to the experimental client), but as noted above, that doesn't indicate that it is accessible. (If you haven't tried moving the "V4: /backup ..." that moves the NFSv4 "root" to /backup, you should do that and see how it goes.) Good luck with it, rick From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 16:31:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57D13106566B for ; Tue, 9 Feb 2010 16:31:58 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 173068FC1F for ; Tue, 9 Feb 2010 16:31:57 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id EF9F22BB346; Tue, 9 Feb 2010 11:31:56 -0500 (EST) Date: Tue, 9 Feb 2010 11:31:55 -0500 From: "Peter C. Lai" To: Tom Evans Message-ID: <20100209163155.GK4648@cesium.hyperfine.info> References: <4B6F9A8D.4050907@langille.org> <2e027be01002090451w2b4506a0ofb5ab55c647540a@mail.gmail.com> <2e027be01002090609y28be404dl1bb610d047b15f9b@mail.gmail.com> <2e027be01002090716y77213c45pb937e22151a2c238@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2e027be01002090716y77213c45pb937e22151a2c238@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Charles Sprickman , FreeBSD Stable , Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:31:58 -0000 That's faster than just about anything I have at home. So you should be fine. It should be good enough to serve as primary media center storage even (for retrievals, anyway, probably a tad bit slow for live transcoding). Also does anybody know if benching dd if=/dev/zero onto a zfs volume that has compression turned on might affect what dd (which is getting what it knows from vfs/vmm) might report? On 2010-02-09 03:16:13PM +0000, Tom Evans wrote: > On Tue, Feb 9, 2010 at 3:01 PM, Dan Langille wrote: > > > > On Tue, February 9, 2010 9:09 am, Tom Evans wrote: > >> On Tue, Feb 9, 2010 at 1:45 PM, Dan Langille wrote: > >> One thing to point out about using a PM like this: you won't get > >> fantastic bandwidth out of it. For my needs (home storage server), > >> this really doesn't matter, I just want oodles of online storage, with > >> redundancy and reliability. > > > > > > A PM?  What's that? > > > > Yes, my priority is reliable storage.  Speed is secondary. > > > > What bandwidth are you getting? > > > > PM = Port Multiplier > > I'm getting disk speed, as I only have one device behind the PM > currently (just making sure it works properly :). The limits are that > the link from siis to the PM is SATA (3Gb/s, 375MB/s), and the siis > sits on a PCIe 1x bus (2Gb/s, 250 MB/s), so the bandwidth from that is > shared amongst the up-to 5 disks behind the PM. > > Writing from /dev/zero to the pool, I get around 120MB/s. Reading from > the pool, and writing to /dev/null, I get around 170 MB/s. > > Cheers > > Tom > _______________________________________________ > 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" -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 16:36:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E48A106568B for ; Tue, 9 Feb 2010 16:36:43 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 66CF08FC12 for ; Tue, 9 Feb 2010 16:36:43 +0000 (UTC) Received: (qmail 55138 invoked from network); 9 Feb 2010 16:36:42 -0000 Received: from unknown (HELO ?10.0.0.158?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 9 Feb 2010 16:36:42 -0000 Message-ID: <4B718EBB.6080709@acm.poly.edu> Date: Tue, 09 Feb 2010 11:35:07 -0500 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.23 (X11/20091021) MIME-Version: 1.0 To: "Peter C. Lai" References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> <20100209161817.GI4648@cesium.hyperfine.info> In-Reply-To: <20100209161817.GI4648@cesium.hyperfine.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Charles Sprickman , FreeBSD Stable , Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:36:43 -0000 Peter C. Lai wrote: > On 2010-02-09 06:37:47AM -0500, Dan Langille wrote: > >> Charles Sprickman wrote: >> >>> On Mon, 8 Feb 2010, Dan Langille wrote: >>> Also, it seems like >>> people who use zfs (or gmirror + gstripe) generally end up buying pricey >>> hardware raid cards for compatibility reasons. There seem to be no decent >>> add-on SATA cards that play nice with FreeBSD other than that weird >>> supermicro card that has to be physically hacked about to fit. >>> > > Mostly only because certain cards have issues w/shoddy JBOD implementation. > Some cards (most notably ones like Adaptec 2610A which was rebranded by > Dell as the "CERC SATA 1.5/6ch" back in the day) won't let you run the > drives in passthrough mode and seem to all want to stick their grubby > little RAID paws into your JBOD setup (i.e. the only way to have minimal > participation from the "hardware" RAID is to set each disk as its own > RAID-0/volume in the controller BIOS) which then cascades into issues with > SMART, AHCI, "triple caching"/write reordering, etc on the FreeBSD side (the > controller's own craptastic cache, ZFS vdev cache, vmm/app cache, oh my!). > So *some* people go with something tried-and-true (basically bordering on > server-level cards that let you ditch any BIOS type of RAID config and > present the raw disk devices to the kernel) As someone else has mentioned, recent SiL stuff works well. I have multiple http://www.newegg.com/Product/Product.aspx?Item=N82E16816132008 cards servicing RAID-Z2 and GEOM_RAID3 arrays on 8.0-RELEASE and 8.0-STABLE machines using both the old ata(4) driver and ATA_CAM. Don't let the RAID label scare you--that stuff is off by default and the controller just presents the disks to the operating system. Hot swap works. I haven't had the time to try the siis(4) driver for them, which would result in better performance. -Boris From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 16:49:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCD33106566B for ; Tue, 9 Feb 2010 16:49:26 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f203.google.com (mail-iw0-f203.google.com [209.85.223.203]) by mx1.freebsd.org (Postfix) with ESMTP id A25318FC13 for ; Tue, 9 Feb 2010 16:49:26 +0000 (UTC) Received: by iwn41 with SMTP id 41so2802467iwn.9 for ; Tue, 09 Feb 2010 08:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=TJLLDlYeOGLOP2VwucMMvyum1eFNSnpqCuxsSt6kCuY=; b=ZTWpr/hXgFTUyzso7BxYywU/dMb9QT9UOpOiLr4D5pTN99f6+qSLGorRnhO6b8cdaU akld7nJqHouyNWQWGoevI2w8MzypSSYulXTbapQK7FoAL1j8/S+3nAQTBFvxC8Qb0o6r 1PqEI445SVpssBKb1DmwqnK9Wv6w76Pc9dMCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=kWil0ULvIbhsRg3YrzYcz1HSK4DKKoSgoOU5RlhmjzqH/gMLwtAwro+4ie/L2iDzc5 orhKOttIxx+TOcpjSHxHX+gZ87M1FAD2eS2iNDuIHpdgx/Mpqrl46Maf/0p/kibHGoOL gC20L8wZuf8PcIQJWkk9pTLxC7YrDK/+9Apek= MIME-Version: 1.0 Received: by 10.231.146.211 with SMTP id i19mr674847ibv.22.1265734165649; Tue, 09 Feb 2010 08:49:25 -0800 (PST) In-Reply-To: <201002091231.17551.doconnor@gsoft.com.au> References: <201002091059.28625.doconnor@gsoft.com.au> <201002091231.17551.doconnor@gsoft.com.au> Date: Tue, 9 Feb 2010 08:49:25 -0800 Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:49:27 -0000 On Mon, Feb 8, 2010 at 6:01 PM, Daniel O'Connor wrote: > On Tue, 9 Feb 2010, Freddie Cash wrote: > > I just did this to 8 of the 1.5 TB Caviar Green disks, without ZFS > > complaining in any way. > > > > I did test it on a spare drive before doing it to the 7 live drives. > > And I did replace them while the server was turned off, just to be > > safe (and to prevent a resilver from occuring). > > > > wdidle3 doesn't actually disable the idle timeout on these drives. > > Using /d just sets the timeout to 62 minutes. Effectively the same, > > but don't be surprised when it continues to say "idel 3 available and > > enabled". :) > > /d sets it (for me) to 6300 milliseconds (6.3 seconds). I took this as a > special value that disabled it entirely (no idea why they didn't use 0 > or 255..) > > I've seen reports of the same on various hardware forums. Not sure if it's due to different firmware, or different drive models. You should still be able to list the timeout value explicitly (instead of using /d). According to the help output, you can use either 25.5 seconds or 3000-something seconds as the max value (depends on the drive). -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 17:10:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E855F106566B for ; Tue, 9 Feb 2010 17:10:22 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.223.172]) by mx1.freebsd.org (Postfix) with ESMTP id 943838FC16 for ; Tue, 9 Feb 2010 17:10:22 +0000 (UTC) Received: by iwn2 with SMTP id 2so6205iwn.8 for ; Tue, 09 Feb 2010 09:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=My9J3RT1Mxel4pw5lyAPAxknqPDMTmsP4BG9vqTiGJQ=; b=amNPZYhvpJBbG5MJfbiT7zsIjR5D2gnBuUd6N2P4NxMZuwqYeBs7zF1jqgafCWhsMR inRAscRsOYF+OltwGpsaIfjBZ0mmaZdyl1Dxahp7cHYFub+7JmSKX9peT3m8k4t3HX39 NG4Qnyd/6lg3B4Vc2W8l6Wd0WpVCxqFVYG33A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=RiU7Z7T6CEGwHApcUA3xTT02hXzZgqxxdJk7blDLQDjgPynxgwgzfukyOmVsjub7Rk qab5g6EeMIQaNDdSfWKOj4803iS/VMPKfyjCgMO+sojU56SYSgNGxjzGYhs2A9Xi+0uj fx/XgkjRo9/vzFsTgklCKl2LafwLdGvd+Mkyg= MIME-Version: 1.0 Received: by 10.231.79.136 with SMTP id p8mr5029225ibk.4.1265735421829; Tue, 09 Feb 2010 09:10:21 -0800 (PST) In-Reply-To: <20100209142658.GA38072@icarus.home.lan> References: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> <20100209142658.GA38072@icarus.home.lan> Date: Tue, 9 Feb 2010 09:10:21 -0800 Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: zpool vdev vs. glabel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 17:10:23 -0000 On Tue, Feb 9, 2010 at 6:26 AM, Jeremy Chadwick wrote: > Also, I'm a little confused as to the use of glabel in this case. In > what condition do your disk indices (e.g. X of daX) change? Are you > yanking multiple disks out of a system at the same time and then shoving > them back into different drive bays? Are you switching between storage > subsystem drivers (ahci(4) vs. ataahci(4), for example) regularly? > > I've yet to be convinced glabel is worth bothering with, unless the > system adheres to one of the above situations (which are worthy of > strangulation anyway ;-) ). > > Use multiple disk controllers in a server, and watch as kernel updates and/or BIOS updates change the order that the controllers are probed, thus changing the dev node for every disk in the system. Use multiple disk controllers that use CAM, then move from an IDE-based CompactFlash adapter to a SATA-based CompactFlash adapter for the / filesystem, and watch the system renumber all your dev nodes. Use a RAID controller configured for JBOD or "Single Disk" arrays, and replace a drive while the server is running, which assigns the disk "largest da number +1", then renumbers everything when the server reboots. After you run into those kinds of things a few times, you'll start to use glabel(8) for everything. Plus, it just makes things easier to understand. Instead of da0 through da25 which is a mix of SATA, RAID, and USB drives, you have cfdisk0, cfdisk1, disk00 through disk24, and so on. Personally, the greatest thing to ever happen to FreeBSD is the introduction of GEOM, and the addition of the glabel class. :) While ZFS does it's own disk labelling behind the scenes, using glabel just makes things easier. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 18:04:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EAC6106566C for ; Tue, 9 Feb 2010 18:04:27 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.223.172]) by mx1.freebsd.org (Postfix) with ESMTP id E91368FC13 for ; Tue, 9 Feb 2010 18:04:26 +0000 (UTC) Received: by iwn2 with SMTP id 2so85491iwn.8 for ; Tue, 09 Feb 2010 10:04:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=ZdtomB0YPmSn99kxKGhQKJE1sVZvlrCd9G+FIMgXjyU=; b=vTch/pPEssDuBRMMalCZvtDSaNMkxcKq/RRBQKD1/JnLsbe5PJOh1fNXy+8gbJSKeY PgJ2b2MVoPLhiiAm5UoYysXCDk2PzAJC1jdUanTW+K3AGoRoLuEXvbsaeivVkQ6RHlTN S0NocbctMX4Mvlvp9ld4EAfomO9jfJSpGtzmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=pv4JQFWU0sH0aVzNm8IVbjJ7y0axU+ej903N1fWuhmMQJRqT2JvU1LdCxRrxqjJ4If v61E+NGSfHfZJ7MjgRJQJx8EjrlRaQIpRAQDz7GPPndtdZCUKngnbcKchnQQd60tNVhY S3KuqgcuwD6uPHRybRsUnnAPYZ7ZFNhBf7e5k= MIME-Version: 1.0 Received: by 10.231.153.205 with SMTP id l13mr2034305ibw.64.1265738666395; Tue, 09 Feb 2010 10:04:26 -0800 (PST) In-Reply-To: <4B71490B.6030602@langille.org> References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> Date: Tue, 9 Feb 2010 10:04:26 -0800 Message-ID: From: Freddie Cash To: FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 18:04:27 -0000 On Tue, Feb 9, 2010 at 3:37 AM, Dan Langille wrote: > Charles Sprickman wrote: > >> On Mon, 8 Feb 2010, Dan Langille wrote: >> >> > Also, it seems like > >> people who use zfs (or gmirror + gstripe) generally end up buying pricey >> hardware raid cards for compatibility reasons. There seem to be no decent >> add-on SATA cards that play nice with FreeBSD other than that weird >> supermicro card that has to be physically hacked about to fit. >> > > They use software RAID and hardware RAID at the same time? I'm not sure > what you mean by this. Compatibility with FreeBSD? > > Add-on (PCI-X/PCIe) RAID controllers tend to have solid drivers in FreeBSD. Add-on SATA controllers not so much. The RAID controllers also tend to support more SATA features like NCQ, hot-swap, monitoring, etc. They also enable you to use the same hardware across OSes (FreeBSD, Linux, etc). For example, we use 3Ware controllers in all our servers, as they have good, solid support under FreeBSD and Linux. On the Linux servers, we use hardware RAID. On the FreeBSD servers, we use them as SATA controllers (Single Disk arrays, not JBOD). Either way, the management is the same, the drivers are the same, the support is the same. It's hard to find good, non-RAID, SATA controllers with solid FreeBSD support, and good throughput, with any kind of management/monitoring features. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 18:20:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82554106566B for ; Tue, 9 Feb 2010 18:20:08 +0000 (UTC) (envelope-from hk@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id 1B89E8FC08 for ; Tue, 9 Feb 2010 18:20:07 +0000 (UTC) Received: from alogis.com (localhost [127.0.0.1]) by alogis.com (8.13.4/8.13.1) with ESMTP id o19IK5ZN066769; Tue, 9 Feb 2010 19:20:05 +0100 (CET) (envelope-from hk@alogis.com) Received: (from hk@localhost) by alogis.com (8.13.4/8.13.1/Submit) id o19IK5pk066768; Tue, 9 Feb 2010 19:20:05 +0100 (CET) (envelope-from hk) Date: Tue, 9 Feb 2010 19:20:05 +0100 From: Holger Kipp To: freebsd-stable@freebsd.org Message-ID: <20100209182005.GA58395@intserv.int1.b.intern> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Problem with USB wireless keyboard/mouse X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 18:20:08 -0000 My son bought a wireless USB deskset (keyboard and mouse) from TRUST. Of course it does not work with freebsd 7.1 (I am currently updating to 7-STABLE just in case). Anyway, here the problem with TRUST Wireless Deskset: Feb 8 22:00:32 TheSimpsons root: Unknown USB device: vendor 0x04fc product 0x05d8 bus uhub3 Feb 8 22:00:37 TheSimpsons kernel: uhub3: port 2, set config at addr 2 failed Feb 8 22:00:37 TheSimpsons kernel: uhub3: device problem (TIMEOUT), disabling port 2 any ideas? There is nothing else showing up. Interestingly, the keyboard is working within BIOS without problems. Same problem with and without ACPI and switching on legacy mode in BIOS does not help either. Keyboard is the german version, Item number 16595. If I can provide anything else, please let me know. Best Regards, Holger From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 18:52:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A738410656B4; Tue, 9 Feb 2010 18:52:31 +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 78A188FC50; Tue, 9 Feb 2010 18:52:31 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1198146B1A; Tue, 9 Feb 2010 13:52:31 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 1E75A8A024; Tue, 9 Feb 2010 13:52:30 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 9 Feb 2010 13:52:24 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B6B89E7.8030002@sdf.lonestar.org> <4B6DE364.8030509@sdf.lonestar.org> <201002080949.00877.jhb@freebsd.org> In-Reply-To: <201002080949.00877.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201002091352.24131.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 09 Feb 2010 13:52:30 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Tom McLaughlin , kib@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 18:52:31 -0000 On Monday 08 February 2010 9:49:00 am John Baldwin wrote: > On Saturday 06 February 2010 4:47:16 pm Tom McLaughlin wrote: > > John Baldwin wrote, On 02/05/2010 08:27 AM: > > > On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: > > >> Hi all, a recent MFC to 7-STABLE has started to cause issues for my VMs > > >> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk > > >> controller the VM just shuts off. The workaround is to change the disk > > >> controller to the BusLogic type. Still, it used to work up until last > > >> week. The change was made around January 26th and based on the commits > > >> that day I'm guessing it's either r203047 or r203073 > > >> > > >> I have the same issue with both amd64 and i386 VMs. This affects HEAD > > >> and 8-STABLE as well and first affected HEAD over the summer. (I just > > >> worked around it and went about my business at the time. :-/) I've > > >> attached a dmesg from a kernel before the problem and one from after it > > >> started. > > > > > > What if you set 'hw.clfush_disable=1' from the loader? > > > > > > > Yes, that corrected it on all my VMs. I've talked to people on ESXi 4 > > and they do not see the problem. I have yet to try 3.5u5 to see if this > > is a non-issue. 3.5 will be supported for awhile longer from VMware. > > I'm going to try upgrading the box during the week. > > I believe folks had to do this on HEAD/8.x as well. Perhaps we can > automatically disable clflush if we are executing under VMware or Xen: Tom, were you able to verify that this patch fixes the problem for you without requiring you to set the hw.clflush_disable tunable? > Index: amd64/amd64/initcpu.c > =================================================================== > --- amd64/amd64/initcpu.c (revision 203430) > +++ amd64/amd64/initcpu.c (working copy) > @@ -177,17 +177,16 @@ > if ((cpu_feature & CPUID_CLFSH) != 0) > cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; > /* > - * XXXKIB: (temporary) hack to work around traps generated when > - * CLFLUSHing APIC registers window. > + * XXXKIB: (temporary) hack to work around traps generated > + * when CLFLUSHing APIC registers window under virtualization > + * environments. > */ > TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && > - hw_clflush_disable == -1) > + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) > cpu_feature &= ~CPUID_CLFSH; > /* > * Allow to disable CLFLUSH feature manually by > - * hw.clflush_disable tunable. This may help Xen guest on some AMD > - * CPUs. > + * hw.clflush_disable tunable. > */ > if (hw_clflush_disable == 1) > cpu_feature &= ~CPUID_CLFSH; > Index: i386/i386/initcpu.c > =================================================================== > --- i386/i386/initcpu.c (revision 203430) > +++ i386/i386/initcpu.c (working copy) > @@ -724,17 +724,16 @@ > if ((cpu_feature & CPUID_CLFSH) != 0) > cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; > /* > - * XXXKIB: (temporary) hack to work around traps generated when > - * CLFLUSHing APIC registers window. > + * XXXKIB: (temporary) hack to work around traps generated > + * when CLFLUSHing APIC registers window under virtualization > + * environments. > */ > TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && > - hw_clflush_disable == -1) > + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) > cpu_feature &= ~CPUID_CLFSH; > /* > * Allow to disable CLFLUSH feature manually by > - * hw.clflush_disable tunable. This may help Xen guest on some AMD > - * CPUs. > + * hw.clflush_disable tunable. > */ > if (hw_clflush_disable == 1) > cpu_feature &= ~CPUID_CLFSH; > > -- > John Baldwin > _______________________________________________ > 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" > -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 19:10:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB9E1106566C for ; Tue, 9 Feb 2010 19:10:12 +0000 (UTC) (envelope-from andre@wensing.org) Received: from mail.wensing.org (wensing.xs4all.nl [80.101.217.189]) by mx1.freebsd.org (Postfix) with ESMTP id 5C8968FC0C for ; Tue, 9 Feb 2010 19:10:12 +0000 (UTC) Received: from ares.wensing.org (localhost [127.0.0.1]) by mail.wensing.org (Postfix) with ESMTP id B86CB17052 for ; Tue, 9 Feb 2010 19:52:08 +0100 (CET) X-Virus-Scanned: amavisd-new at wensing.org Received: from mail.wensing.org ([127.0.0.1]) by ares.wensing.org (ares.wensing.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MUcVy2+6v1eq for ; Tue, 9 Feb 2010 19:52:06 +0100 (CET) Received: from [192.168.1.14] (unknown [192.168.1.14]) by mail.wensing.org (Postfix) with ESMTPA id 22B5A17045 for ; Tue, 9 Feb 2010 19:52:06 +0100 (CET) Message-ID: <4B71AED5.4030002@wensing.org> Date: Tue, 09 Feb 2010 19:52:05 +0100 From: Andre Wensing User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: FreeBSD Stable References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 19:10:12 -0000 Freddie Cash wrote: > On Tue, Feb 9, 2010 at 3:37 AM, Dan Langille wrote: > >> Charles Sprickman wrote: >> >>> On Mon, 8 Feb 2010, Dan Langille wrote: >>> >>>> Also, it seems like >>> people who use zfs (or gmirror + gstripe) generally end up buying pricey >>> hardware raid cards for compatibility reasons. There seem to be no decent >>> add-on SATA cards that play nice with FreeBSD other than that weird >>> supermicro card that has to be physically hacked about to fit. >>> >> They use software RAID and hardware RAID at the same time? I'm not sure >> what you mean by this. Compatibility with FreeBSD? >> >> Add-on (PCI-X/PCIe) RAID controllers tend to have solid drivers in FreeBSD. > Add-on SATA controllers not so much. The RAID controllers also tend to > support more SATA features like NCQ, hot-swap, monitoring, etc. They also > enable you to use the same hardware across OSes (FreeBSD, Linux, etc). > > For example, we use 3Ware controllers in all our servers, as they have good, > solid support under FreeBSD and Linux. On the Linux servers, we use > hardware RAID. On the FreeBSD servers, we use them as SATA controllers > (Single Disk arrays, not JBOD). Either way, the management is the same, the > drivers are the same, the support is the same. > > It's hard to find good, non-RAID, SATA controllers with solid FreeBSD > support, and good throughput, with any kind of management/monitoring > features. > And I thought I found one in the Adaptec 1405 Integrated SAS/SATA controller, because it's marketed as an inexpensive SAS/SATA non-RAID addon-card. On top of that, they advertise it as having FreeBSD6 and FreeBSD7-support and drivers. So I ordered it for my storage-box (FreeNAS) with great expectations. Sadly, they don't have support nor drivers for FreeBSD ("drivers will be released Q4 2009") at all, so I'm thinking of leaving FreeNAS and trying some linux-flavor that does support this card... But Adaptec doesn't have a great track-record for FreeBSD-support, does it? André Wensing From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 19:27:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DDCA106566C for ; Tue, 9 Feb 2010 19:27:10 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 11E0D8FC0C for ; Tue, 9 Feb 2010 19:27:09 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id 02C722BB302; Tue, 9 Feb 2010 14:27:08 -0500 (EST) Date: Tue, 9 Feb 2010 14:27:07 -0500 From: "Peter C. Lai" To: Andre Wensing Message-ID: <20100209192707.GM4648@cesium.hyperfine.info> References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> <4B71AED5.4030002@wensing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B71AED5.4030002@wensing.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 19:27:10 -0000 On 2010-02-09 07:52:05PM +0100, Andre Wensing wrote: > > > Freddie Cash wrote: >> On Tue, Feb 9, 2010 at 3:37 AM, Dan Langille wrote: >> >>> Charles Sprickman wrote: >>> >>>> On Mon, 8 Feb 2010, Dan Langille wrote: >>>> >>>>> Also, it seems like >>>> people who use zfs (or gmirror + gstripe) generally end up buying pricey >>>> hardware raid cards for compatibility reasons. There seem to be no decent >>>> add-on SATA cards that play nice with FreeBSD other than that weird >>>> supermicro card that has to be physically hacked about to fit. >>>> >>> They use software RAID and hardware RAID at the same time? I'm not sure >>> what you mean by this. Compatibility with FreeBSD? >>> >>> Add-on (PCI-X/PCIe) RAID controllers tend to have solid drivers in FreeBSD. >> Add-on SATA controllers not so much. The RAID controllers also tend to >> support more SATA features like NCQ, hot-swap, monitoring, etc. They also >> enable you to use the same hardware across OSes (FreeBSD, Linux, etc). >> >> For example, we use 3Ware controllers in all our servers, as they have good, >> solid support under FreeBSD and Linux. On the Linux servers, we use >> hardware RAID. On the FreeBSD servers, we use them as SATA controllers >> (Single Disk arrays, not JBOD). Either way, the management is the same, the >> drivers are the same, the support is the same. >> >> It's hard to find good, non-RAID, SATA controllers with solid FreeBSD >> support, and good throughput, with any kind of management/monitoring >> features. >> > > And I thought I found one in the Adaptec 1405 Integrated SAS/SATA > controller, because it's marketed as an inexpensive SAS/SATA non-RAID > addon-card. On top of that, they advertise it as having FreeBSD6 and > FreeBSD7-support and drivers. So I ordered it for my storage-box (FreeNAS) > with great expectations. Sadly, they don't have support nor drivers for > FreeBSD ("drivers will be released Q4 2009") at all, so I'm thinking of > leaving FreeNAS and trying some linux-flavor that does support this card... > But Adaptec doesn't have a great track-record for FreeBSD-support, does it? > Everything is a repackage of some OEM these days (basically gone are the days of Adaptec==LSI==mpt(4) and all). Find the actual chipset make and model if you can, then you can look at what is supported, as the drivers deal with the actual chipset and could care less about the brand of some vertically-integrated fpga package. Probably will want to give a shout-out on -hardware i.e. http://markmail.org/message/b5imismi5s3iafc5#query:+page:1+mid:5htpj5fw7uijtzqp+state:results -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 19:46:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A33C106566B for ; Tue, 9 Feb 2010 19:46:37 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id A22108FC15 for ; Tue, 9 Feb 2010 19:46:36 +0000 (UTC) Received: by bwz3 with SMTP id 3so2091531bwz.33 for ; Tue, 09 Feb 2010 11:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=9+/SMORb2e6YqmWxy3kDLehCxs4LnYdoWh3ptrsSseo=; b=AftsyZfwiYBiekgW//K4hp7y9jwgigrUaImPrbnUmyw5yMv2hP9gzbXtao1dbtEOvQ Io+titlaoQwTJlX1gqpHXTds2AWaxEYgYdLEBfJCA0LqKqsSUcbWK8YdoXbIK7Ol3gJW A7yO6QLIZVpk5Srs5zTZJevnnOtYnhnlP3C8E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=XPM965TQwlOLyC60HxTnbDfa67lfjJ4BBhE+vINBgV/VUpz0dVw17N7IwRHJBrQnOK c2+Ys/f+KRQThLk4Jd5BiLx8yJrgAsvx1MuJdhEA5MQQ52HEksEZjafYsxjG//RfbSVT vDSA6sSumnqHYuL2qJwBPzdZxZLi2A+zx/A+I= MIME-Version: 1.0 Received: by 10.204.6.203 with SMTP id a11mr2903235bka.33.1265744795180; Tue, 09 Feb 2010 11:46:35 -0800 (PST) In-Reply-To: <20100208114734.GA99245@icarus.home.lan> References: <426bed111002080049u16354c87pd4fb8830e0542972@mail.gmail.com> <20100208114734.GA99245@icarus.home.lan> From: Chris Rees Date: Tue, 9 Feb 2010 19:46:15 +0000 Message-ID: To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Unresponsive keyboard after a few boots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 19:46:37 -0000 On 8 February 2010 11:47, Jeremy Chadwick wrote: > On Mon, Feb 08, 2010 at 02:19:06PM +0530, Rohit Grover wrote: >> I am using a very recent Freebsd 8.0 STABLE on a Macbook. I updated my >> sources and rebuilt a kernel about 3 days ago. I was able to use the >> machine fine once or twice after that. But now the keyboard has >> stopped working. The boot program is able to use the keyboard, but the >> kernel isn't, and I am unable to do anything useful with the machine >> from the login screen. >> >> I had rebuilt the kernel twice with slightly varying settings, so I >> don't have a copy of the previously working kernel in >> /boot/kernel.old. >> >> It may not be easy for me to download a ISO image. Can someone please help? > > Is the keyboard USB? > No Mac since late generation Powerbooks and iBooks has used ADB, so yes, the Macbook keyboard is USB. HTH, Chris From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 19:49:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4905E106566C for ; Tue, 9 Feb 2010 19:49:56 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 06FAC8FC13 for ; Tue, 9 Feb 2010 19:49:55 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.4/8.14.1) with ESMTP id o19JntKk009018 for ; Tue, 9 Feb 2010 11:49:55 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.14.4/8.13.4/Submit) id o19JntPo009017; Tue, 9 Feb 2010 11:49:55 -0800 (PST) Date: Tue, 9 Feb 2010 11:49:55 -0800 (PST) From: Matthew Dillon Message-Id: <201002091949.o19JntPo009017@apollo.backplane.com> To: FreeBSD Stable References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> <4B71AED5.4030002@wensing.org> Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 19:49:56 -0000 The Silicon Image 3124A chipsets (the PCI-e version of the 3124. The original 3124 was PCI-x). The 3124A's are starting to make their way into distribution channels. This is probably the best 'cheap' solution which offers fully concurrent multi-target NCQ operation through a port multiplier enclosure with more than the PCIe 1x bus the ultra-cheap 3132 offers. I think the 3124A uses an 8x bus (not quite sure, but it is more than 1x). AHCI on-motherboard with equivalent capabilities do not appear to be in wide distribution yet. Most AHCI chips can do NCQ to a single target (even a single target behind a PM), but not concurrently to multiple targets behind a port multiplier. Even though SATA bandwidth constraints might seem to make this a reasonable alternative it actually isn't because any seek heavy activity to multiple drives will be serialized and perform EXTREMELY poorly. Linear performance will be fine. Random performance will be horrible. It should be noted that while hotswap is supported with silicon image chipsets and port multiplier enclosures (which also use Sili chips in the enclosure), the hot-swap capability is not anywhere near as robust as you would find with a more costly commercial SAS setup. SI chips are very poorly made (this is the same company that went bust under another name a few years back due to shoddy chipsets), and have a lot of on-chip hardware bugs, but fortunately OSS driver writers (linux guys) have been able to work around most of them. So even though the chipset is a bit shoddy actual operation is quite good. However, this does mean you generally want to idle all activity on the enclosure to safely hot swap anything, not just the drive you are pulling out. I've done a lot of testing and hot-swapping an idle disk while other drives in the same enclosure are hot is not reliable (for a cheap port multiplier enclosure using a Sili chip inside, which nearly all do). Also, a disk failure within the enclosure can create major command sequencing issues for other targets in the enclosure because error processing has to be serialized. Fine for home use but don't expect miracles if you have a drive failure. The Sili chips and port multiplier enclosures are definitely the cheapest multi-disk solution. You lose on aggregate bandwidth and you lose on some robustness but you get the hot-swap basically for free. -- Multi-HD setups for home use are usually a lose. I've found over the years that it is better to just buy a big whopping drive and then another one or two for backups and not try to gang them together in a RAID. And yes, at one time in the past I was running three separate RAID-5 using 3ware controllers. I don't anymore and I'm a lot happier. If you have more than 2TB worth of critical data you don't have much of a choice, but I'd go with as few physical drives as possible regardless. The 2TB Maxtor green or black drives are nice. I strongly recommend getting the highest-capacity drives you can afford if you don't want your power bill to blow out your budget. The bigger problem is always having an independent backup of the data. Depending on a single-instanced filesystem, even one like ZFS, for a lifetime's worth of data is not a good idea. Fire, theft... there are a lot of ways the data can be lost. So when designing the main system you have to take care to also design the backup regimen including something off-site (or swapping the physical drive once a month, etc). i.e. multiple backup regimens. If single-drive throughput is an issue then using ZFS's caching solution with a small SSD is the way to go (and yes, DFly has a SSD caching solution now too but that's not pertainant to this thread). The Intel SSDs are really nice, but I am singularly unimpressed with the OCZ Colossus's which don't even negotiate NCQ. I don't know much re: other vendors. A little $100 Intel 40G SSD has around a 40TB write endurance and can last 10 years as a disk meta-data caching environment with a little care, particularly if you only cache meta-data. A very small incremental cost gives you 120-200MB/sec of seek-agnostic bandwidth which is perfect for network serving, backup, remote filesystems, etc. Unless the box has 10GigE or multiple 1xGigE network links there's no real need to try to push HD throughput beyond what the network can do so it really comes down to avoiding thrashing the HDs with random seeks. That is what the small SSD cache gives you. It can be like night and day. -Matt From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 20:27:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD8FC106566B for ; Tue, 9 Feb 2010 20:27:22 +0000 (UTC) (envelope-from efinley.lists@gmail.com) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.223.172]) by mx1.freebsd.org (Postfix) with ESMTP id A1B708FC1D for ; Tue, 9 Feb 2010 20:27:22 +0000 (UTC) Received: by iwn2 with SMTP id 2so291849iwn.8 for ; Tue, 09 Feb 2010 12:27:21 -0800 (PST) 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=9QsxC9d6H9SI4TflY235l9E8BSz/IwhDkqeC5Ok0qAo=; b=J97kA8nR2CFYxGfWjjgIUaXOv9icB/WfelRM1cTcUL3s8CsKDB7N9HSWjMsOsLCqRV k0ZQnI+Q+Plfsb+lmGC5oRS17uKygJiIIELHD+lECFBZYc+hMyXlvkyZJG1zCB3UH3lW 7NSBtEGCJd2xwZtZaUIJDpj4SUNKyilS5R8PM= 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=jnbScgc1atyojqswh8kETQlsaIfoZ4i/T5V+9d1CZCFPZGhqrFSJiS6UDS0OZQTs4L 1IMKGSgKYi4cBem1mHtY0NeRoyHa+SXNB33Sx5dhaaYU9nSaYD5vbzBuuCN8k/1Gr2CY ZfjOQksrzIO9q1ufUynWv5+2oUpQ4okSamrKc= MIME-Version: 1.0 Received: by 10.143.24.18 with SMTP id b18mr1412438wfj.16.1265747241394; Tue, 09 Feb 2010 12:27:21 -0800 (PST) In-Reply-To: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> References: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> Date: Tue, 9 Feb 2010 13:27:21 -0700 Message-ID: <54e63c321002091227w15657c54oeb2295efc4c43980@mail.gmail.com> From: Elliot Finley To: =?ISO-8859-1?Q?Gerrit_K=FChn?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: zpool vdev vs. glabel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 20:27:22 -0000 I ran into this same problem. you need to clean the beginning and end of your disk off before glabeling and adding it to your pool. clean with dd if=3D/dev/zero... 2010/2/9 Gerrit K=FChn > Hi, > > I have created a raidz2 with disk I labeled with glabel before. Right > after creation this pool looked fine, using devices label/tank[1-6]. > > I did some tests with replacing/swapping disks and so on. After doing a > > zpool offline tank label/tank6 > remove disk > camcontrol rescan all > insert disk > camcontrol rescan all > zpool online tank label/tank6 > > I got the disk back, but not under the requested label, but under the da > device name: > > pool: tank > state: ONLINE > scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:56:3= 7 > 2010 config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > label/tank1 ONLINE 0 0 0 8.50K resilvered > label/tank2 ONLINE 0 0 0 7.50K resilvered > label/tank3 ONLINE 0 0 0 8.50K resilvered > label/tank4 ONLINE 0 0 0 7.50K resilvered > label/tank5 ONLINE 0 0 0 9K resilvered > da6 ONLINE 0 0 0 13.5K resilvered > > errors: No known data errors > > > > Why does this happen? Is there any way to get zfs to use the label again? > After the device is in use, the label in /dev/label disappears. When > taking the device offline again, the label is there, but cannot be used: > > pigpen# zpool offline tank da6 > pigpen# zpool status > pool: system > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are > unaffected. action: Determine if the device needs to be replaced, and > clear the errors using 'zpool clear' or replace the device with 'zpool > replace'. see: http://www.sun.com/msg/ZFS-8000-9P > scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:49:1= 4 > 2010 config: > > NAME STATE READ WRITE CKSUM > system ONLINE 0 0 0 > mirror ONLINE 0 0 0 > label/system1 ONLINE 3 617 0 126K resilvered > label/system2 ONLINE 0 0 0 41K resilvered > > errors: No known data errors > > pool: tank > state: DEGRADED > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are > unaffected. action: Determine if the device needs to be replaced, and > clear the errors using 'zpool clear' or replace the device with 'zpool > replace'. see: http://www.sun.com/msg/ZFS-8000-9P > scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:56:3= 7 > 2010 config: > > NAME STATE READ WRITE CKSUM > tank DEGRADED 0 0 0 > raidz2 DEGRADED 0 0 0 > label/tank1 ONLINE 0 0 0 8.50K resilvered > label/tank2 ONLINE 0 0 0 7.50K resilvered > label/tank3 ONLINE 0 0 0 8.50K resilvered > label/tank4 ONLINE 0 0 0 7.50K resilvered > label/tank5 ONLINE 0 0 0 9K resilvered > da6 OFFLINE 0 38 0 13.5K resilvered > > errors: No known data errors > pigpen# ll /dev/label/ > total 0 > crw-r----- 1 root operator 0, 104 Feb 9 14:04 lisacrypt1 > crw-r----- 1 root operator 0, 112 Feb 9 14:04 lisacrypt2 > crw-r----- 1 root operator 0, 113 Feb 9 14:04 lisacrypt3 > crw-r----- 1 root operator 0, 134 Feb 9 14:48 system1 > crw-r----- 1 root operator 0, 115 Feb 9 14:04 system2 > crw-r----- 1 root operator 0, 116 Feb 9 14:04 tank1 > crw-r----- 1 root operator 0, 117 Feb 9 14:04 tank2 > crw-r----- 1 root operator 0, 118 Feb 9 14:04 tank3 > crw-r----- 1 root operator 0, 101 Feb 9 14:04 tank4 > crw-r----- 1 root operator 0, 102 Feb 9 14:04 tank5 > crw-r----- 1 root operator 0, 103 Feb 9 15:02 tank6 > > pigpen# zpool online tank label/tank6 > cannot online label/tank6: no such device in pool > > In a different thread I found the hint to use zpool replace to get to the > usage of labels, but this seems not possible, either: > > pigpen# zpool replace tank label/tank6 > invalid vdev specification > use '-f' to override the following errors: > /dev/label/tank6 is part of active pool 'tank' > > pigpen# zpool replace -f tank label/tank6 > invalid vdev specification > the following errors must be manually repaired: > /dev/label/tank6 is part of active pool 'tank' > > pigpen# zpool replace -f tank da6 label/tank6 > invalid vdev specification > the following errors must be manually repaired: > /dev/label/tank6 is part of active pool 'tank' > > > I'm running out of ideas here... > > > > cu > Gerrit > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 20:58:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FEB1106566B for ; Tue, 9 Feb 2010 20:58:35 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id DB4E38FC18 for ; Tue, 9 Feb 2010 20:58:34 +0000 (UTC) Received: by wwj40 with SMTP id 40so2420040wwj.13 for ; Tue, 09 Feb 2010 12:58:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=du3WllRrTLCcU7w9Ug6jhRtTD8jKHMrvxw48G3PUMyY=; b=LixuaZzxWo/elp39QBmTB7/8tmXR9fCmm9vmIMesPGd9WlPN8MA+e9dOthdJZdJRJM vUkGEjKet31chf9LnE5YKZy6N9UwbNYkQ2qpctwz8c+JtD98e4UG9hh6N6t2uRAL2ybS dVMSKT2x4ySQ4kFuYMj4xrQuyq42sUbqnxaVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=gC730DTYbnLUoh3PIefKTEW3HYqYsmYKvFsBWAbwIYnYGL6Gv2GOyJTNRJs9c3ckDa nCLbUHOv/Idlqw6QbPp5/l/8GttTi30HvABxOyxvLY5ZgQmI02b1rRYkld/CV3Wtd3ZJ vFIMsWFrnIp/2AsIO2iduMMCRNLzj52rf4Vhw= MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.216.90.131 with SMTP id e3mr380887wef.69.1265747534158; Tue, 09 Feb 2010 12:32:14 -0800 (PST) In-Reply-To: <20100202193616.GA16953@osiris.chen.org.nz> References: <20100202193616.GA16953@osiris.chen.org.nz> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Tue, 9 Feb 2010 21:31:54 +0100 X-Google-Sender-Auth: c67b6030910fb42b Message-ID: <3131aa531002091231o3003a60ay7e83b17fa995063b@mail.gmail.com> To: Jonathan Chen Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE outgoing scp stalling frequently. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 20:58:35 -0000 On Tue, Feb 2, 2010 at 8:36 PM, Jonathan Chen wrote: > Hi, > > I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be > stalling very frequently. I've got the same problem since I've upgraded from 7.2 to 8-stable (32bit). My NIC is a vge(4), with txsum and rxsum disabled. dmesg: vge0: port 0xfc00-0xfcff mem 0xfdfff000-0xfdfff0ff irq 18 at device 14.0 on pci0 I can't SCP big file too because my transferts stall and abord. Regards, Olivier From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 21:13:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94D6C1065670 for ; Tue, 9 Feb 2010 21:13:14 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out1.tiscali.nl (smtp-out1.tiscali.nl [195.241.79.176]) by mx1.freebsd.org (Postfix) with ESMTP id 281428FC15 for ; Tue, 9 Feb 2010 21:13:14 +0000 (UTC) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out1.tiscali.nl with esmtp (Exim) (envelope-from ) id 1NexOS-0000is-W7; Tue, 09 Feb 2010 22:13:13 +0100 Received: from 212-123-145-58.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 1D490C8AB; Tue, 9 Feb 2010 22:13:09 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Freddie Cash" , freebsd-stable@freebsd.org References: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> <20100209142658.GA38072@icarus.home.lan> Date: Tue, 09 Feb 2010 22:13:08 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/10.10 (FreeBSD) Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: zpool vdev vs. glabel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 21:13:14 -0000 On Tue, 09 Feb 2010 18:10:21 +0100, Freddie Cash wrot= e: > On Tue, Feb 9, 2010 at 6:26 AM, Jeremy Chadwick =20 > wrote: > >> Also, I'm a little confused as to the use of glabel in this case. In >> what condition do your disk indices (e.g. X of daX) change? Are you >> yanking multiple disks out of a system at the same time and then shovi= ng >> them back into different drive bays? Are you switching between storag= e >> subsystem drivers (ahci(4) vs. ataahci(4), for example) regularly? >> >> I've yet to be convinced glabel is worth bothering with, unless the >> system adheres to one of the above situations (which are worthy of >> strangulation anyway ;-) ). >> >> Use multiple disk controllers in a server, and watch as kernel updates > and/or BIOS updates change the order that the controllers are probed, =20 > thus > changing the dev node for every disk in the system. > > Use multiple disk controllers that use CAM, then move from an IDE-based > CompactFlash adapter to a SATA-based CompactFlash adapter for the / > filesystem, and watch the system renumber all your dev nodes. > > Use a RAID controller configured for JBOD or "Single Disk" arrays, and > replace a drive while the server is running, which assigns the disk =20 > "largest > da number +1", then renumbers everything when the server reboots. > > After you run into those kinds of things a few times, you'll start to u= se > glabel(8) for everything. Plus, it just makes things easier to =20 > understand. > Instead of da0 through da25 which is a mix of SATA, RAID, and USB =20 > drives, > you have cfdisk0, cfdisk1, disk00 through disk24, and so on. > > Personally, the greatest thing to ever happen to FreeBSD is the =20 > introduction > of GEOM, and the addition of the glabel class. :) Yeah. GEOM is very very very nice. It is a very elegant solution to a lot= =20 of problems. I always wonder why other OS'es didn't pick it up. Ronald. > While ZFS does it's own disk labelling behind the scenes, using glabel = =20 > just > makes things easier. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 21:16:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97619106566B for ; Tue, 9 Feb 2010 21:16:56 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 758578FC22 for ; Tue, 9 Feb 2010 21:16:56 +0000 (UTC) Received: from [134.117.23.34] (pldrouinlap2-pc.physics.carleton.ca [134.117.23.34]) by smtp.cyberfingers.net (Postfix) with ESMTP id E7F10AB6C10; Tue, 9 Feb 2010 16:13:57 -0500 (EST) Message-ID: <4B71D0C3.5040907@pldrouin.net> Date: Tue, 09 Feb 2010 16:16:51 -0500 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Daniel O'Connor References: <4B70C1F8.8090809@pldrouin.net> <20100209022039.GE4648@cesium.hyperfine.info> <4B70C851.9010604@pldrouin.net> <201002091608.24051.doconnor@gsoft.com.au> In-Reply-To: <201002091608.24051.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Peter C. Lai" , freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.0 i386 unable to boot... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 21:16:56 -0000 Daniel O'Connor wrote: > On Tue, 9 Feb 2010, Pierre-Luc Drouin wrote: > >> After doing some more research, it seems that I am having the same >> problem than described by this person: >> http://forums.freebsd.org/showthread.php?t=4502 >> > > So you get the same "file system full" message and then a panic about > init? > yes exactly. I currently have 4 20GB partitions/slices on that drive 1: Win XP fat32 2: Old FreeBSD installation 3: FAT32 4: Empty UFS2 > >> however I really don't understand why I would need to move partitions >> around to allow the installer to even start? This machine has 2GB of >> RAM which I guess should be plenty enough to start the installer >> without swapping... The hard drive is a 80GB WD IDE drive. The >> machine is not configured to use any RAID. >> > > It is pretty odd, I've installed FreeBSD on a laptop with 60Gb > partitions and FreeBSD was last yet it worked fine.. > > This is the first time I see that kind of warning as well although I have been using it for about 10 years... From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 21:17:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ACBD1065676 for ; Tue, 9 Feb 2010 21:17:57 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABD48FC12 for ; Tue, 9 Feb 2010 21:17:57 +0000 (UTC) Received: from [134.117.23.34] (pldrouinlap2-pc.physics.carleton.ca [134.117.23.34]) by smtp.cyberfingers.net (Postfix) with ESMTP id 4D04DAB6C64; Tue, 9 Feb 2010 16:14:59 -0500 (EST) Message-ID: <4B71D102.9040104@pldrouin.net> Date: Tue, 09 Feb 2010 16:17:54 -0500 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Chuck Swiger References: <4B70C1F8.8090809@pldrouin.net> <1A21C3B1-B637-4DF9-92F1-AA659CA0D90A@mac.com> In-Reply-To: <1A21C3B1-B637-4DF9-92F1-AA659CA0D90A@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.0 i386 unable to boot... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 21:17:57 -0000 Chuck Swiger wrote: > Hi-- > > On Feb 8, 2010, at 6:01 PM, Pierre-Luc Drouin wrote: > >> Going nowhere without my init cpuid = 1 >> >> Does anyone know what can be causing this and how to solve it? >> > > I don't suppose you built a custom kernel without the COMPAT_FREEBSD7 option? You need it until you get a new R8 userland and all ports recompiled... > > No I am using an official image of FreeBSD 8: ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/8.0/8.0-RELEASE-i386-disc1.iso From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 21:51:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29E3910656BE for ; Tue, 9 Feb 2010 21:51:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id CC3678FC1A for ; Tue, 9 Feb 2010 21:51:22 +0000 (UTC) Received: by vws11 with SMTP id 11so3417660vws.13 for ; Tue, 09 Feb 2010 13:51:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=20WEKgn0ghdzmXwP5/02qtlDZvJNX4XYr+OZB2wupAI=; b=j8PSnb5tZ5EscSpkz04wXigSdZaLbSmmR4mlqGofN5qXkrvGoptPxG+D8bEUEOepWH MD6H/E0CBBmdHd39yK2wt7i8tzb/E/RLRb/HRVg4XOipSS6XaiO3UWs30r/5FY5z/wTv qDDkVcnqbowXATnmlNeIA6IVHIZleyg9zT3e8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=dpjPmLa4i0z1AJ60fstkNrmamrzkMI2J/g039FlAN8aWlUlS8VpcEdKbpJY9RIrX6U pth2S9NxGqrgK/8MamqBhxNl+JFRaEY0rQ4toZ2mIiaR3qWQAEvjdDnnBvQ0m8lkHhEA AqsdXRdDFBXJlZGpX5o+YlPcwK8HRPHCRNJjo= Received: by 10.220.127.66 with SMTP id f2mr963908vcs.142.1265752281821; Tue, 09 Feb 2010 13:51:21 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 24sm4406117vws.13.2010.02.09.13.51.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Feb 2010 13:51:20 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 9 Feb 2010 13:51:10 -0800 From: Pyun YongHyeon Date: Tue, 9 Feb 2010 13:51:10 -0800 To: Olivier Cochard-Labb? Message-ID: <20100209215110.GJ1358@michelle.cdnetworks.com> References: <20100202193616.GA16953@osiris.chen.org.nz> <3131aa531002091231o3003a60ay7e83b17fa995063b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3131aa531002091231o3003a60ay7e83b17fa995063b@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE outgoing scp stalling frequently. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 21:51:23 -0000 On Tue, Feb 09, 2010 at 09:31:54PM +0100, Olivier Cochard-Labb? wrote: > On Tue, Feb 2, 2010 at 8:36 PM, Jonathan Chen wrote: > > Hi, > > > > I've noticed that on a recent 8-STABLE/amd64, scp(1) appears to be > > stalling very frequently. > > I've got the same problem since I've upgraded from 7.2 to 8-stable (32bit). > > My NIC is a vge(4), with txsum and rxsum disabled. > dmesg: > vge0: port 0xfc00-0xfcff mem > 0xfdfff000-0xfdfff0ff irq 18 at device 14.0 on pci0 > > I can't SCP big file too because my transferts stall and abord. > I guess I fixed all known vge(4) issues, how recent stable/8 you use? From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 22:07:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C161D1065670 for ; Tue, 9 Feb 2010 22:07:37 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4771C8FC0A for ; Tue, 9 Feb 2010 22:07:37 +0000 (UTC) Received: from mail-in-19-z2.arcor-online.net (mail-in-19-z2.arcor-online.net [151.189.8.36]) by mx.arcor.de (Postfix) with ESMTP id 62FF63326F6 for ; Tue, 9 Feb 2010 22:33:38 +0100 (CET) Received: from mail-in-10.arcor-online.net (mail-in-10.arcor-online.net [151.189.21.50]) by mail-in-19-z2.arcor-online.net (Postfix) with ESMTP id 5C62B6BD67 for ; Tue, 9 Feb 2010 22:33:38 +0100 (CET) Received: from lorvorc.mips.inka.de (dslb-088-067-112-185.pools.arcor-ip.net [88.67.112.185]) by mail-in-10.arcor-online.net (Postfix) with ESMTPS id 0B6B228ED92 for ; Tue, 9 Feb 2010 22:33:37 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-10.arcor-online.net 0B6B228ED92 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.3/8.14.3) with ESMTP id o19LXb5u034334 for ; Tue, 9 Feb 2010 22:33:37 +0100 (CET) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.3/8.14.3/Submit) id o19LXboo034333 for freebsd-stable@freebsd.org; Tue, 9 Feb 2010 22:33:37 +0100 (CET) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Tue, 9 Feb 2010 21:33:37 +0000 (UTC) Message-ID: References: <4B6F9A8D.4050907@langille.org> <201002081556.54782.doconnor@gsoft.com.au> <20100209053002.GA9449@over-yonder.net> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 22:07:37 -0000 Matthew D. Fuller wrote: > > I have something similar (5x1Tb) - I have a Gigabyte GA-MA785GM-US2H > > with an Athlon X2 and 4Gb of RAM (only half filled - 2x2Gb) > > > > Note that it doesn't support ECC, I don't know if that is a problem. > > How's that? Is the BIOS just stupid, or is the board physically > missing traces? Doesn't matter really, does it? I have a GA-MA78G-DS3H. According to the specs, it supports ECC memory. And that is all the mention of ECC you will find anywhere. There is nothing in the BIOS. My best guess is that they quite literally mean that you can plug ECC memory into the board and it will work, but that there are no provisions to actually use ECC. That said, I also have an Asus M2N-SLI Deluxe. If I enable ECC in the BIOS, the board locks up sooner or later, even when just sitting in the BIOS. memtest86 dies a screaming death immediately. When I disable ECC, the board is solid, both in actual use and with memtest. I thought if I built a PC from components, I'd be already a step above the lowest dregs of the consumer market, but apparently not. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 22:17:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44C20106566C; Tue, 9 Feb 2010 22:17:35 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 139858FC08; Tue, 9 Feb 2010 22:17:35 +0000 (UTC) Received: from straycat.dhs.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o19MHXXL044147; Tue, 9 Feb 2010 22:17:34 GMT (envelope-from tmclaugh@sdf.lonestar.org) Received: from tomcat.straycat.dhs.org (tomcat.straycat.dhs.org [192.168.2.213]) by straycat.dhs.org (8.14.1/8.14.1) with ESMTP id o19MHW2P026549; Tue, 9 Feb 2010 17:17:33 -0500 (EST) Message-ID: <4B71DEFC.2000200@sdf.lonestar.org> Date: Tue, 09 Feb 2010 17:17:32 -0500 From: Tom McLaughlin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.1 MIME-Version: 1.0 To: John Baldwin References: <4B6B89E7.8030002@sdf.lonestar.org> <4B6DE364.8030509@sdf.lonestar.org> <201002080949.00877.jhb@freebsd.org> <201002091352.24131.jhb@freebsd.org> In-Reply-To: <201002091352.24131.jhb@freebsd.org> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: kib@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 22:17:35 -0000 John Baldwin wrote, On 02/09/2010 01:52 PM: > On Monday 08 February 2010 9:49:00 am John Baldwin wrote: >> On Saturday 06 February 2010 4:47:16 pm Tom McLaughlin wrote: >>> John Baldwin wrote, On 02/05/2010 08:27 AM: >>>> On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: >>>>> Hi all, a recent MFC to 7-STABLE has started to cause issues for my VMs >>>>> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk >>>>> controller the VM just shuts off. The workaround is to change the disk >>>>> controller to the BusLogic type. Still, it used to work up until last >>>>> week. The change was made around January 26th and based on the commits >>>>> that day I'm guessing it's either r203047 or r203073 >>>>> >>>>> I have the same issue with both amd64 and i386 VMs. This affects HEAD >>>>> and 8-STABLE as well and first affected HEAD over the summer. (I just >>>>> worked around it and went about my business at the time. :-/) I've >>>>> attached a dmesg from a kernel before the problem and one from after it >>>>> started. >>>> >>>> What if you set 'hw.clfush_disable=1' from the loader? >>>> >>> >>> Yes, that corrected it on all my VMs. I've talked to people on ESXi 4 >>> and they do not see the problem. I have yet to try 3.5u5 to see if this >>> is a non-issue. 3.5 will be supported for awhile longer from VMware. >>> I'm going to try upgrading the box during the week. >> >> I believe folks had to do this on HEAD/8.x as well. Perhaps we can >> automatically disable clflush if we are executing under VMware or Xen: > > Tom, were you able to verify that this patch fixes the problem for you > without requiring you to set the hw.clflush_disable tunable? > John, I'm getting the following build error on all branches: /usr/src/sys/amd64/amd64/initcpu.c: In function 'initializecpucache': /usr/src/sys/amd64/amd64/initcpu.c:184: error: 'vm_guest' undeclared (first use in this function) /usr/src/sys/amd64/amd64/initcpu.c:184: error: (Each undeclared identifier is reported only once /usr/src/sys/amd64/amd64/initcpu.c:184: error: for each function it appears in.) *** Error code 1 tom >> Index: amd64/amd64/initcpu.c >> =================================================================== >> --- amd64/amd64/initcpu.c (revision 203430) >> +++ amd64/amd64/initcpu.c (working copy) >> @@ -177,17 +177,16 @@ >> if ((cpu_feature & CPUID_CLFSH) != 0) >> cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; >> /* >> - * XXXKIB: (temporary) hack to work around traps generated when >> - * CLFLUSHing APIC registers window. >> + * XXXKIB: (temporary) hack to work around traps generated >> + * when CLFLUSHing APIC registers window under virtualization >> + * environments. >> */ >> TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); >> - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && >> - hw_clflush_disable == -1) >> + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) >> cpu_feature &= ~CPUID_CLFSH; >> /* >> * Allow to disable CLFLUSH feature manually by >> - * hw.clflush_disable tunable. This may help Xen guest on some AMD >> - * CPUs. >> + * hw.clflush_disable tunable. >> */ >> if (hw_clflush_disable == 1) >> cpu_feature &= ~CPUID_CLFSH; >> Index: i386/i386/initcpu.c >> =================================================================== >> --- i386/i386/initcpu.c (revision 203430) >> +++ i386/i386/initcpu.c (working copy) >> @@ -724,17 +724,16 @@ >> if ((cpu_feature & CPUID_CLFSH) != 0) >> cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; >> /* >> - * XXXKIB: (temporary) hack to work around traps generated when >> - * CLFLUSHing APIC registers window. >> + * XXXKIB: (temporary) hack to work around traps generated >> + * when CLFLUSHing APIC registers window under virtualization >> + * environments. >> */ >> TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); >> - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && >> - hw_clflush_disable == -1) >> + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) >> cpu_feature &= ~CPUID_CLFSH; >> /* >> * Allow to disable CLFLUSH feature manually by >> - * hw.clflush_disable tunable. This may help Xen guest on some AMD >> - * CPUs. >> + * hw.clflush_disable tunable. >> */ >> if (hw_clflush_disable == 1) >> cpu_feature &= ~CPUID_CLFSH; >> >> -- >> John Baldwin >> _______________________________________________ >> 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" >> > -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 22:21:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DF9D1065670 for ; Tue, 9 Feb 2010 22:21:09 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id D218A8FC16 for ; Tue, 9 Feb 2010 22:21:08 +0000 (UTC) Received: (qmail 14366 invoked by uid 0); 9 Feb 2010 22:21:07 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Feb 2010 22:21:07 -0000 Date: Tue, 9 Feb 2010 17:21:07 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@freemac To: Dan Langille In-Reply-To: <4B71490B.6030602@langille.org> Message-ID: References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 22:21:09 -0000 On Tue, 9 Feb 2010, Dan Langille wrote: > Charles Sprickman wrote: >> On Mon, 8 Feb 2010, Dan Langille wrote: >> >> Also, it seems like >> people who use zfs (or gmirror + gstripe) generally end up buying pricey >> hardware raid cards for compatibility reasons. There seem to be no decent >> add-on SATA cards that play nice with FreeBSD other than that weird >> supermicro card that has to be physically hacked about to fit. > > They use software RAID and hardware RAID at the same time? I'm not sure what > you mean by this. Compatibility with FreeBSD? >From what I've seen on this list, people buy a nice Areca or 3Ware card and put it in JBOD mode and run ZFS on top of the drives. The card is just being used to get lots of sata ports with a stable driver and known good hardware. I've asked here a few times in the last few years for recommendations on a cheap SATA card and it seems like such a thing does not exist. This might be a bit dated at this point, but you're playing it safe if you go with a 3ware/Areca/LSI card. I don't recall all the details, but there were issues with siil, highpoint, etc. IIRC it was not really FBSD's issue, but bugginess in those cards. The intel ICH9 chipset works well, but there are no add-on PCIe cards that have an intel chip on them... I'm sure someone will correct me if my info is now outdated or flat-out wrong. :) Charles From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 22:23:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA2A8106566C; Tue, 9 Feb 2010 22:23: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 9AC818FC16; Tue, 9 Feb 2010 22:23:55 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4BF3846B39; Tue, 9 Feb 2010 17:23:55 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 42BB38A024; Tue, 9 Feb 2010 17:23:54 -0500 (EST) From: John Baldwin To: Tom McLaughlin Date: Tue, 9 Feb 2010 17:23:44 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B6B89E7.8030002@sdf.lonestar.org> <201002091352.24131.jhb@freebsd.org> <4B71DEFC.2000200@sdf.lonestar.org> In-Reply-To: <4B71DEFC.2000200@sdf.lonestar.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201002091723.44625.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 09 Feb 2010 17:23:54 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: kib@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 22:23:55 -0000 On Tuesday 09 February 2010 5:17:32 pm Tom McLaughlin wrote: > John Baldwin wrote, On 02/09/2010 01:52 PM: > > On Monday 08 February 2010 9:49:00 am John Baldwin wrote: > >> On Saturday 06 February 2010 4:47:16 pm Tom McLaughlin wrote: > >>> John Baldwin wrote, On 02/05/2010 08:27 AM: > >>>> On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: > >>>>> Hi all, a recent MFC to 7-STABLE has started to cause issues for my VMs > >>>>> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk > >>>>> controller the VM just shuts off. The workaround is to change the disk > >>>>> controller to the BusLogic type. Still, it used to work up until last > >>>>> week. The change was made around January 26th and based on the commits > >>>>> that day I'm guessing it's either r203047 or r203073 > >>>>> > >>>>> I have the same issue with both amd64 and i386 VMs. This affects HEAD > >>>>> and 8-STABLE as well and first affected HEAD over the summer. (I just > >>>>> worked around it and went about my business at the time. :-/) I've > >>>>> attached a dmesg from a kernel before the problem and one from after it > >>>>> started. > >>>> > >>>> What if you set 'hw.clfush_disable=1' from the loader? > >>>> > >>> > >>> Yes, that corrected it on all my VMs. I've talked to people on ESXi 4 > >>> and they do not see the problem. I have yet to try 3.5u5 to see if this > >>> is a non-issue. 3.5 will be supported for awhile longer from VMware. > >>> I'm going to try upgrading the box during the week. > >> > >> I believe folks had to do this on HEAD/8.x as well. Perhaps we can > >> automatically disable clflush if we are executing under VMware or Xen: > > > > Tom, were you able to verify that this patch fixes the problem for you > > without requiring you to set the hw.clflush_disable tunable? > > > > John, I'm getting the following build error on all branches: > > /usr/src/sys/amd64/amd64/initcpu.c: In function 'initializecpucache': > /usr/src/sys/amd64/amd64/initcpu.c:184: error: 'vm_guest' undeclared > (first use in this function) > /usr/src/sys/amd64/amd64/initcpu.c:184: error: (Each undeclared > identifier is reported only once > /usr/src/sys/amd64/amd64/initcpu.c:184: error: for each function it > appears in.) Oh foo. Can you add 'extern int vm_guest;' to that file near the top? > *** Error code 1 > > > tom > > >> Index: amd64/amd64/initcpu.c > >> =================================================================== > >> --- amd64/amd64/initcpu.c (revision 203430) > >> +++ amd64/amd64/initcpu.c (working copy) > >> @@ -177,17 +177,16 @@ > >> if ((cpu_feature & CPUID_CLFSH) != 0) > >> cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; > >> /* > >> - * XXXKIB: (temporary) hack to work around traps generated when > >> - * CLFLUSHing APIC registers window. > >> + * XXXKIB: (temporary) hack to work around traps generated > >> + * when CLFLUSHing APIC registers window under virtualization > >> + * environments. > >> */ > >> TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > >> - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && > >> - hw_clflush_disable == -1) > >> + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) > >> cpu_feature &= ~CPUID_CLFSH; > >> /* > >> * Allow to disable CLFLUSH feature manually by > >> - * hw.clflush_disable tunable. This may help Xen guest on some AMD > >> - * CPUs. > >> + * hw.clflush_disable tunable. > >> */ > >> if (hw_clflush_disable == 1) > >> cpu_feature &= ~CPUID_CLFSH; > >> Index: i386/i386/initcpu.c > >> =================================================================== > >> --- i386/i386/initcpu.c (revision 203430) > >> +++ i386/i386/initcpu.c (working copy) > >> @@ -724,17 +724,16 @@ > >> if ((cpu_feature & CPUID_CLFSH) != 0) > >> cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; > >> /* > >> - * XXXKIB: (temporary) hack to work around traps generated when > >> - * CLFLUSHing APIC registers window. > >> + * XXXKIB: (temporary) hack to work around traps generated > >> + * when CLFLUSHing APIC registers window under virtualization > >> + * environments. > >> */ > >> TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > >> - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && > >> - hw_clflush_disable == -1) > >> + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) > >> cpu_feature &= ~CPUID_CLFSH; > >> /* > >> * Allow to disable CLFLUSH feature manually by > >> - * hw.clflush_disable tunable. This may help Xen guest on some AMD > >> - * CPUs. > >> + * hw.clflush_disable tunable. > >> */ > >> if (hw_clflush_disable == 1) > >> cpu_feature &= ~CPUID_CLFSH; > >> > >> -- > >> John Baldwin > >> _______________________________________________ > >> 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" > >> > > > > > -- > | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | > | FreeBSD http://www.FreeBSD.org | > > -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 22:32:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCDA1106568D for ; Tue, 9 Feb 2010 22:32:03 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id A4BBF8FC12 for ; Tue, 9 Feb 2010 22:32:03 +0000 (UTC) Received: (qmail 27931 invoked by uid 0); 9 Feb 2010 22:32:02 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Feb 2010 22:32:02 -0000 Date: Tue, 9 Feb 2010 17:32:02 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@freemac To: Jeremy Chadwick In-Reply-To: <20100209134456.GA37029@icarus.home.lan> Message-ID: References: <4B6F9A8D.4050907@langille.org> <4B70FEEC.6070007@modulus.org> <20100209063310.GA23387@icarus.home.lan> <4B715AC6.5090500@denninger.net> <20100209134456.GA37029@icarus.home.lan> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 22:32:03 -0000 On Tue, 9 Feb 2010, Jeremy Chadwick wrote: > On Tue, Feb 09, 2010 at 06:53:26AM -0600, Karl Denninger wrote: >> Jeremy Chadwick wrote: >>> On Tue, Feb 09, 2010 at 05:21:32PM +1100, Andrew Snow wrote: >>> >>>> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H >>>> >>>> Supermicro just released a new Mini-ITX fanless Atom server board >>>> with 6xSATA ports (based on Intel ICH9) and a PCIe 16x slot. It >>>> takes up to 4GB of RAM, and there's even a version with KVM-over-LAN >>>> for headless operation and remote management. >>>> >>> >>> Neat hardware. But with regards to the KVM-over-LAN stuff: it's IPMI, >>> and Supermicro has a very, *very* long history of having shoddy IPMI >>> support. I've been told the latter by too many different individuals in >>> the industry (some co-workers, some work at Yahoo, some at Rackable, >>> etc.) for me to rely on it. If you *have* to go this route, make sure >>> you get the IPMI module which has its own dedicated LAN port on the >>> module and ***does not*** piggyback on top of an existing LAN port on >>> the mainboard. >>> >> What's wrong with the Supermicro IPMI implementations? I have several - >> all have a SEPARATE LAN port on the main board for the IPMI KVM >> (separate and distinct from the board's primary LAN ports), and I've not >> had any trouble with any of them. > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2008-01/msg01206.html > http://forums.freebsd.org/showthread.php?t=7750 > http://www.beowulf.org/archive/2007-November/019925.html > http://bivald.com/lessons-learned/2009/06/supermicro_ipmi_problems_web_i.html > http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044248.html > http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044237.html > > (Last thread piece does mention that the user was able to get keyboard > working by disabling umass(4) of all things) I have a box down at Softlayer (one of the few major server rental outfits that officially supports FreeBSD), and one of the reasons I went with them is that they advertised "IP-KVM support". Turns out they run Supermicro boxes with the IPMI card. It mostly works, but it is very quirky and you have to use a very wonky Java client app to get the remote console. You have to build a kernel that omits certain USB devices to make the keyboard work over the KVM connection (and their stock FBSD install has it disabled). I can usually get in, but sometimes I have to open a ticket with them and a tech does some kind of reset on the card. I don't know if they a hitting a button on the card/chassis or if they have some way to do this remotely. After they do that, I'll see something like this in dmesg: umass0: on uhub4 ums0: on uhub4 ums0: 3 buttons and Z dir. ukbd0: on uhub4 kbd2 at ukbd0 The umass device is to support the "virtual media" feature that simply does not work. It's supposed to allow you to point the ipmi card at an iso or disk image on an SMB server and boot your server off of it. I had no luck with this. All the IPMI power on/off, reset, and hw monitoring functions do work well though. > It gets worse when you use one of the IPMI modules that piggybacks on an > existing Ethernet port -- the NIC driver for the OS, from the ground up, > has to be fully aware of ASF and any quirks/oddities involved. For > example, on bge(4) and bce(4), you'll find this (bge mentioned below): > > hw.bge.allow_asf > Allow the ASF feature for cooperating with IPMI. Can cause sys- > tem lockup problems on a small number of systems. Disabled by > default. > > So unless the administrator intentionally sets the loader tunable prior > to booting the OS installation, they'll find all kinds of MAC problems > as a result of the IPMI piggybacking. "Why isn't this enabled by > default?" I believe because there were reports of failures/problems on > people's systems who *did not* have IPMI cards. Lose-lose situation. I don't think they have this setup, or if they do, they are using it on the internal LAN, so I don't notice any weirdness. > If you really want me to dig up people at Yahoo who have dealt with IPMI > on thousands of Supermicro servers and the insanity involved (due to > bugs, quirks, or implementation differences between the IPMI firmwares > and which revision/model of module used), I can do so. Most of the > complaints I've heard of stem from serial-over-IPMI. I don't think > it'd be a very positive/"supportive" thread, however. :-) > > One similar product that does seem to work well is iLO, available on > HP/Compaq hardware. I've heard great things about that. It seems like a much better design - it's essentially a small server that is independent from the main host. Has it's own LAN and serial ports as well. Charles > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 22:41:50 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1978D1065670 for ; Tue, 9 Feb 2010 22:41:50 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id E0A2E8FC0A for ; Tue, 9 Feb 2010 22:41:49 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o19Mfnaw009497 for ; Tue, 9 Feb 2010 14:41:49 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o19MfnxH009496 for stable@freebsd.org; Tue, 9 Feb 2010 14:41:49 -0800 (PST) (envelope-from david) Date: Tue, 9 Feb 2010 14:41:49 -0800 From: David Wolfskill To: stable@freebsd.org Message-ID: <20100209224149.GR391@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , stable@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KD3NH8oGZ7XN2Llp" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: 7.3-P r203700: what can I do about "psm0: the aux device is gone!" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 22:41:50 -0000 --KD3NH8oGZ7XN2Llp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I normally run X11 (via xdm) on my laptop. Today, running FreeBSD 7.3-PRERELEASE as of r203700, the mouse stopped moving. Logging in from a pty & checking the last bit of /var/log/messages showed: Feb 9 14:30:27 localhost kernel: kbdc: TEST_AUX_PORT status:0000 Feb 9 14:30:27 localhost kernel: kbdc: RESET_AUX return code:00fa Feb 9 14:30:27 localhost kernel: kbdc: RESET_AUX status:ffffffff Feb 9 14:30:27 localhost kernel: kbdc: DIAGNOSE status:0055 Feb 9 14:30:27 localhost kernel: kbdc: TEST_KBD_PORT status:0000 Feb 9 14:30:27 localhost kernel: psm0: failed to reset the aux device. Feb 9 14:30:27 localhost kernel: psm0: the aux device has gone! (reinitial= ize). uname output: FreeBSD localhost 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #56 r203700: Tue Fe= b 9 05:31:36 PST 2010 root@g1-136.catwhisker.org:/common/S2/obj/usr/sr= c/sys/CANARY i386 So far, the least disruptive form of evasive action I've found is a reboot, which is quite a bit more disruptive than I'd prefer. Help? Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --KD3NH8oGZ7XN2Llp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAktx5KwACgkQmprOCmdXAD2IXACdH6WtYPmFMQr2Fd1lBTjmyt6G wc8An1caBUzI0ow2zVLLh7XiEBxficiO =6b63 -----END PGP SIGNATURE----- --KD3NH8oGZ7XN2Llp-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 22:56:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 705B8106566B for ; Tue, 9 Feb 2010 22:56:35 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4730E8FC08 for ; Tue, 9 Feb 2010 22:56:34 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id B4CA32BB343; Tue, 9 Feb 2010 17:56:33 -0500 (EST) Date: Tue, 9 Feb 2010 17:56:32 -0500 From: "Peter C. Lai" To: Charles Sprickman Message-ID: <20100209225631.GP4648@cesium.hyperfine.info> References: <4B6F9A8D.4050907@langille.org> <4B70FEEC.6070007@modulus.org> <20100209063310.GA23387@icarus.home.lan> <4B715AC6.5090500@denninger.net> <20100209134456.GA37029@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 22:56:35 -0000 On 2010-02-09 05:32:02PM -0500, Charles Sprickman wrote: > On Tue, 9 Feb 2010, Jeremy Chadwick wrote: >> One similar product that does seem to work well is iLO, available on >> HP/Compaq hardware. > > I've heard great things about that. It seems like a much better design - > it's essentially a small server that is independent from the main host. Has > it's own LAN and serial ports as well. > > Charles Dell PowerEdge Remote Access (DRAC) cards also provided this as well, and for a while there, you could actually VNC into them. But HP offers iLO for no extra charge or discount upon removal (DRACs are worth about $250) and has become such a prominent "must-have" datacenter feature that the "iLO" term is beginning to become genericized for web-accessible and virtual disc-capable onboard out-of-band IP-console management. -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 23:05:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F2151065676; Tue, 9 Feb 2010 23:05:26 +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 DC7698FC17; Tue, 9 Feb 2010 23:05:25 +0000 (UTC) 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 <1Nez92-0007eE-Vl>; Wed, 10 Feb 2010 00:05:25 +0100 Received: from e178020182.adsl.alicedsl.de ([85.178.20.182] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Nez92-0005Vu-QP>; Wed, 10 Feb 2010 00:05:24 +0100 Message-ID: <4B71EA34.3010703@mail.zedat.fu-berlin.de> Date: Wed, 10 Feb 2010 00:05:24 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100207 Thunderbird/3.0.1 MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <4B701269.9070703@zedat.fu-berlin.de> <20100208172033.112629f7@ernst.jennejohn.org> <4B706038.3030603@zedat.fu-berlin.de> <4B712DCE.7030500@zedat.fu-berlin.de> <20100209135402.02976be2@ernst.jennejohn.org> In-Reply-To: <20100209135402.02976be2@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.20.182 Cc: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: Re: www/firefox: Firefox 3.6 crashes, Firefox 3.5.7 not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 23:05:26 -0000 On 02/09/10 13:54, Gary Jennejohn wrote: > On Tue, 09 Feb 2010 09:41:34 +0000 > "O. Hartmann" wrote: > > [snip maybe too much] >> On 02/08/10 21:42, Eitan Adler wrote: >>> you need to load the sem module (kldload sem). >>> >> SysV smaphore (or sem?) are built into my kernel by default. The >> error/system message when crashing is >> >> socket(): Protocol not supported >> Illegal instruction (core dumped) >> >> and a core is dumped. >> > > So, have you looked at the core dump with gdb to see where it appears > to be crashing? No, I regret, I haven't, but I will after my return to my desk at the lab. > > Could it be IPv6 related? Do you have IPv6 in the kernel and enabled? > I do. No, on all machines, those running firefox 3.6 cleanly and those which are unwilling IPv6 is not enabled. On the box in question, een thundebird 3.0.1 is crashing spontanously, while it isn't on those boxes which also run Firefox 3.6 cleanly. This puzzles me and I suspect either SMP (could it be threaded perl/python?) or a faulty library of X, which isn't built when performing 'portmaster -f firefox'. > > You could try adding these options to MOZ_OPTIONS in the Makefile > --enable-debug[=DBG] Enable building with developer debug info > --enable-debug-modules Enable/disable debug info for specific modules > --enable-debugger-info-modules > Enable/disable debugger info for specific modules > > --- > Gary Jennejohn Oliver From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 23:24:38 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A29E106568D for ; Tue, 9 Feb 2010 23:24:38 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id 7B9A38FC1F for ; Tue, 9 Feb 2010 23:24:36 +0000 (UTC) Received: by bwz3 with SMTP id 3so2269974bwz.33 for ; Tue, 09 Feb 2010 15:24:36 -0800 (PST) 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; bh=MdPWd/2E3PR8jb4tWYuaAiAMtn8w68ryQTFVNBrmQqk=; b=QmTSiahQBJ8eJCLs347aG0+xaucRNjDah5U0NyF6ZqluHJllYwEI35OTdEjmda3I7t OFeUyHx9OVxhkTkDYZyOCKEFvRbkNE4KqgkL53FAH4vmL0C7zHy+aQOPSibFEQg4+/6z Ah7zNR2lQ3W/gEr1UVxUmXRBfseHPONVAbv3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=X31wuidS/k9c2BiFFttvibzDlu2WNPaFgD1RaSn2t0OXsv6/0uj7AklQjAiK6yOqal L+riE4/bKxU+wKgrrCPyMyE/DO5f5WdlBr/O+Kyv+MYgBwyJTNKcDR2TkTWHTFUWbpWQ eLXOpIjNB2EFw4UuVHLCVKYMcrf/YZseigB18= MIME-Version: 1.0 Received: by 10.204.8.75 with SMTP id g11mr295331bkg.172.1265757876202; Tue, 09 Feb 2010 15:24:36 -0800 (PST) Date: Tue, 9 Feb 2010 23:24:31 +0000 Message-ID: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> From: Oliver Pinter To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-x11@freebsd.org, x11@FreeBSD.org Subject: freebsd7, radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 23:24:38 -0000 Hi all! After updated the xorg* and dri* and dependency, the system going to deadlock at second start of xserver. I think it is not an uniqe issue, as others wrote them at freebsd-x11: http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html The symptoms: * independent from enabled or disabled DRI or GLX, first I think, this is the error, but not * the system going to deadlock state * no coredumps of xorgs * no panic, but the system is unusuable * independent from the driver: probed the radeon and radeonhd driver * independent from the WITHOUT_NOUVEAU or WITH_NOUVEAU compile options (make.conf) * the system is: FreeBSD peonia.teteny.bme.hu 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #29 r203612+fa83fdf: Mon Feb 8 02:11:08 CET 2010 root@peonia.teteny.bme.hu:/usr/obj/usr/src/sys/stable amd64 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 23:32:58 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4476D1065670; Tue, 9 Feb 2010 23:32:58 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from out1.laposte.net (out2.laposte.net [193.251.214.119]) by mx1.freebsd.org (Postfix) with ESMTP id 003EC8FC0A; Tue, 9 Feb 2010 23:32:57 +0000 (UTC) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8207.laposte.net (SMTP Server) with ESMTP id 4CB3A7000084; Wed, 10 Feb 2010 00:32:55 +0100 (CET) Received: from [192.168.1.133] (137.228.100-84.rev.gaoland.net [84.100.228.137]) by mwinf8207.laposte.net (SMTP Server) with ESMTP id 0A3087000083; Wed, 10 Feb 2010 00:32:54 +0100 (CET) X-ME-UUID: 20100209233255418.0A3087000083@mwinf8207.laposte.net Message-ID: <4B71F0A3.6020401@laposte.net> Date: Wed, 10 Feb 2010 00:32:51 +0100 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Jeremy Chadwick References: <4B6228EF.5050400@laposte.net> <201001290802.o0T829sd050043@lurza.secnetix.de> <20100129090357.GA38872@icarus.home.lan> In-Reply-To: <20100129090357.GA38872@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-me-spamlevel: not-spam X-me-spamrating: 40.000000 X-me-spamcause: OK, (0)(0000)gggruggvucftvghtrhhoucdtuddrvdeltddrvdehucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecu Cc: freebsd-stable@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: su password prompt to stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 23:32:58 -0000 Jeremy Chadwick a =E9crit : >=20 > OpenPAM is des@'s responsibility. Has anyone brought this up to him? >=20 still no answer from des@ ! any idea ? Regards, Cyrille Lefevre --=20 mailto:Cyrille.Lefevre-lists@laposte.net From owner-freebsd-stable@FreeBSD.ORG Tue Feb 9 23:57:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58E94106568D for ; Tue, 9 Feb 2010 23:57:17 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A8CAA8FC30 for ; Tue, 9 Feb 2010 23:57:16 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o19NvEhf004694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 10 Feb 2010 10:27:14 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Wed, 10 Feb 2010 10:27:03 +1030 User-Agent: KMail/1.9.10 References: <4B6F9A8D.4050907@langille.org> <20100209053002.GA9449@over-yonder.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3769514.5anNkBbL1L"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002101027.11212.doconnor@gsoft.com.au> X-Spam-Score: -3.639 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Christian Weisgerber Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 23:57:17 -0000 --nextPart3769514.5anNkBbL1L Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 10 Feb 2010, Christian Weisgerber wrote: > Matthew D. Fuller wrote: > > > I have something similar (5x1Tb) - I have a Gigabyte > > > GA-MA785GM-US2H with an Athlon X2 and 4Gb of RAM (only half > > > filled - 2x2Gb) > > > > > > Note that it doesn't support ECC, I don't know if that is a > > > problem. > > > > How's that? Is the BIOS just stupid, or is the board physically > > missing traces? > > Doesn't matter really, does it? > > I have a GA-MA78G-DS3H. According to the specs, it supports ECC > memory. And that is all the mention of ECC you will find anywhere. > There is nothing in the BIOS. My best guess is that they quite > literally mean that you can plug ECC memory into the board and it > will work, but that there are no provisions to actually use ECC. =46WIW I can't see ECC support listed for that board on Gigabyte's=20 website.. (vs the GA-MA770T-UD3P which does list ECC as supported -=20 DDR3 board though) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3769514.5anNkBbL1L Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLcfZX5ZPcIHs/zowRAlrbAJ9N3YlyV+Kai0KnsSveY0B0RNTLPwCeOdWI sx4P7erwoHjpBtYgzplFwRY= =f2Re -----END PGP SIGNATURE----- --nextPart3769514.5anNkBbL1L-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 00:00:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C67BF1065693 for ; Wed, 10 Feb 2010 00:00:33 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3ADEA8FC15 for ; Wed, 10 Feb 2010 00:00:32 +0000 (UTC) Received: from inchoate.gsoft.com.au ([203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o1A00UNq004773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 10 Feb 2010 10:30:31 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Wed, 10 Feb 2010 10:30:27 +1030 User-Agent: KMail/1.9.10 References: <201002091231.17551.doconnor@gsoft.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4655901.eT2to6VThY"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002101030.29063.doconnor@gsoft.com.au> X-Spam-Score: -3.638 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Subject: Re: one more load-cycle-count problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 00:00:33 -0000 --nextPart4655901.eT2to6VThY Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 10 Feb 2010, Freddie Cash wrote: > > /d sets it (for me) to 6300 milliseconds (6.3 seconds). I took this > > as a special value that disabled it entirely (no idea why they > > didn't use 0 or 255..) > > > > I've seen reports of the same on various hardware forums. =C2=A0Not sure > > if it's > > due to different firmware, or different drive models. > > You should still be able to list the timeout value explicitly > (instead of using /d). =C2=A0According to the help output, you can use > either 25.5 seconds or 3000-something seconds as the max value > (depends on the drive). Yes I know, I used /d and haven't had any issues since. As the original timeout was 8 seconds I am pretty confident it treats 63=20 as special otherwise the problem would still be happening for me. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart4655901.eT2to6VThY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLcfcd5ZPcIHs/zowRAmiPAKCBiPxnCMemkHC3fYZ4SmZorFT/3ACaA7ge amdhvlXclq7Uhj307WJuiLQ= =mpl8 -----END PGP SIGNATURE----- --nextPart4655901.eT2to6VThY-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 00:22:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FA61106566C; Wed, 10 Feb 2010 00:22:53 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 37F148FC52; Wed, 10 Feb 2010 00:22:53 +0000 (UTC) Received: from straycat.dhs.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1A0MqGd054383; Wed, 10 Feb 2010 00:22:52 GMT (envelope-from tmclaugh@sdf.lonestar.org) Received: from tomcat.straycat.dhs.org (tomcat.straycat.dhs.org [192.168.2.213]) by straycat.dhs.org (8.14.1/8.14.1) with ESMTP id o1A0MooJ031162; Tue, 9 Feb 2010 19:22:51 -0500 (EST) Message-ID: <4B71FC5A.9080601@sdf.lonestar.org> Date: Tue, 09 Feb 2010 19:22:50 -0500 From: Tom McLaughlin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.1 MIME-Version: 1.0 To: John Baldwin References: <4B6B89E7.8030002@sdf.lonestar.org> <201002091352.24131.jhb@freebsd.org> <4B71DEFC.2000200@sdf.lonestar.org> <201002091723.44625.jhb@freebsd.org> In-Reply-To: <201002091723.44625.jhb@freebsd.org> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: kib@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 00:22:53 -0000 John Baldwin wrote, On 02/09/2010 05:23 PM: > On Tuesday 09 February 2010 5:17:32 pm Tom McLaughlin wrote: >> John Baldwin wrote, On 02/09/2010 01:52 PM: >>> On Monday 08 February 2010 9:49:00 am John Baldwin wrote: >>>> On Saturday 06 February 2010 4:47:16 pm Tom McLaughlin wrote: >>>>> John Baldwin wrote, On 02/05/2010 08:27 AM: >>>>>> On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: >>>>>>> Hi all, a recent MFC to 7-STABLE has started to cause issues for my > VMs >>>>>>> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk >>>>>>> controller the VM just shuts off. The workaround is to change the > disk >>>>>>> controller to the BusLogic type. Still, it used to work up until last >>>>>>> week. The change was made around January 26th and based on the > commits >>>>>>> that day I'm guessing it's either r203047 or r203073 >>>>>>> >>>>>>> I have the same issue with both amd64 and i386 VMs. This affects HEAD >>>>>>> and 8-STABLE as well and first affected HEAD over the summer. (I just >>>>>>> worked around it and went about my business at the time. :-/) I've >>>>>>> attached a dmesg from a kernel before the problem and one from after > it >>>>>>> started. >>>>>> >>>>>> What if you set 'hw.clfush_disable=1' from the loader? >>>>>> >>>>> >>>>> Yes, that corrected it on all my VMs. I've talked to people on ESXi 4 >>>>> and they do not see the problem. I have yet to try 3.5u5 to see if this >>>>> is a non-issue. 3.5 will be supported for awhile longer from VMware. >>>>> I'm going to try upgrading the box during the week. >>>> >>>> I believe folks had to do this on HEAD/8.x as well. Perhaps we can >>>> automatically disable clflush if we are executing under VMware or Xen: >>> >>> Tom, were you able to verify that this patch fixes the problem for you >>> without requiring you to set the hw.clflush_disable tunable? >>> >> >> John, I'm getting the following build error on all branches: >> >> /usr/src/sys/amd64/amd64/initcpu.c: In function 'initializecpucache': >> /usr/src/sys/amd64/amd64/initcpu.c:184: error: 'vm_guest' undeclared >> (first use in this function) >> /usr/src/sys/amd64/amd64/initcpu.c:184: error: (Each undeclared >> identifier is reported only once >> /usr/src/sys/amd64/amd64/initcpu.c:184: error: for each function it >> appears in.) > > Oh foo. Can you add 'extern int vm_guest;' to that file near the top? Adding that to the top fixed the build on 8.x and HEAD. Both of those are also now working just fine. However, 7.x still does not build. 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 vers.c linking kernel.debug initcpu.o(.text+0x272): In function `initializecpucache': /usr/src/sys/amd64/amd64/initcpu.c:186: undefined reference to `vm_guest' *** Error code 1 > >> *** Error code 1 >> >> >> tom >> >>>> Index: amd64/amd64/initcpu.c >>>> =================================================================== >>>> --- amd64/amd64/initcpu.c (revision 203430) >>>> +++ amd64/amd64/initcpu.c (working copy) >>>> @@ -177,17 +177,16 @@ >>>> if ((cpu_feature & CPUID_CLFSH) != 0) >>>> cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; >>>> /* >>>> - * XXXKIB: (temporary) hack to work around traps generated when >>>> - * CLFLUSHing APIC registers window. >>>> + * XXXKIB: (temporary) hack to work around traps generated >>>> + * when CLFLUSHing APIC registers window under virtualization >>>> + * environments. >>>> */ >>>> TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); >>>> - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && >>>> - hw_clflush_disable == -1) >>>> + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) >>>> cpu_feature &= ~CPUID_CLFSH; >>>> /* >>>> * Allow to disable CLFLUSH feature manually by >>>> - * hw.clflush_disable tunable. This may help Xen guest on some AMD >>>> - * CPUs. >>>> + * hw.clflush_disable tunable. >>>> */ >>>> if (hw_clflush_disable == 1) >>>> cpu_feature &= ~CPUID_CLFSH; >>>> Index: i386/i386/initcpu.c >>>> =================================================================== >>>> --- i386/i386/initcpu.c (revision 203430) >>>> +++ i386/i386/initcpu.c (working copy) >>>> @@ -724,17 +724,16 @@ >>>> if ((cpu_feature & CPUID_CLFSH) != 0) >>>> cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; >>>> /* >>>> - * XXXKIB: (temporary) hack to work around traps generated when >>>> - * CLFLUSHing APIC registers window. >>>> + * XXXKIB: (temporary) hack to work around traps generated >>>> + * when CLFLUSHing APIC registers window under virtualization >>>> + * environments. >>>> */ >>>> TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); >>>> - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && >>>> - hw_clflush_disable == -1) >>>> + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) >>>> cpu_feature &= ~CPUID_CLFSH; >>>> /* >>>> * Allow to disable CLFLUSH feature manually by >>>> - * hw.clflush_disable tunable. This may help Xen guest on some AMD >>>> - * CPUs. >>>> + * hw.clflush_disable tunable. >>>> */ >>>> if (hw_clflush_disable == 1) >>>> cpu_feature &= ~CPUID_CLFSH; >>>> >>>> -- >>>> John Baldwin >>>> _______________________________________________ >>>> 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" >>>> >>> >> >> >> -- >> | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | >> | FreeBSD http://www.FreeBSD.org | >> >> > -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 00:53:16 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C46E9106566C; Wed, 10 Feb 2010 00:53:16 +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 4EAC28FC21; Wed, 10 Feb 2010 00:53:16 +0000 (UTC) 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 <1Nf0Zd-0001fw-FG>; Wed, 10 Feb 2010 01:36:57 +0100 Received: from e178020182.adsl.alicedsl.de ([85.178.20.182] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Nf0Zd-0000pU-B4>; Wed, 10 Feb 2010 01:36:57 +0100 Message-ID: <4B71FFA8.3070306@mail.zedat.fu-berlin.de> Date: Wed, 10 Feb 2010 01:36:56 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100207 Thunderbird/3.0.1 MIME-Version: 1.0 To: Oliver Pinter References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> In-Reply-To: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.20.182 Cc: stable@freebsd.org, x11@FreeBSD.org, freebsd-x11@freebsd.org Subject: Re: freebsd7, radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 00:53:16 -0000 On 02/10/10 00:24, Oliver Pinter wrote: > Hi all! > > After updated the xorg* and dri* and dependency, the system going to > deadlock at second start of xserver. I think it is not an uniqe issue, > as others wrote them at freebsd-x11: > http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html > > The symptoms: > * independent from enabled or disabled DRI or GLX, first I think, this > is the error, but not > * the system going to deadlock state > * no coredumps of xorgs > * no panic, but the system is unusuable > * independent from the driver: probed the radeon and radeonhd driver > * independent from the WITHOUT_NOUVEAU or WITH_NOUVEAU compile options > (make.conf) > * the system is: FreeBSD peonia.teteny.bme.hu 7.3-PRERELEASE FreeBSD > 7.3-PRERELEASE #29 r203612+fa83fdf: Mon Feb 8 02:11:08 CET 2010 > root@peonia.teteny.bme.hu:/usr/obj/usr/src/sys/stable amd64 > _______________________________________________ > freebsd-stable@freebsd.org mailing list, > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" I had a similar freezing on several FreeBSD 8.0 boxes with either 'radeon' or 'radeonhd/radeonhd-devel' with recent ports. With more expensive graphics cards, like HD4830, HD4850 we never had the issue, but with smaller cards, like HD4670. HD4670 never worked. HD4770 cards work with explicit set option "DRI" "OFF" As far as I know, WITHOUT_NOUVEAU does have no effect on the current ports, since it is reported in ports/UPDATING, it prevents building nouveau driver which is broken when using newer libdrm/dri and libGLUT, but those new ports do not seem to be merged into the tree. The situation is heavily unsatisfying, since one need an expensive AMD/ATi Radeon card to gain non-3D poor functionality, where a cheaper one should be do the same - but the cheaper ones don't work. Even if one uses AMD64, the situattion is worse and I have no reason using Linux-driver on a FreeBSD box. Hope the situation gets cleared in the nearest future. It's a kind of deadlock. As I said, either spenig a lot of money for a working RV770 based AMD graphics card with poor functionality or nothing so far, since most smaller RV730 chips aren't supported properly by the most recent drivers. Regards, Oliver From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 00:55:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BC3D1065697 for ; Wed, 10 Feb 2010 00:55:18 +0000 (UTC) (envelope-from emikulic@gmail.com) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by mx1.freebsd.org (Postfix) with ESMTP id 1B7838FC19 for ; Wed, 10 Feb 2010 00:55:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPOOcUuWZZrw/2dsb2JhbACRAoljdK4PhwmIdoRUBI4a Received: from ppp154-240.static.internode.on.net ([150.101.154.240]) by ipmail07.adl2.internode.on.net with ESMTP; 10 Feb 2010 11:10:04 +1030 Received: by ppp154-240.static.internode.on.net (Poo-fix, from userid 1001) id 470755C44; Wed, 10 Feb 2010 11:40:03 +1100 (EST) Date: Wed, 10 Feb 2010 11:40:03 +1100 From: Emil Mikulic To: "Peter C. Lai" Message-ID: <20100210004003.GA2507@dmr.ath.cx> References: <4B6F9A8D.4050907@langille.org> <2e027be01002090451w2b4506a0ofb5ab55c647540a@mail.gmail.com> <2e027be01002090609y28be404dl1bb610d047b15f9b@mail.gmail.com> <2e027be01002090716y77213c45pb937e22151a2c238@mail.gmail.com> <20100209163155.GK4648@cesium.hyperfine.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100209163155.GK4648@cesium.hyperfine.info> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 00:55:18 -0000 On Tue, Feb 09, 2010 at 11:31:55AM -0500, Peter C. Lai wrote: > Also does anybody know if benching dd if=/dev/zero onto a zfs volume that > has compression turned on might affect what dd (which is getting what it > knows from vfs/vmm) might report? Absolutely! Compression on: 4294967296 bytes transferred in 16.251397 secs (264282961 bytes/sec) 4294967296 bytes transferred in 16.578707 secs (259065276 bytes/sec) 4294967296 bytes transferred in 16.178586 secs (265472353 bytes/sec) 4294967296 bytes transferred in 16.069003 secs (267282747 bytes/sec) Compression off: 4294967296 bytes transferred in 58.248351 secs (73735432 bytes/sec) From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 01:05:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82A3D106568F for ; Wed, 10 Feb 2010 01:05:57 +0000 (UTC) (envelope-from christof.schulze@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id DD3088FC08 for ; Wed, 10 Feb 2010 01:05:56 +0000 (UTC) Received: (qmail invoked by alias); 10 Feb 2010 01:05:55 -0000 Received: from e181218153.adsl.alicedsl.de (EHLO klausdieter0815.dyndns.org) [85.181.218.153] by mail.gmx.com (mp-eu003) with SMTP; 10 Feb 2010 02:05:55 +0100 X-Authenticated: #56306756 X-Provags-ID: V01U2FsdGVkX1+GHVFXLiuGYeFtBFAA2B3L/DugzxRHVPQABpt/ZZ b9qLZPxH2PAput Received: by myhost.mydomain.de (Postfix, from userid 1001) id 265F298A6; Wed, 10 Feb 2010 02:03:00 +0100 (CET) From: Christof Schulze To: freebsd-stable@freebsd.org Date: Wed, 10 Feb 2010 02:02:59 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.5; amd64; ; ) References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B71FFA8.3070306@mail.zedat.fu-berlin.de> In-Reply-To: <4B71FFA8.3070306@mail.zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7626550.6Z1gRQCGa3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002100202.59954.christof.schulze@gmx.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68000000000000005 Subject: Re: freebsd7, radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 01:05:57 -0000 --nextPart7626550.6Z1gRQCGa3 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable > The situation is heavily unsatisfying, since one need an expensive > AMD/ATi Radeon card to gain non-3D poor functionality, where a cheaper > one should be do the same - but the cheaper ones don't work. Even if one > uses AMD64, the situattion is worse and I have no reason using > Linux-driver on a FreeBSD box. Hope the situation gets cleared in the > nearest future. It's a kind of deadlock. As I said, either spenig a lot > of money for a working RV770 based AMD graphics card with poor > functionality or nothing so far, since most smaller RV730 chips aren't > supported properly by the most recent drivers. To be fair - my ATI X300 has always worked. It is a cheap card with low-end= =20 performance but it is perfectly fine for regular desktop-use. Christof =2D-=20 () ascii ribbon campaign - against html e-mail=20 /\ www.asciiribbon.org - against proprietary attachments --nextPart7626550.6Z1gRQCGa3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEABECAAYFAktyBcMACgkQpZfyPAmdZJn+YwCfU6Bz0EHzPVzo5bu5OzIzBFSP wKYAoIkPhydOtrjzLQrA70QZcoHl5P9b =VmIx -----END PGP SIGNATURE----- --nextPart7626550.6Z1gRQCGa3-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 01:28:35 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D1CD106566B for ; Wed, 10 Feb 2010 01:28: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 60FD38FC14 for ; Wed, 10 Feb 2010 01:28:34 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1A14jQ2000197 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 9 Feb 2010 20:04:46 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "O. Hartmann" In-Reply-To: <4B71FFA8.3070306@mail.zedat.fu-berlin.de> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B71FFA8.3070306@mail.zedat.fu-berlin.de> Content-Type: text/plain Organization: FreeBSD Date: Tue, 09 Feb 2010 19:04:40 -0600 Message-Id: <1265763880.8609.17.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@freebsd.org, x11@FreeBSD.org, freebsd-x11@freebsd.org, Oliver Pinter Subject: Re: freebsd7, radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 01:28:35 -0000 On Wed, 2010-02-10 at 01:36 +0100, O. Hartmann wrote: > On 02/10/10 00:24, Oliver Pinter wrote: > > Hi all! > > > > After updated the xorg* and dri* and dependency, the system going to > > deadlock at second start of xserver. I think it is not an uniqe issue, > > as others wrote them at freebsd-x11: > > http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html > > > > The symptoms: > > * independent from enabled or disabled DRI or GLX, first I think, this > > is the error, but not > > * the system going to deadlock state > > * no coredumps of xorgs > > * no panic, but the system is unusuable > > * independent from the driver: probed the radeon and radeonhd driver > > * independent from the WITHOUT_NOUVEAU or WITH_NOUVEAU compile options > > (make.conf) > > * the system is: FreeBSD peonia.teteny.bme.hu 7.3-PRERELEASE FreeBSD > > 7.3-PRERELEASE #29 r203612+fa83fdf: Mon Feb 8 02:11:08 CET 2010 > > root@peonia.teteny.bme.hu:/usr/obj/usr/src/sys/stable amd64 > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list, > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > I had a similar freezing on several FreeBSD 8.0 boxes with either > 'radeon' or 'radeonhd/radeonhd-devel' with recent ports. With more > expensive graphics cards, like HD4830, HD4850 we never had the issue, > but with smaller cards, like HD4670. HD4670 never worked. HD4770 cards > work with explicit set > > option "DRI" "OFF" > > As far as I know, WITHOUT_NOUVEAU does have no effect on the current > ports, since it is reported in ports/UPDATING, it prevents building > nouveau driver which is broken when using newer libdrm/dri and libGLUT, > but those new ports do not seem to be merged into the tree. > > The situation is heavily unsatisfying, since one need an expensive > AMD/ATi Radeon card to gain non-3D poor functionality, where a cheaper > one should be do the same - but the cheaper ones don't work. Even if one > uses AMD64, the situattion is worse and I have no reason using > Linux-driver on a FreeBSD box. Hope the situation gets cleared in the > nearest future. It's a kind of deadlock. As I said, either spenig a lot > of money for a working RV770 based AMD graphics card with poor > functionality or nothing so far, since most smaller RV730 chips aren't > supported properly by the most recent drivers. I'm only aware of one issue which leads to corruption. I have patches that resolve that issue which are not yet committed. If your are experiencing lockups with DRI disabled, then something very strange is going on and you will need to provide more details. I don't remember exactly what drm code I have committed to 7 right now, but it should be fairly current as I don't think I have much in the way of outstanding MFCs. The current drm and radeon drivers work on every card that I have, which in the r600 class are HD 3650,3850,4650. robert. > Regards, > Oliver > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 01:52:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A55281065679 for ; Wed, 10 Feb 2010 01:52:45 +0000 (UTC) (envelope-from rgrover1@gmail.com) Received: from mail-pz0-f179.google.com (mail-pz0-f179.google.com [209.85.222.179]) by mx1.freebsd.org (Postfix) with ESMTP id 7B50A8FC15 for ; Wed, 10 Feb 2010 01:52:45 +0000 (UTC) Received: by pzk9 with SMTP id 9so405100pzk.28 for ; Tue, 09 Feb 2010 17:52:45 -0800 (PST) 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=M2UCmWuztJRNOArdPjyIQIAz3C8D554OxNdfbAD2ocE=; b=Uf1S73WOz2BI6IwCK+STpzlZZm0p1i5pJ3Upz978/SZ/5pqWVd0ehcYt+4b5ybqDS+ giD8r0AGOwunpRejWSRELeNR/jnauHwSvVxb3C4qTKmysRWnUm4EVEPAmRER9oi//nT9 DprAXCpOaHe+vjIEZpx0jfRxjSeGI611HUJZE= 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=j/bO1LiczkoHBhV3N6QBOHI8LZ8yT/RB2vLlPR/12lBjaU85l9OH/fezL6x/JBIdUu IY6954Wb6OdgQuX5m+tp1p5x1KUw/JOn5UL5tKvMtVUCcTUie5oaPSaIMYBx1E3Zd51P zINwxUBVarinCmomBxEgNRVpKgBODIWx6SuKo= MIME-Version: 1.0 Received: by 10.141.100.11 with SMTP id c11mr970768rvm.196.1265766764808; Tue, 09 Feb 2010 17:52:44 -0800 (PST) In-Reply-To: References: <426bed111002080049u16354c87pd4fb8830e0542972@mail.gmail.com> <20100208114734.GA99245@icarus.home.lan> Date: Wed, 10 Feb 2010 07:22:44 +0530 Message-ID: <426bed111002091752g1cf96cd0qf7be5098ab5c9742@mail.gmail.com> From: Rohit Grover To: utisoft@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Unresponsive keyboard after a few boots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 01:52:45 -0000 Yes, this is a USB keyboard. If I plug in an external USB keyboard I get the same behaviour. In the mean time, I have discovered that if I boot the machine with MacOSX and then reboot into FreeBSD, it is very likely that FreeBSD will have no problems with using the keyboard. I am sure that this behaviour is new in 8.0/stable. Now that I have this method, I am willing to dig deeper into this problem and collect more information for debugging. Any ideas on how to proceed? regards, On Wed, Feb 10, 2010 at 1:16 AM, Chris Rees wrote: > On 8 February 2010 11:47, Jeremy Chadwick wrote: >> On Mon, Feb 08, 2010 at 02:19:06PM +0530, Rohit Grover wrote: >>> I am using a very recent Freebsd 8.0 STABLE on a Macbook. I updated my >>> sources and rebuilt a kernel about 3 days ago. I was able to use the >>> machine fine once or twice after that. But now the keyboard has >>> stopped working. The boot program is able to use the keyboard, but the >>> kernel isn't, and I am unable to do anything useful with the machine >>> from the login screen. >>> >>> I had rebuilt the kernel twice with slightly varying settings, so I >>> don't have a copy of the previously working kernel in >>> /boot/kernel.old. >>> >>> It may not be easy for me to download a ISO image. Can someone please help? >> >> Is the keyboard USB? >> > > No Mac since late generation Powerbooks and iBooks has used ADB, so > yes, the Macbook > keyboard is USB. > > HTH, > > Chris > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 03:41:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E69F4106568B for ; Wed, 10 Feb 2010 03:41:43 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 9BC578FC14 for ; Wed, 10 Feb 2010 03:41:43 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id o1A3fgKo012692; Tue, 9 Feb 2010 20:41:42 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id o1A3fgaS012689; Tue, 9 Feb 2010 20:41:42 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 9 Feb 2010 20:41:42 -0700 (MST) From: Warren Block To: Christof Schulze In-Reply-To: <201002100202.59954.christof.schulze@gmx.com> Message-ID: References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B71FFA8.3070306@mail.zedat.fu-berlin.de> <201002100202.59954.christof.schulze@gmx.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (wonkity.com [127.0.0.1]); Tue, 09 Feb 2010 20:41:42 -0700 (MST) Cc: freebsd-stable@freebsd.org Subject: Re: freebsd7, radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 03:41:44 -0000 On Wed, 10 Feb 2010, Christof Schulze wrote: >> The situation is heavily unsatisfying, since one need an expensive >> AMD/ATi Radeon card to gain non-3D poor functionality, where a cheaper >> one should be do the same - but the cheaper ones don't work. Even if one >> uses AMD64, the situattion is worse and I have no reason using >> Linux-driver on a FreeBSD box. Hope the situation gets cleared in the >> nearest future. It's a kind of deadlock. As I said, either spenig a lot >> of money for a working RV770 based AMD graphics card with poor >> functionality or nothing so far, since most smaller RV730 chips aren't >> supported properly by the most recent drivers. > To be fair - my ATI X300 has always worked. It is a cheap card with low-end > performance but it is perfectly fine for regular desktop-use. The older chipsets are better supported because the newer ones are, well, newer. If you haven't bought a video card yet, look at the radeon(4x) man page first. Unfortunately, that doesn't help if you already have a newer card, or a notebook. The other choices are Intel, where they don't have standalone video cards, or nVidia, which has a full-featured blob and a really bare-bones open driver. -Warren Block * Rapid City, South Dakota USA From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 04:22:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D343106568B for ; Wed, 10 Feb 2010 04:22:41 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from smtp.cyberfingers.net (smtp.cyberfingers.net [198.177.254.227]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0EC8FC1A for ; Wed, 10 Feb 2010 04:22:41 +0000 (UTC) Received: from [192.168.1.107] (CPE0023695b905f-CM001a666aca96.cpe.net.cable.rogers.com [99.246.67.95]) by smtp.cyberfingers.net (Postfix) with ESMTP id 2647BAB6C64 for ; Tue, 9 Feb 2010 23:19:42 -0500 (EST) Message-ID: <4B72348E.3000008@pldrouin.net> Date: Tue, 09 Feb 2010 23:22:38 -0500 From: Pierre-Luc Drouin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B70C1F8.8090809@pldrouin.net> <20100209022039.GE4648@cesium.hyperfine.info> <4B70C851.9010604@pldrouin.net> <201002091608.24051.doconnor@gsoft.com.au> <4B71D0C3.5040907@pldrouin.net> In-Reply-To: <4B71D0C3.5040907@pldrouin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 8.0 i386 unable to boot... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 04:22:41 -0000 About this problem, I have seen that in the past there have been problem with libdisk when a WinXP partition had an invalid name. Could it be something like that that could be causing this error? I guess the problem occurs somewhere in the Open_Disk function of libdisk, right? Should I be able to get around this problem by installing through a PC-BSD CD instead? I have never tried PC-BSD. Does their installer rely on libdisk at all? Thanks! Pierre-Luc Drouin wrote: > Daniel O'Connor wrote: >> On Tue, 9 Feb 2010, Pierre-Luc Drouin wrote: >> >>> After doing some more research, it seems that I am having the same >>> problem than described by this person: >>> http://forums.freebsd.org/showthread.php?t=4502 >>> >> >> So you get the same "file system full" message and then a panic about >> init? >> > yes exactly. I currently have 4 20GB partitions/slices on that drive > 1: Win XP fat32 > 2: Old FreeBSD installation > 3: FAT32 > 4: Empty UFS2 >> >>> however I really don't understand why I would need to move partitions >>> around to allow the installer to even start? This machine has 2GB of >>> RAM which I guess should be plenty enough to start the installer >>> without swapping... The hard drive is a 80GB WD IDE drive. The >>> machine is not configured to use any RAID. >>> >> >> It is pretty odd, I've installed FreeBSD on a laptop with 60Gb >> partitions and FreeBSD was last yet it worked fine.. >> >> > This is the first time I see that kind of warning as well although I > have been using it for about 10 years... > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 04:28:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A76D106566C for ; Wed, 10 Feb 2010 04:28:55 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4D70A8FC0C for ; Wed, 10 Feb 2010 04:28:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id C7FFB508A8; Wed, 10 Feb 2010 04:28:54 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg5YaltWjjP9; Wed, 10 Feb 2010 04:28:54 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id E21C350830 ; Wed, 10 Feb 2010 04:28:53 +0000 (GMT) Message-ID: <4B723609.8010802@langille.org> Date: Tue, 09 Feb 2010 23:28:57 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Boris Kochergin References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> <20100209161817.GI4648@cesium.hyperfine.info> <4B718EBB.6080709@acm.poly.edu> In-Reply-To: <4B718EBB.6080709@acm.poly.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Peter C. Lai" , Charles Sprickman , FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 04:28:55 -0000 Boris Kochergin wrote: > Peter C. Lai wrote: >> On 2010-02-09 06:37:47AM -0500, Dan Langille wrote: >> >>> Charles Sprickman wrote: >>> >>>> On Mon, 8 Feb 2010, Dan Langille wrote: >>>> Also, it seems like >>>> people who use zfs (or gmirror + gstripe) generally end up buying >>>> pricey hardware raid cards for compatibility reasons. There seem to >>>> be no decent add-on SATA cards that play nice with FreeBSD other >>>> than that weird supermicro card that has to be physically hacked >>>> about to fit. >>>> >> >> Mostly only because certain cards have issues w/shoddy JBOD >> implementation. Some cards (most notably ones like Adaptec 2610A which >> was rebranded by Dell as the "CERC SATA 1.5/6ch" back in the day) >> won't let you run the drives in passthrough mode and seem to all want >> to stick their grubby little RAID paws into your JBOD setup (i.e. the >> only way to have minimal >> participation from the "hardware" RAID is to set each disk as its own >> RAID-0/volume in the controller BIOS) which then cascades into issues >> with SMART, AHCI, "triple caching"/write reordering, etc on the >> FreeBSD side (the controller's own craptastic cache, ZFS vdev cache, >> vmm/app cache, oh my!). So *some* people go with something >> tried-and-true (basically bordering on server-level cards that let you >> ditch any BIOS type of RAID config and present the raw disk devices to >> the kernel) > As someone else has mentioned, recent SiL stuff works well. I have > multiple http://www.newegg.com/Product/Product.aspx?Item=N82E16816132008 > cards servicing RAID-Z2 and GEOM_RAID3 arrays on 8.0-RELEASE and > 8.0-STABLE machines using both the old ata(4) driver and ATA_CAM. Don't > let the RAID label scare you--that stuff is off by default and the > controller just presents the disks to the operating system. Hot swap > works. I haven't had the time to try the siis(4) driver for them, which > would result in better performance. That's a really good price. :) If needed, I could host all eight SATA drives for $160, much cheaper than any of the other RAID cards I've seen. The issue then is finding a motherboard which has 4x PCI Express slots. ;) From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 05:02:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 036EB106568B for ; Wed, 10 Feb 2010 05:02:48 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id CB3038FC0C for ; Wed, 10 Feb 2010 05:02:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 157C0508B0; Wed, 10 Feb 2010 05:02:47 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8e-9UCMHSiH; Wed, 10 Feb 2010 05:02:46 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id EF2D950823 ; Wed, 10 Feb 2010 05:02:45 +0000 (GMT) Message-ID: <4B723DF9.3070105@langille.org> Date: Wed, 10 Feb 2010 00:02:49 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Matthew Dillon References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> <4B71AED5.4030002@wensing.org> <201002091949.o19JntPo009017@apollo.backplane.com> In-Reply-To: <201002091949.o19JntPo009017@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 05:02:48 -0000 Trying to make sense of stuff I don't know about... Matthew Dillon wrote: > > AHCI on-motherboard with equivalent capabilities do not appear to be > in wide distribution yet. Most AHCI chips can do NCQ to a single > target (even a single target behind a PM), but not concurrently to > multiple targets behind a port multiplier. Even though SATA bandwidth > constraints might seem to make this a reasonable alternative it > actually isn't because any seek heavy activity to multiple drives > will be serialized and perform EXTREMELY poorly. Linear performance > will be fine. Random performance will be horrible. Don't use a port multiplier and this goes away. I was hoping to avoid a PM and using something like the Syba PCI Express SATA II 4 x Ports RAID Controller seems to be the best solution so far. http://www.amazon.com/Syba-Express-Ports-Controller-SY-PEX40008/dp/B002R0DZWQ/ref=sr_1_22?ie=UTF8&s=electronics&qid=1258452902&sr=1-22 > > It should be noted that while hotswap is supported with silicon image > chipsets and port multiplier enclosures (which also use Sili chips in > the enclosure), the hot-swap capability is not anywhere near as robust > as you would find with a more costly commercial SAS setup. SI chips > are very poorly made (this is the same company that went bust under > another name a few years back due to shoddy chipsets), and have a lot > of on-chip hardware bugs, but fortunately OSS driver writers (linux > guys) have been able to work around most of them. So even though the > chipset is a bit shoddy actual operation is quite good. However, > this does mean you generally want to idle all activity on the enclosure > to safely hot swap anything, not just the drive you are pulling out. > I've done a lot of testing and hot-swapping an idle disk while other > drives in the same enclosure are hot is not reliable (for a cheap port > multiplier enclosure using a Sili chip inside, which nearly all do). What I'm planning to use is an SATA enclosure but I'm pretty sure a port multiplier is not involved: http://www.athenapower.us/web_backplane_zoom/bp_sata3141b.html > Also, a disk failure within the enclosure can create major command > sequencing issues for other targets in the enclosure because error > processing has to be serialized. Fine for home use but don't expect > miracles if you have a drive failure. Another reason to avoid port multipliers. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 05:57:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 166CC1065670 for ; Wed, 10 Feb 2010 05:57:29 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 890D68FC0C for ; Wed, 10 Feb 2010 05:57:28 +0000 (UTC) Received: by fxm24 with SMTP id 24so39850fxm.3 for ; Tue, 09 Feb 2010 21:57:27 -0800 (PST) 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=iTotW8YGszGrrGmkUBH0/9f2HM2bhVTjiuAPGYoIPNE=; b=wlHfJtUS/RY2wXIZZAQQqVK5QgkekMeuGO5VM3ioloebZgdePTc315NSKkYSSOqBaf cjL1cs9UvPCDqzSerTZijBxjI+SbnI2PNCanOrLIKQuMl+Ly4sN9ZZrULMFa09zAPrYJ cwBXoSDd4WI+jySzd0C7NQKomPYSGUgtEqEOE= 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=Y04/GYkgq5wTaLo5yEYmDXnwtROngLfDJetRnY9246rATFSM0dsuz9KJNweEDTB2ST PBVfqVX4hIYhE16wjhY5GVBBv1ye5Hh3Ihn4I5snU03JogZRoBnZD70H/4vUX8mIxyPQ QKQOM4nBAvShMsYpUglli6M2Noqdz3a3c9kKY= MIME-Version: 1.0 Sender: ndenev@gmail.com Received: by 10.223.132.209 with SMTP id c17mr4673889fat.37.1265781447488; Tue, 09 Feb 2010 21:57:27 -0800 (PST) In-Reply-To: <20100209225631.GP4648@cesium.hyperfine.info> References: <4B6F9A8D.4050907@langille.org> <4B70FEEC.6070007@modulus.org> <20100209063310.GA23387@icarus.home.lan> <4B715AC6.5090500@denninger.net> <20100209134456.GA37029@icarus.home.lan> <20100209225631.GP4648@cesium.hyperfine.info> Date: Wed, 10 Feb 2010 07:57:27 +0200 X-Google-Sender-Auth: 1c3169b603375977 Message-ID: <2e77fc11002092157x645105cdi543a8729aec37b2d@mail.gmail.com> From: Niki Denev To: "Peter C. Lai" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 05:57:29 -0000 On Wed, Feb 10, 2010 at 12:56 AM, Peter C. Lai wrot= e: > On 2010-02-09 05:32:02PM -0500, Charles Sprickman wrote: >> On Tue, 9 Feb 2010, Jeremy Chadwick wrote: >>> One similar product that does seem to work well is iLO, available on >>> HP/Compaq hardware. >> >> I've heard great things about that. =A0It seems like a much better desig= n - >> it's essentially a small server that is independent from the main host. = Has >> it's own LAN and serial ports as well. >> >> Charles > > Dell PowerEdge Remote Access (DRAC) cards also provided this as well, > and for a while there, you could actually VNC into them. But HP offers iL= O > for no extra charge or discount upon removal (DRACs are worth about $250) > and has become such a prominent "must-have" datacenter feature that the > "iLO" term is beginning to become genericized for web-accessible and virt= ual > disc-capable onboard out-of-band IP-console management. > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Peter C. Lai =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Bard College at Simon's Ro= ck > Systems Administrator =A0 =A0 =A0 =A0| 84 Alford Rd. > Information Technology Svcs. | Gt. Barrington, MA 01230 USA > peter AT simons-rock.edu =A0 =A0 | (413) 528-7428 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I thought that their VNC implementation is non-standard, and I wasn't able to VPN into them, at least on the latest Core i7 models. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 06:35:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37315106566C for ; Wed, 10 Feb 2010 06:35:49 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id C29D18FC12 for ; Wed, 10 Feb 2010 06:35:48 +0000 (UTC) Received: by wwj40 with SMTP id 40so2691961wwj.13 for ; Tue, 09 Feb 2010 22:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=dl7BFiUzTrNnZJha60tMeJ5yEFlPXlCYRmX1xYxdAAY=; b=chfvgnkLnDo0zkHmgJXe2qbjQVcnGChh6rFOOenfbYxPBPmc0X+RzuYJyu2eR4jnC1 bF+X/BlyoaXvHuTfKHnMVQfR4yqjuy4ahcJHeCc6vdI7vlely/RMOYyx+K292x1vrpcd RL40d2GKGgpUpYiQpM062HIvd8oD+FVYJp7nM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=NKMbDDX/yFcE6XB5Z/1lBMjrY6Sm/lhOl8IT8JhGDZJ2YuIHZXvw9dORfFTnq4v/+X kDXQZKdwQ1woxLHbX9vwSHS389geABHrsfctgk9NwP9Z/eQpyP+ectpJ9IfwGxogrhAJ z8i8sIIqDUUvGZDsDVAPq/OQbVSSu8Jt3cv/w= MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.216.159.204 with SMTP id s54mr835106wek.99.1265783747273; Tue, 09 Feb 2010 22:35:47 -0800 (PST) In-Reply-To: <20100209215110.GJ1358@michelle.cdnetworks.com> References: <20100202193616.GA16953@osiris.chen.org.nz> <3131aa531002091231o3003a60ay7e83b17fa995063b@mail.gmail.com> <20100209215110.GJ1358@michelle.cdnetworks.com> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Wed, 10 Feb 2010 07:35:27 +0100 X-Google-Sender-Auth: 4aff7de8123e2b24 Message-ID: <3131aa531002092235t396664aajf247f7a69b6ef12b@mail.gmail.com> To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE outgoing scp stalling frequently. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 06:35:49 -0000 On Tue, Feb 9, 2010 at 10:51 PM, Pyun YongHyeon wrote: > > I guess I fixed all known vge(4) issues, how recent stable/8 you > use? > Hi, my mistake, it's a release and not a stable version that I'm using: uname -a FreeBSD dev.bsdrp.net 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 16:02:27 UTC 2010 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 Regards, Olivier From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 07:10:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F54D1065670 for ; Wed, 10 Feb 2010 07:10:45 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 2DC168FC13 for ; Wed, 10 Feb 2010 07:10:44 +0000 (UTC) Received: by fxm24 with SMTP id 24so73767fxm.3 for ; Tue, 09 Feb 2010 23:10:44 -0800 (PST) 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=jlf2Z1ocGXoIA+hacP9zEn6dFnU2cub8E/X51beMDfA=; b=DuN97JCZpGZauofUuiwTnC6qKzmDkTC8qKtPwubJ327eJCNe5teX43/Kw6OunC6Tx7 E1S7fpmPTL/iUQHTiAPJuxy4YMP4O7jfe1Glo6SbwBCdjz7/hxEX3XYJmu6aM1wqxiQx ilwfZOYG3aj9lAgVX8TLHwMmwf3H5c8XqGygE= 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=GTnuhuxzbwKx2SxOPYRzURYAt3TZmP3qK+QHcjUuP/DW/hMcdI34XfEjANm9gSibA2 tbj9mmIhua2mbyCqcybqy+yqB+kl/kunHBJhpcUgWii3oq05YllxGxu4hw297L+0lDT1 6MQYwT+L4SxEQvs+GD/GqKp8EX3L+THBsaamE= MIME-Version: 1.0 Received: by 10.239.188.84 with SMTP id o20mr1005424hbh.81.1265785843957; Tue, 09 Feb 2010 23:10:43 -0800 (PST) In-Reply-To: <426bed111002091752g1cf96cd0qf7be5098ab5c9742@mail.gmail.com> References: <426bed111002080049u16354c87pd4fb8830e0542972@mail.gmail.com> <20100208114734.GA99245@icarus.home.lan> <426bed111002091752g1cf96cd0qf7be5098ab5c9742@mail.gmail.com> Date: Wed, 10 Feb 2010 02:10:43 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Rohit Grover Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick , utisoft@gmail.com Subject: Re: Unresponsive keyboard after a few boots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 07:10:45 -0000 On Tue, Feb 9, 2010 at 8:52 PM, Rohit Grover wrote: > Yes, this is a USB keyboard. If I plug in an external USB keyboard I > get the same behaviour. > > In the mean time, I have discovered that if I boot the machine with > MacOSX and then reboot into FreeBSD, it is very likely that FreeBSD > will have no problems with using the keyboard. > > I am sure that this behaviour is new in 8.0/stable. > Now that I have this method, I am willing to dig deeper into this > problem and collect more information for debugging. Any ideas on how > to proceed? > > regards, > My opinion is that MacOSX is initializing some circuit areas but FreeBSD 8.0 is NOT touching in those areas . Therefore , initialization values from MacOSX are remaining in place and FreeBSD 8.0 is using those values without changing them . This idea is a pure guess , but when FreeBSD 8.0 starts initially and USB key board does not work , there seems that this is most likely possibility . If it is possible the following steps may be useful : Initially start MacOSX , dump all of the related circuit register values . Start FreeBSD 8.0 , repeat the dumping of the related circuit register values . This will give differences between two boots . Initially start FreeBSD and dump all of the related circuit register values . This may require a key board . Problem is to override this requirement . If in the system there is also a PS/2 key board slot , a PS/2 keyboard may be utilized . Another way may be a shell script or program starting on boot automatically to dump the required values . In that case , a key board may not be required . This will show uninitialized values . Related sources may also be studied to understand which areas are left without initializations . Successive boots may clear properly stored circuit register values and they do not initialize them properly . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 08:24:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE29B1065670 for ; Wed, 10 Feb 2010 08:24:15 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 20A2C8FC12 for ; Wed, 10 Feb 2010 08:24:14 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1A8OCDS008495; Wed, 10 Feb 2010 09:24:13 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 45A3624; Wed, 10 Feb 2010 09:24:12 +0100 (CET) Date: Wed, 10 Feb 2010 09:24:12 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Elliot Finley Message-Id: <20100210092412.5a06d98e.gerrit@pmp.uni-hannover.de> In-Reply-To: <54e63c321002091227w15657c54oeb2295efc4c43980@mail.gmail.com> References: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> <54e63c321002091227w15657c54oeb2295efc4c43980@mail.gmail.com> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.10.81225 Cc: freebsd-stable@freebsd.org Subject: Re: zpool vdev vs. glabel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 08:24:15 -0000 On Tue, 9 Feb 2010 13:27:21 -0700 Elliot Finley wrote about Re: zpool vdev vs. glabel: EF> I ran into this same problem. you need to clean the beginning and end EF> of your disk off before glabeling and adding it to your pool. clean EF> with dd if=/dev/zero... Hm, I think I did that (at least for the beginning part). Maybe I was not quite clear what I did below: I removed and re-attached the *same* disk which was labelled with glabel and running fine brefore. The label was there when I inserted it back, but zfs went for the da device node anyway. If I see this problem again, I will try to wipe the complete disk before re-inserting it. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 08:24:47 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF5F31065679; Wed, 10 Feb 2010 08:24:47 +0000 (UTC) (envelope-from masoom.shaikh@gmail.com) Received: from mail-px0-f203.google.com (mail-px0-f203.google.com [209.85.216.203]) by mx1.freebsd.org (Postfix) with ESMTP id 956688FC21; Wed, 10 Feb 2010 08:24:47 +0000 (UTC) Received: by pxi41 with SMTP id 41so8423809pxi.27 for ; Wed, 10 Feb 2010 00:24:47 -0800 (PST) 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=T4eSmwMTcKtN8v3FcuP75CJRyTGKO1kwdRram0/SVfs=; b=piCZ7MIqoQmLE8RSojFAYYd8wNj8XbkOCJwQp19soorL71SjO0bRKe6dApS3DO2IG+ aa8O9a7+ft3CvGJSmQjTlCJO0a6taY+OWRQFVgar3b06ejsvViv5xRQ/L+rEaE1MPTGP L8azLwPCErgRpe6eHaI2K3GS7f5O0ZTfIZwGI= 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=Gz9vQCOiJAnpekeiZ7rKmBd8JZkB5bUtUIt+6bd983Dp1jY4o/WCESjuaybkYRgsEw A5CWA1/v5tmpZGtoU9iClE4mCipY/Bd+taq3aSHjhPBHnjr6OzjXA7Cgc2cEc6FHyc4A cKD6mIACToNlg8eIqs87C5fxbDM5AHC1eJDcM= MIME-Version: 1.0 Received: by 10.115.65.17 with SMTP id s17mr3975940wak.100.1265788451618; Tue, 09 Feb 2010 23:54:11 -0800 (PST) In-Reply-To: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> Date: Wed, 10 Feb 2010 13:24:11 +0530 Message-ID: From: Masoom Shaikh To: Oliver Pinter Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, x11@freebsd.org, freebsd-x11@freebsd.org Subject: Re: freebsd7, radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 08:24:47 -0000 On Wed, Feb 10, 2010 at 4:54 AM, Oliver Pinter wrote: > Hi all! > > After updated the xorg* and dri* and dependency, the system going to > deadlock at second start of xserver. I think it is not an uniqe issue, > as others wrote them at freebsd-x11: > http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html > > The symptoms: > * independent from enabled or disabled DRI or GLX, first I think, this > is the error, but not > * the system going to deadlock state > * no coredumps of xorgs > * no panic, but the system is unusuable > * independent from the driver: probed the radeon and radeonhd driver > * independent from the WITHOUT_NOUVEAU or WITH_NOUVEAU compile options > (make.conf) > * the system is: FreeBSD peonia.teteny.bme.hu 7.3-PRERELEASE FreeBSD > 7.3-PRERELEASE #29 r203612+fa83fdf: Mon Feb 8 02:11:08 CET 2010 > root@peonia.teteny.bme.hu:/usr/obj/usr/src/sys/stable amd64 > _______________________________________________ > 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" > are you using intel wireless cards ? I had/having similar issues when such freeze happens hard boot is the only option. I think it has something to do with wlandev or something related to wpi driver. I cannot comment more since coredumps are occasional and back trace suggests it is doadump(). here is my report earlier http://lists.freebsd.org/pipermail/freebsd-questions/2009-November/207768.html From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 08:31:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BE5E106566C for ; Wed, 10 Feb 2010 08:31:01 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 728E18FC14 for ; Wed, 10 Feb 2010 08:31:00 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta10.emeryville.ca.mail.comcast.net with comcast id g8SU1d0011u4NiLAA8X1NR; Wed, 10 Feb 2010 08:31:01 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta21.emeryville.ca.mail.comcast.net with comcast id g8X01d0073S48mS8h8X19L; Wed, 10 Feb 2010 08:31:01 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D1D571E3033; Wed, 10 Feb 2010 00:30:59 -0800 (PST) Date: Wed, 10 Feb 2010 00:30:59 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100210083059.GA62117@icarus.home.lan> References: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> <54e63c321002091227w15657c54oeb2295efc4c43980@mail.gmail.com> <20100210092412.5a06d98e.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100210092412.5a06d98e.gerrit@pmp.uni-hannover.de> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: zpool vdev vs. glabel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 08:31:01 -0000 On Wed, Feb 10, 2010 at 09:24:12AM +0100, Gerrit Kühn wrote: > On Tue, 9 Feb 2010 13:27:21 -0700 Elliot Finley > wrote about Re: zpool vdev vs. glabel: > > EF> I ran into this same problem. you need to clean the beginning and end > EF> of your disk off before glabeling and adding it to your pool. clean > EF> with dd if=/dev/zero... > > Hm, I think I did that (at least for the beginning part). > Maybe I was not quite clear what I did below: I removed and re-attached > the *same* disk which was labelled with glabel and running fine brefore. > The label was there when I inserted it back, but zfs went for the da > device node anyway. > If I see this problem again, I will try to wipe the complete disk before > re-inserting it. If I remember right, glabel metadata is stored in the last sector of the disk, not the beginning. "glabel clear" would probably be easier than dd if=/dev/zero'ing the entire disk. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 08:58:16 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09190106566C for ; Wed, 10 Feb 2010 08:58:16 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 832998FC14 for ; Wed, 10 Feb 2010 08:58:15 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o1A8wEWF040941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Feb 2010 09:58:14 +0100 (CET) (envelope-from uqs@FreeBSD.org) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o1A8wEPf040940 for stable@freebsd.org; Wed, 10 Feb 2010 09:58:14 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Wed, 10 Feb 2010 09:58:14 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: stable@FreeBSD.org Message-ID: <20100210085814.GE9748@acme.spoerlein.net> Mail-Followup-To: stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: numeric sort(1) is broken on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 08:58:16 -0000 Hi guys, not sure if this is a pilot error, but it seems to me that gnu sort -n is broken on at least -STABLE (couldn't test -CURRENT yet). It somehow does not manifest when using a simple list and sorting on a specific column, but it always happens to me when using it in combination with find(1). % truncate -s10m a; truncate -s5m b; truncate -s800k c % find a b c -ls|sort -nk7,7 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c % find a b c -ls|sort -gk7,7 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a at least -g does what is expected and I can work around this for the time being. Here's bsdsort % find a b c -ls|bsdsort -nk7,7 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a and this is on Solaris 8 % find a b c -ls|sort -nk7,7 546728 16 -rw-r--r-- 1 spoerul xxx 819200 Feb 10 09:49 c 546727 16 -rw-r--r-- 1 spoerul xxx 5242880 Feb 10 09:48 b 546724 16 -rw-r--r-- 1 spoerul xxx 10485760 Feb 10 09:48 a It even occured to me, that we don't have a sort regression suite under tools/regression. Anyone know a place to find one with a suitable license? Regards, Uli From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 09:18:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5A3A1065676 for ; Wed, 10 Feb 2010 09:18:56 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 79C6D8FC1D for ; Wed, 10 Feb 2010 09:18:56 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta06.emeryville.ca.mail.comcast.net with comcast id g9Jw1d0031smiN4A69Jwkd; Wed, 10 Feb 2010 09:18:56 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id g9Jw1d0023S48mS8g9Jw7Y; Wed, 10 Feb 2010 09:18:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0B2701E3033; Wed, 10 Feb 2010 01:18:55 -0800 (PST) Date: Wed, 10 Feb 2010 01:18:55 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100210091854.GA62983@icarus.home.lan> References: <20100210085814.GE9748@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100210085814.GE9748@acme.spoerlein.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: numeric sort(1) is broken on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 09:18:56 -0000 On Wed, Feb 10, 2010 at 09:58:14AM +0100, Ulrich Spörlein wrote: > Hi guys, > > not sure if this is a pilot error, but it seems to me that gnu sort -n > is broken on at least -STABLE (couldn't test -CURRENT yet). > > It somehow does not manifest when using a simple list and sorting on a > specific column, but it always happens to me when using it in > combination with find(1). > > % truncate -s10m a; truncate -s5m b; truncate -s800k c > % find a b c -ls|sort -nk7,7 > 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a > 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b > 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c > % find a b c -ls|sort -gk7,7 > 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c > 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b > 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a I can't repro this on 8.0-STABLE or 7.2-STABLE. /usr/bin/sort on these machines is what comes with the base system (which is GNU coreutils sort). Maybe your issue is related to locale(1) variables? $ uname -a FreeBSD icarus.home.lan 8.0-STABLE FreeBSD 8.0-STABLE #0: Sat Jan 16 17:48:04 PST 2010 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 $ truncate -s10m a; truncate -s5m b; truncate -s800k c $ find a b c -ls | /usr/bin/sort -nk7,7 3078 1 -rw------- 1 jdc users 819200 10 Feb 01:11 c 3077 1 -rw------- 1 jdc users 5242880 10 Feb 01:11 b 3076 1 -rw------- 1 jdc users 10485760 10 Feb 01:11 a $ find a b c -ls | /usr/bin/sort -gk7,7 3078 1 -rw------- 1 jdc users 819200 10 Feb 01:11 c 3077 1 -rw------- 1 jdc users 5242880 10 Feb 01:11 b 3076 1 -rw------- 1 jdc users 10485760 10 Feb 01:11 a $ /usr/bin/sort --version sort (GNU coreutils) 5.3.0-20040812-FreeBSD Written by Mike Haertel and Paul Eggert. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ locale LANG=en_GB.ISO8859-1 LC_CTYPE="en_GB.ISO8859-1" LC_COLLATE=C LC_TIME="en_GB.ISO8859-1" LC_NUMERIC="en_GB.ISO8859-1" LC_MONETARY="en_GB.ISO8859-1" LC_MESSAGES="en_GB.ISO8859-1" LC_ALL= $ uname -a FreeBSD horus.parodius.com 7.2-STABLE FreeBSD 7.2-STABLE #0: Sat Jan 9 07:52:27 PST 2010 root@horus.sc1.parodius.com:/usr/obj/usr/src/sys/PDSMI_PLUS_RELENG_7_amd64 amd64 $ truncate -s10m a; truncate -s5m b; truncate -s800k c $ find a b c -ls | /usr/bin/sort -nk7,7 406132 1 -rw------- 1 jdc users 819200 10 Feb 01:13 c 406131 1 -rw------- 1 jdc users 5242880 10 Feb 01:13 b 406130 1 -rw------- 1 jdc users 10485760 10 Feb 01:13 a $ find a b c -ls | /usr/bin/sort -gk7,7 406132 1 -rw------- 1 jdc users 819200 10 Feb 01:13 c 406131 1 -rw------- 1 jdc users 5242880 10 Feb 01:13 b 406130 1 -rw------- 1 jdc users 10485760 10 Feb 01:13 a $ /usr/bin/sort --version sort (GNU coreutils) 5.3.0-20040812-FreeBSD Written by Mike Haertel and Paul Eggert. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ locale LANG=en_GB.ISO8859-1 LC_CTYPE="en_GB.ISO8859-1" LC_COLLATE=C LC_TIME="en_GB.ISO8859-1" LC_NUMERIC="en_GB.ISO8859-1" LC_MONETARY="en_GB.ISO8859-1" LC_MESSAGES="en_GB.ISO8859-1" LC_ALL= -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 09:19:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D87BB10657A4 for ; Wed, 10 Feb 2010 09:19:10 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 781D28FC0C for ; Wed, 10 Feb 2010 09:19:10 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 25so1041766eya.3 for ; Wed, 10 Feb 2010 01:19:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.88.79 with SMTP id z57mr1149331wee.22.1265793549344; Wed, 10 Feb 2010 01:19:09 -0800 (PST) In-Reply-To: <20100210092412.5a06d98e.gerrit@pmp.uni-hannover.de> References: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> <54e63c321002091227w15657c54oeb2295efc4c43980@mail.gmail.com> <20100210092412.5a06d98e.gerrit@pmp.uni-hannover.de> From: =?UTF-8?Q?Marius_N=C3=BCnnerich?= Date: Wed, 10 Feb 2010 10:18:49 +0100 Message-ID: To: =?UTF-8?B?R2Vycml0IEvDvGhu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Elliot Finley , freebsd-stable@freebsd.org Subject: Re: zpool vdev vs. glabel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 09:19:10 -0000 2010/2/10 Gerrit K=C3=BChn : > On Tue, 9 Feb 2010 13:27:21 -0700 Elliot Finley > wrote about Re: zpool vdev vs. glabel: > > EF> I ran into this same problem. =C2=A0you need to clean the beginning a= nd end > EF> of your disk off before glabeling and adding it to your pool. =C2=A0c= lean > EF> with dd if=3D/dev/zero... > > Hm, I think I did that (at least for the beginning part). > Maybe I was not quite clear what I did below: I removed and re-attached > the *same* disk which was labelled with glabel and running fine brefore. > The label was there when I inserted it back, but zfs went for the da > device node anyway. > If I see this problem again, I will try to wipe the complete disk before > re-inserting it. It seems there is some kind of race condition with zfs either picking up the disk itself or the label device for the same disk. I guess it's which ever it probes first. I wrote the GPT part of glabel for using it in situations like this, I had not a single report of this kind of problem with the gpt labels. Maybe you can try them too? My zpool looks like this: % zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gpt/wd1 ONLINE 0 0 0 gpt/wd2 ONLINE 0 0 0 gpt/wd3 ONLINE 0 0 0 gpt/wd4 ONLINE 0 0 0 gpt/wd5 ONLINE 0 0 0 errors: No known data errors I already physically reordered the devices a few times and it always worked out correctly. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 09:29:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5739C106566C for ; Wed, 10 Feb 2010 09:29:16 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id D5F3D8FC19 for ; Wed, 10 Feb 2010 09:29:15 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1A9TDxU012229; Wed, 10 Feb 2010 10:29:14 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 2D10724; Wed, 10 Feb 2010 10:29:13 +0100 (CET) Date: Wed, 10 Feb 2010 10:29:13 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Marius =?ISO-8859-1?Q?N=FCnnerich?= Message-Id: <20100210102913.091f64ef.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> <54e63c321002091227w15657c54oeb2295efc4c43980@mail.gmail.com> <20100210092412.5a06d98e.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.10.91819 Cc: Elliot Finley , freebsd-stable@freebsd.org Subject: Re: zpool vdev vs. glabel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 09:29:16 -0000 On Wed, 10 Feb 2010 10:18:49 +0100 Marius N=FCnnerich wrote about Re: zpool vdev vs. glabel: MN> It seems there is some kind of race condition with zfs either picking MN> up the disk itself or the label device for the same disk. I guess it's MN> which ever it probes first. This could explain it. However, it seems that zfs sticks to the da device once it changed it's mind. Meanwhile I discovered one more system where is obviously has happened (although I cannot say when: luna# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 label/disk-1 ONLINE 0 0 0 da0 ONLINE 0 0 0 label/disk-2 ONLINE 0 0 0 label/disk-3 ONLINE 0 0 0 errors: No known data errors MN> I wrote the GPT part of glabel for using MN> it in situations like this, I had not a single report of this kind of MN> problem with the gpt labels. Maybe you can try them too? Yeah, I just have to look into how gpt labels work. I did not use them at all up to now. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 10:11:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11E39106566C for ; Wed, 10 Feb 2010 10:11:51 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from authsmtp.rrzn.uni-hannover.de (authsmtp.rrzn.uni-hannover.de [130.75.2.107]) by mx1.freebsd.org (Postfix) with ESMTP id 92B5B8FC0C for ; Wed, 10 Feb 2010 10:11:50 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by authsmtp.rrzn.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1A9qQa5017771 for ; Wed, 10 Feb 2010 10:52:27 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id AB62324 for ; Wed, 10 Feb 2010 10:52:26 +0100 (CET) Date: Wed, 10 Feb 2010 10:52:26 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-stable@freebsd.org Message-Id: <20100210105226.5c825b48.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.10.94226 Subject: bugs in mpt(4) and mptutil(8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 10:11:51 -0000 Hi, I have 2 8port cards with lsi chips installed in one machine that are driven by mpt(4). I see about the same problem (I think) when disconnecting disks as described here: When I simply pull a disk (without offlineing it first), zfs does not notice it (is still listed as "online") and I get lots of mpt1: mpt_cam_event: 0x16 mpt1: mpt_cam_event: 0x12 mpt1: mpt_cam_event: 0x16 mpt1: mpt_cam_event: 0x16 mpt1: mpt_cam_event: 0x16 mpt1: request 0xffffff80005e0bf0:2419 timed out for ccb 0xffffff0005802800 (req->ccb 0xffffff0005802800) mpt1: attempting to abort req 0xffffff80005e0bf0:2419 function 0 mpt1: completing timedout/aborted req 0xffffff80005e0bf0:2419 mpt1: abort of req 0xffffff80005e0bf0:0 completed mpt1: request 0xffffff80005dc000:2810 timed out for ccb 0xffffff000fa66800 (req->ccb 0xffffff000fa66800) mpt1: request 0xffffff80005dc3f0:2811 timed out for ccb 0xffffff0005802800 (req->ccb 0xffffff0005802800) mpt1: attempting to abort req 0xffffff80005dc000:2810 function 0 mpt1: completing timedout/aborted req 0xffffff80005dc3f0:2811 mpt1: completing timedout/aborted req 0xffffff80005dc000:2810 [...goes on for ages...] I don't know if this would ever stop. It ceased when I put the disk back in. In the thread above it is mentioned that there are some fixes for mpt (4) in -current to try out. However, I do not want to run -current on this machine. So, does anyone here know how the chances are that the mentioned patches are MFCed soon? One more thing I noticed is that mptutil does not play well with my controllers: pigpen# mptutil show adapter mpt0 Adapter: Board Name: USASLP-L8i Board Assembly: USASLP-L8i Chip Name: C1068E Chip Revision: B3 RAID Levels: none mptutil: Reading config page header failed: Invalid configuration page I don't know if it terminates because it cannot read the config page or if it is not able to see the second card. However: pigpen# mptutil show drives mpt0 Physical Drives: da0 ( 466G) ONLINE SATA bus 0 id 0 da1 ( 466G) ONLINE SATA bus 0 id 1 da6 ( 466G) ONLINE SATA bus 0 id 2 da11 ( 466G) ONLINE SATA bus 0 id 3 da3 ( 466G) ONLINE SATA bus 0 id 0 da4 ( 466G) ONLINE SATA bus 0 id 1 da5 ( 466G) ONLINE SATA bus 0 id 2 da2 ( 75G) ONLINE SATA bus 0 id 3 da7 ( 75G) ONLINE SATA bus 0 id 4 da8 ( 466G) ONLINE SATA bus 0 id 5 da9 ( 466G) ONLINE SATA bus 0 id 6 da10 ( 466G) ONLINE SATA bus 0 id 7 da12 ( 3824M) ONLINE SCSI-0 bus 0 id 0 This output is definitely wrong, because the drives are split up on mpt0 and mpt1 (and the USB stick is not connected to mpt at all :-) as can be seen with camcontrol: pigpen# camcontrol devlist at scbus0 target 0 lun 0 (da0,pass0) at scbus0 target 1 lun 0 (da1,pass1) at scbus0 target 2 lun 0 (pass6,da6) at scbus0 target 3 lun 0 (pass11,da11) at scbus1 target 0 lun 0 (da3,pass3) at scbus1 target 1 lun 0 (da4,pass4) at scbus1 target 2 lun 0 (da5,pass5) at scbus1 target 3 lun 0 (pass2,da2) at scbus1 target 4 lun 0 (da7,pass7) at scbus1 target 5 lun 0 (da8,pass8) at scbus1 target 6 lun 0 (da9,pass9) at scbus1 target 7 lun 0 (da10,pass10) at scbus2 target 0 lun 0 (pass12,da12) cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 10:40:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF285106566B for ; Wed, 10 Feb 2010 10:40:01 +0000 (UTC) (envelope-from pdegoeje@service2media.com) Received: from s2m-is-001.service2media.com (rev-130-102.virtu.nl [217.114.102.130]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB628FC1A for ; Wed, 10 Feb 2010 10:39:59 +0000 (UTC) Received: from pieter-dev-linux.localnet ([10.0.1.3] RDNS failed) by s2m-is-001.service2media.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 11:27:53 +0100 From: Pieter de Goeje Organization: Service2Media To: freebsd-stable@freebsd.org Date: Wed, 10 Feb 2010 11:27:53 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-19-generic; KDE/4.3.2; i686; ; ) References: <4B6F9A8D.4050907@langille.org> <4B718EBB.6080709@acm.poly.edu> <4B723609.8010802@langille.org> In-Reply-To: <4B723609.8010802@langille.org> MIME-Version: 1.0 Message-Id: <201002101127.53444.pieter@service2media.com> X-OriginalArrivalTime: 10 Feb 2010 10:27:53.0680 (UTC) FILETIME=[B4375D00:01CAAA3B] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Peter C. Lai" , Charles Sprickman , Boris Kochergin , Dan Langille Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 10:40:01 -0000 On Wednesday 10 February 2010 05:28:57 Dan Langille wrote: > Boris Kochergin wrote: > > Peter C. Lai wrote: > >> On 2010-02-09 06:37:47AM -0500, Dan Langille wrote: > >>> Charles Sprickman wrote: > >>>> On Mon, 8 Feb 2010, Dan Langille wrote: > >>>> Also, it seems like > >>>> people who use zfs (or gmirror + gstripe) generally end up buying > >>>> pricey hardware raid cards for compatibility reasons. There seem to > >>>> be no decent add-on SATA cards that play nice with FreeBSD other > >>>> than that weird supermicro card that has to be physically hacked > >>>> about to fit. > >> > >> Mostly only because certain cards have issues w/shoddy JBOD > >> implementation. Some cards (most notably ones like Adaptec 2610A which > >> was rebranded by Dell as the "CERC SATA 1.5/6ch" back in the day) > >> won't let you run the drives in passthrough mode and seem to all want > >> to stick their grubby little RAID paws into your JBOD setup (i.e. the > >> only way to have minimal > >> participation from the "hardware" RAID is to set each disk as its own > >> RAID-0/volume in the controller BIOS) which then cascades into issues > >> with SMART, AHCI, "triple caching"/write reordering, etc on the > >> FreeBSD side (the controller's own craptastic cache, ZFS vdev cache, > >> vmm/app cache, oh my!). So *some* people go with something > >> tried-and-true (basically bordering on server-level cards that let you > >> ditch any BIOS type of RAID config and present the raw disk devices to > >> the kernel) > > > > As someone else has mentioned, recent SiL stuff works well. I have > > multiple http://www.newegg.com/Product/Product.aspx?Item=3DN82E16816132= 008 > > cards servicing RAID-Z2 and GEOM_RAID3 arrays on 8.0-RELEASE and > > 8.0-STABLE machines using both the old ata(4) driver and ATA_CAM. Don't > > let the RAID label scare you--that stuff is off by default and the > > controller just presents the disks to the operating system. Hot swap > > works. I haven't had the time to try the siis(4) driver for them, which > > would result in better performance. >=20 > That's a really good price. :) >=20 > If needed, I could host all eight SATA drives for $160, much cheaper > than any of the other RAID cards I've seen. >=20 > The issue then is finding a motherboard which has 4x PCI Express slots. = ;) You should be able to put PCIe 4x card in a PCIe 16x or 8x slot.=20 =46or an explanation allow me to quote wikipedia: "A PCIe card will fit into a slot of its physical size or bigger, but may n= ot=20 fit into a smaller PCIe slot. Some slots use open-ended sockets to permit=20 physically longer cards and will negotiate the best available electrical=20 connection. The number of lanes actually connected to a slot may also be le= ss=20 than the number supported by the physical slot size. An example is a x8 slo= t=20 that actually only runs at =C3=971; these slots will allow any =C3=971, =C3= =972, =C3=974 or =C3=978=20 card to be used, though only running at the =C3=971 speed. This type of soc= ket is=20 described as a =C3=978 (=C3=971 mode) slot, meaning it physically accepts u= p to =C3=978 cards=20 but only runs at =C3=971 speed. The advantage gained is that a larger range= of PCIe=20 cards can still be used without requiring the motherboard hardware to suppo= rt=20 the full transfer rate=E2=80=94in so doing keeping design and implementatio= n costs=20 down." =2D- Pieter From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 10:46:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E21D1065670 for ; Wed, 10 Feb 2010 10:46:18 +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 EE7AB8FC16 for ; Wed, 10 Feb 2010 10:46:17 +0000 (UTC) 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 <1NfA5I-0003qr-Mm>; Wed, 10 Feb 2010 11:46:16 +0100 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 <1NfA5I-0004b3-L1>; Wed, 10 Feb 2010 11:46:16 +0100 Message-ID: <4B728ED3.7040309@zedat.fu-berlin.de> Date: Wed, 10 Feb 2010 10:47:47 +0000 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100206 Thunderbird/3.0.1 MIME-Version: 1.0 To: Warren Block References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B71FFA8.3070306@mail.zedat.fu-berlin.de> <201002100202.59954.christof.schulze@gmx.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Christof Schulze , freebsd-stable@freebsd.org Subject: Re: freebsd7, radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 10:46:18 -0000 On 02/10/10 03:41, Warren Block wrote: > On Wed, 10 Feb 2010, Christof Schulze wrote: > >>> The situation is heavily unsatisfying, since one need an expensive >>> AMD/ATi Radeon card to gain non-3D poor functionality, where a cheaper >>> one should be do the same - but the cheaper ones don't work. Even if >>> one >>> uses AMD64, the situattion is worse and I have no reason using >>> Linux-driver on a FreeBSD box. Hope the situation gets cleared in the >>> nearest future. It's a kind of deadlock. As I said, either spenig a lot >>> of money for a working RV770 based AMD graphics card with poor >>> functionality or nothing so far, since most smaller RV730 chips aren't >>> supported properly by the most recent drivers. >> To be fair - my ATI X300 has always worked. It is a cheap card with >> low-end >> performance but it is perfectly fine for regular desktop-use. > > The older chipsets are better supported because the newer ones are, > well, newer. If you haven't bought a video card yet, look at the > radeon(4x) man page first. > > Unfortunately, that doesn't help if you already have a newer card, or > a notebook. > > The other choices are Intel, where they don't have standalone video > cards, or nVidia, which has a full-featured blob and a really > bare-bones open driver. > > -Warren Block * Rapid City, South Dakota USA You said it. Alternatives? Barely. Having Intel-X58 based mainboards for our workstations, there is no onboard-Intel solution. Speaking of nVidia - 64Bit FreeBSD-support isn't mature and, as far as I know, not yet arrived, but underway, but this is in the future and isn't subject of any consideration if I need to make my choices now. Our department orders, in most cases, a bunch of systems completely equipted also with graphics boards. In many cases, there is no reason, economically, buying outdated graphics boards which are 5 years old and older, despite the fact that many shops do not offer them. On Linux, most of those modern ATi/AMD video cards not working with X11 on FreeBSD/amd64 work on Linux due to the fact most Linux derivates have a more modern OpenSource Xorg environment, including 'cutting' edge DRI and drivers. The alternative is to play with the well supported 32- and 64-Bit blob even AMD/ATi offers for Linux. Regards, Oliver From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 10:46:40 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F0331065692; Wed, 10 Feb 2010 10:46:40 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 6EEAB8FC0C; Wed, 10 Feb 2010 10:46:39 +0000 (UTC) Received: by fxm24 with SMTP id 24so230768fxm.3 for ; Wed, 10 Feb 2010 02:46:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=UwMvXOYe1Vnp+5/WvVNVV4sUZFjaMchpbXwzRs8zL3Y=; b=v3EW/L117Fe6dUU7R5WnC9sjIDCDUgwFg6C8DUaU+qf4C+r47iaDc3OdI9qvki6HD/ 7hgCV+18sFVw55Vj3ETvBUjpvdE6ApV7y2RMWOaXhwjwNtH6SjpPBdsMxiOt31deyJ5X PLD84tfo41SJqu1il/EAh77nKe530u1CHAUBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=itr398SrsG09RYvlfZGUOvLap+knV6tWAULBpxEkptPdJ9M60XZIYJM9ncF4amn4PG oWO0d86R91GEUKFRQzDImx48wBXJ43BJW3yn4F6I946EH+5iZIfAcT1zdMwtBml6gJkw 7kEClLGul/4ft+j5zcc0EMHU9ct8bI4KcTC3s= Received: by 10.87.55.18 with SMTP id h18mr2570509fgk.65.1265797401117; Wed, 10 Feb 2010 02:23:21 -0800 (PST) Received: from ?192.168.1.57? (195-248-173-117.static.vega-ua.net [195.248.173.117]) by mx.google.com with ESMTPS id 16sm520357fxm.12.2010.02.10.02.23.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Feb 2010 02:23:20 -0800 (PST) Message-ID: <4B728A7A.60706@gmail.com> Date: Wed, 10 Feb 2010 12:29:14 +0200 From: Vitaly Magerya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Oliver Pinter References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> In-Reply-To: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, x11@FreeBSD.org, freebsd-x11@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 10:46:40 -0000 Oliver Pinter wrote: > After updated the xorg* and dri* and dependency, the system going to > deadlock at second start of xserver. I think it is not an uniqe issue, > as others wrote them at freebsd-x11: > http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html I have a similar problem with ATI Mobility Radeon 9000 (r250) and FreeBSD 8.0-RELEASE-p2 i386 (dmesg is at [1]). The system hangs when I run Xorg with xorg.conf obtained by `Xorg -configure' and do either of these: * pkill Xorg * close xorg via ^C and start it again * close xorg via ^C and kldunload radeon I did not try using 'option "DRI" "OFF"' though, I will this evening. Unfortunately I can't currently say if it works under different conditions, since after a number of hangs I switched to VESA. But if anyone is interested, I'll investigate further and will provide any additional information -- just name it. [1] http://tx97.net/~magv/dmesg-t40.80-p2.txt From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 10:49:12 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28B2710656BD for ; Wed, 10 Feb 2010 10:49:12 +0000 (UTC) (envelope-from ru@FreeBSD.org) Received: from mail.vega.ru (mail.vega.ru [90.156.167.5]) by mx1.freebsd.org (Postfix) with ESMTP id DA51C8FC08 for ; Wed, 10 Feb 2010 10:49:11 +0000 (UTC) Received: from [10.100.124.99] (helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NfA86-0006qT-A3 for stable@freebsd.org; Wed, 10 Feb 2010 13:49:10 +0300 Date: Wed, 10 Feb 2010 13:49:05 +0300 From: Ruslan Ermilov To: stable@freebsd.org Message-ID: <20100210104904.GA85373@edoofus.dev.vega.ru> References: <20100210085814.GE9748@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100210085814.GE9748@acme.spoerlein.net> Cc: Subject: Re: numeric sort(1) is broken on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 10:49:12 -0000 On Wed, Feb 10, 2010 at 09:58:14AM +0100, Ulrich Spörlein wrote: > Hi guys, > > not sure if this is a pilot error, but it seems to me that gnu sort -n > is broken on at least -STABLE (couldn't test -CURRENT yet). > > It somehow does not manifest when using a simple list and sorting on a > specific column, but it always happens to me when using it in > combination with find(1). > > % truncate -s10m a; truncate -s5m b; truncate -s800k c > % find a b c -ls|sort -nk7,7 > 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a > 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b > 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c I bet you're using some non-C locale for LC_NUMERIC. What does "locale" output tell you? > % find a b c -ls|sort -gk7,7 > 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c > 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b > 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a > > at least -g does what is expected and I can work around this for the time being. Here's bsdsort > > % find a b c -ls|bsdsort -nk7,7 > 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c > 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b > 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a > > and this is on Solaris 8 > > % find a b c -ls|sort -nk7,7 > 546728 16 -rw-r--r-- 1 spoerul xxx 819200 Feb 10 09:49 c > 546727 16 -rw-r--r-- 1 spoerul xxx 5242880 Feb 10 09:48 b > 546724 16 -rw-r--r-- 1 spoerul xxx 10485760 Feb 10 09:48 a > > It even occured to me, that we don't have a sort regression suite under > tools/regression. Anyone know a place to find one with a suitable license? > > Regards, > Uli > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 10:55:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01C231065692 for ; Wed, 10 Feb 2010 10:55:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id DBDDF8FC17 for ; Wed, 10 Feb 2010 10:55:17 +0000 (UTC) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta05.emeryville.ca.mail.comcast.net with comcast id gAux1d0020mlR8UA5AvJ5R; Wed, 10 Feb 2010 10:55:18 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta11.emeryville.ca.mail.comcast.net with comcast id gAvH1d0033S48mS8XAvHBC; Wed, 10 Feb 2010 10:55:18 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 506C31E3033; Wed, 10 Feb 2010 02:55:16 -0800 (PST) Date: Wed, 10 Feb 2010 02:55:16 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100210105516.GA65506@icarus.home.lan> References: <4B6F9A8D.4050907@langille.org> <4B718EBB.6080709@acm.poly.edu> <4B723609.8010802@langille.org> <201002101127.53444.pieter@service2media.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201002101127.53444.pieter@service2media.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 10:55:18 -0000 On Wed, Feb 10, 2010 at 11:27:53AM +0100, Pieter de Goeje wrote: > On Wednesday 10 February 2010 05:28:57 Dan Langille wrote: > > Boris Kochergin wrote: > > > Peter C. Lai wrote: > > >> On 2010-02-09 06:37:47AM -0500, Dan Langille wrote: > > >>> Charles Sprickman wrote: > > >>>> On Mon, 8 Feb 2010, Dan Langille wrote: > > >>>> Also, it seems like > > >>>> people who use zfs (or gmirror + gstripe) generally end up buying > > >>>> pricey hardware raid cards for compatibility reasons. There seem to > > >>>> be no decent add-on SATA cards that play nice with FreeBSD other > > >>>> than that weird supermicro card that has to be physically hacked > > >>>> about to fit. > > >> > > >> Mostly only because certain cards have issues w/shoddy JBOD > > >> implementation. Some cards (most notably ones like Adaptec 2610A which > > >> was rebranded by Dell as the "CERC SATA 1.5/6ch" back in the day) > > >> won't let you run the drives in passthrough mode and seem to all want > > >> to stick their grubby little RAID paws into your JBOD setup (i.e. the > > >> only way to have minimal > > >> participation from the "hardware" RAID is to set each disk as its own > > >> RAID-0/volume in the controller BIOS) which then cascades into issues > > >> with SMART, AHCI, "triple caching"/write reordering, etc on the > > >> FreeBSD side (the controller's own craptastic cache, ZFS vdev cache, > > >> vmm/app cache, oh my!). So *some* people go with something > > >> tried-and-true (basically bordering on server-level cards that let you > > >> ditch any BIOS type of RAID config and present the raw disk devices to > > >> the kernel) > > > > > > As someone else has mentioned, recent SiL stuff works well. I have > > > multiple http://www.newegg.com/Product/Product.aspx?Item=N82E16816132008 > > > cards servicing RAID-Z2 and GEOM_RAID3 arrays on 8.0-RELEASE and > > > 8.0-STABLE machines using both the old ata(4) driver and ATA_CAM. Don't > > > let the RAID label scare you--that stuff is off by default and the > > > controller just presents the disks to the operating system. Hot swap > > > works. I haven't had the time to try the siis(4) driver for them, which > > > would result in better performance. > > > > That's a really good price. :) > > > > If needed, I could host all eight SATA drives for $160, much cheaper > > than any of the other RAID cards I've seen. > > > > The issue then is finding a motherboard which has 4x PCI Express slots. ;) > > You should be able to put PCIe 4x card in a PCIe 16x or 8x slot. > For an explanation allow me to quote wikipedia: > > "A PCIe card will fit into a slot of its physical size or bigger, but may not > fit into a smaller PCIe slot. Some slots use open-ended sockets to permit > physically longer cards and will negotiate the best available electrical > connection. The number of lanes actually connected to a slot may also be less > than the number supported by the physical slot size. An example is a x8 slot > that actually only runs at ×1; these slots will allow any ×1, ×2, ×4 or ×8 > card to be used, though only running at the ×1 speed. This type of socket is > described as a ×8 (×1 mode) slot, meaning it physically accepts up to ×8 cards > but only runs at ×1 speed. The advantage gained is that a larger range of PCIe > cards can still be used without requiring the motherboard hardware to support > the full transfer rate???in so doing keeping design and implementation costs > down." Correction -- more than likely on a consumer motherboard you *will not* be able to put a non-VGA card into the PCIe x16 slot. I have numerous Asus and Gigabyte motherboards which only accept graphics cards in their PCIe x16 slots; this """feature""" is documented in user manuals. I don't know how/why these companies chose to do this, but whatever. I would strongly advocate that the OP (who has stated he's focusing on stability and reliability over speed) purchase a server motherboard that has a PCIe x8 slot on it and/or server chassis (usually best to buy both of these things from the same vendor) and be done with it. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 11:06:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48997106566C for ; Wed, 10 Feb 2010 11:06:37 +0000 (UTC) (envelope-from andrej@antiszoc.hu) Received: from mail.deployis.eu (mail.deployis.eu [217.20.135.253]) by mx1.freebsd.org (Postfix) with ESMTP id CEC4F8FC17 for ; Wed, 10 Feb 2010 11:06:36 +0000 (UTC) Received: from localhost ([127.0.0.1]:51693 helo=mail.deployis.eu) by mail.deployis.eu with esmtp (Exim 4.69 #1 (Debian)) id 1NfAOw-0005KM-J2 from ; Wed, 10 Feb 2010 12:06:35 +0100 Received: from 80.95.75.131 (SquirrelMail authenticated user andrej@antiszoc.hu) by mail.deployis.eu with HTTP; Wed, 10 Feb 2010 12:06:34 +0100 (CET) Message-ID: <64053.80.95.75.131.1265799994.squirrel@mail.deployis.eu> In-Reply-To: <20100210105516.GA65506@icarus.home.lan> References: <4B6F9A8D.4050907@langille.org> <4B718EBB.6080709@acm.poly.edu> <4B723609.8010802@langille.org> <201002101127.53444.pieter@service2media.com> <20100210105516.GA65506@icarus.home.lan> Date: Wed, 10 Feb 2010 12:06:34 +0100 (CET) From: =?iso-8859-2?Q?G=F3t_Andr=E1s?= To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Spam-Score-deployiseu: -3 Cc: Jeremy Chadwick Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 11:06:37 -0000 On Sze, Február 10, 2010 11:55 am, Jeremy Chadwick wrote: > On Wed, Feb 10, 2010 at 11:27:53AM +0100, Pieter de Goeje wrote: > >> On Wednesday 10 February 2010 05:28:57 Dan Langille wrote: >> >>> Boris Kochergin wrote: >>> >>>> Peter C. Lai wrote: >>>> >>>>> On 2010-02-09 06:37:47AM -0500, Dan Langille wrote: >>>>> >>>>>> Charles Sprickman wrote: >>>>>> >>>>>>> On Mon, 8 Feb 2010, Dan Langille wrote: >>>>>>> Also, it seems like >>>>>>> people who use zfs (or gmirror + gstripe) generally end up >>>>>>> buying pricey hardware raid cards for compatibility reasons. >>>>>>> There seem to >>>>>>> be no decent add-on SATA cards that play nice with FreeBSD >>>>>>> other than that weird supermicro card that has to be >>>>>>> physically hacked about to fit. >>>>> >>>>> Mostly only because certain cards have issues w/shoddy JBOD >>>>> implementation. Some cards (most notably ones like Adaptec 2610A >>>>> which was rebranded by Dell as the "CERC SATA 1.5/6ch" back in the >>>>> day) won't let you run the drives in passthrough mode and seem to >>>>> all want to stick their grubby little RAID paws into your JBOD >>>>> setup (i.e. the only way to have minimal participation from the >>>>> "hardware" RAID is to set each disk as its own >>>>> RAID-0/volume in the controller BIOS) which then cascades into >>>>> issues with SMART, AHCI, "triple caching"/write reordering, etc on >>>>> the FreeBSD side (the controller's own craptastic cache, ZFS vdev >>>>> cache, vmm/app cache, oh my!). So *some* people go with something >>>>> tried-and-true (basically bordering on server-level cards that >>>>> let you ditch any BIOS type of RAID config and present the raw >>>>> disk devices to the kernel) >>>> >>>> As someone else has mentioned, recent SiL stuff works well. I have >>>> multiple >>>> http://www.newegg.com/Product/Product.aspx?Item=N82E16816132008 >>>> cards servicing RAID-Z2 and GEOM_RAID3 arrays on 8.0-RELEASE and >>>> 8.0-STABLE machines using both the old ata(4) driver and ATA_CAM. >>>> Don't >>>> let the RAID label scare you--that stuff is off by default and the >>>> controller just presents the disks to the operating system. Hot >>>> swap works. I haven't had the time to try the siis(4) driver for >>>> them, which would result in better performance. >>> >>> That's a really good price. :) >>> >>> >>> If needed, I could host all eight SATA drives for $160, much cheaper >>> than any of the other RAID cards I've seen. >>> >>> The issue then is finding a motherboard which has 4x PCI Express >>> slots. ;) >> >> You should be able to put PCIe 4x card in a PCIe 16x or 8x slot. >> For an explanation allow me to quote wikipedia: >> >> >> "A PCIe card will fit into a slot of its physical size or bigger, but >> may not fit into a smaller PCIe slot. Some slots use open-ended sockets >> to permit physically longer cards and will negotiate the best available >> electrical connection. The number of lanes actually connected to a slot >> may also be less than the number supported by the physical slot size. An >> example is a x8 slot that actually only runs at ×1; these slots will >> allow any ×1, ×2, ×4 or ×8 card to be used, though only running at the >> ×1 speed. This type of socket is >> described as a ×8 (×1 mode) slot, meaning it physically accepts up to ×8 >> cards but only runs at ×1 speed. The advantage gained is that a larger >> range of PCIe cards can still be used without requiring the motherboard >> hardware to support the full transfer rate???in so doing keeping design >> and implementation costs down." > > Correction -- more than likely on a consumer motherboard you *will not* > be able to put a non-VGA card into the PCIe x16 slot. I have numerous Asus > and Gigabyte motherboards which only accept graphics cards in their PCIe > x16 slots; this """feature""" is documented in user manuals. I don't know > how/why these companies chose to do this, but whatever. > > I would strongly advocate that the OP (who has stated he's focusing on > stability and reliability over speed) purchase a server motherboard that > has a PCIe x8 slot on it and/or server chassis (usually best to buy both > of these things from the same vendor) and be done with it. Hi, We're running an 'old' LSI U320 x4 (or x8) PCIe hw raid card in a simple Gigabyte mobo without any problems. It was plug and play. The mobo has some P35 chipset and an E7400 CPU. If the exact types needed I'll look after them. (And yes, the good old U320 scsi is lightning fast compared to any new SATA drives and only 3x36GB disks are in raid5. I know that it won't win the capacity contest... :) ) I think these single cpu server boards are quite overpriced regarding to the few extra features that would make some to buy them. Anyway, I liked that Atom D510 supermicro mobo that was mentioned earlier. I think it would handle any good PCIe cards and would fit in a nice Supermicro tower. I'd also suggest to with as less disk as you can. 2TB disks are here so you can make a 4TB R5 aray with only 3 and you power bill won't wipe out your bank account. Regards, Andras Got From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 11:35:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BED5B106566B for ; Wed, 10 Feb 2010 11:35:17 +0000 (UTC) (envelope-from rgrover1@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 9035F8FC0A for ; Wed, 10 Feb 2010 11:35:17 +0000 (UTC) Received: by pzk40 with SMTP id 40so207070pzk.7 for ; Wed, 10 Feb 2010 03:35:17 -0800 (PST) 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=ww9ZBXuJex0A+F/9irCdYCdwgGjnmRthWAN8sKNat7k=; b=af56Ms0mGDTEkVPh4XTKWi8LLzeqeKGU1h2ltHJH8eNjEZiFROI2b05mJPVFXEK8hz IBd1KO0+9oWN9dO6P39ZvNVHl1RoK2u9kr6u4XoK1PE/H1sij26PoKXDJIy+R0qbcHx6 xUdSjq3qutWRqemwamJ4XvGXk1paRjut2eFfw= 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=smuCM/AX/K4XBPEFwuJnDVo5o+ygfgGMbtUv2N0glumBvXY5QTutItbPVo+4v8mTet lhoLidgs1KJ2HLOucnGDvRm8XbQ/kPRJIKePQLJ4UoMRTo6yiMk0blONCT51gAj4k8Gj UKgRdC9qNr7FewCQJFGJm7xxjmPs/CDqsduM8= MIME-Version: 1.0 Received: by 10.141.23.12 with SMTP id a12mr50599rvj.161.1265801716911; Wed, 10 Feb 2010 03:35:16 -0800 (PST) In-Reply-To: References: <426bed111002080049u16354c87pd4fb8830e0542972@mail.gmail.com> <20100208114734.GA99245@icarus.home.lan> <426bed111002091752g1cf96cd0qf7be5098ab5c9742@mail.gmail.com> Date: Wed, 10 Feb 2010 17:05:16 +0530 Message-ID: <426bed111002100335x538a14bbo38f511566fe05fb2@mail.gmail.com> From: Rohit Grover To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Jeremy Chadwick , utisoft@gmail.com Subject: Re: Unresponsive keyboard after a few boots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 11:35:17 -0000 Thanks for replying. I would like to pursue this problem. I have verified that this problem doesn't happen with 8.0/RELEASE, and there are some improvements in 8.0/STABLE which I need, so it is very important for me to be able to use the latest 8.0/STABLE. > My opinion is that MacOSX is initializing some circuit areas but FreeBSD = 8.0 > is NOT touching in those areas . Therefore , initialization values from > MacOSX are remaining in place and FreeBSD 8.0 is using those values witho= ut > changing them . > > This idea is a pure guess , but > =A0when FreeBSD 8.0 starts initially and USB key board does not work , th= ere > seems that this is most likely possibility . > > If it is possible the following steps may be useful : > > Initially start MacOSX , dump all of the related circuit register values = . How do I dump the keyboard circuit register values for MacOSX and FreeBSD? thanks. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 12:04:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAAB7106566C for ; Wed, 10 Feb 2010 12:04:50 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 0F4148FC0C for ; Wed, 10 Feb 2010 12:04:49 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o1AC4mZd049479; Wed, 10 Feb 2010 14:04:48 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B72A0DB.5010806@eng.auth.gr> Date: Wed, 10 Feb 2010 14:04:43 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-doc@freebsd.org, freebsd-stable Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: A more secure approach of jail establishment. It could be included in jail chapter of fbsd handbook X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 12:04:50 -0000 Dear all, After working with jails for a long time, I ended up with a quite different approach (architecture) of setting up jails, that seems more secure than the one proposed in the freebsd handbook. The concept is very similar to that of handbook's chapter 15.6.1, only it involves a few more concepts. I'll try to be descriptive and understandable. Instead of having the mroot directory (mounted ro) containing the base system, and the s directory containing the different configs of each different jail (mounted rw), I introduced one more directory, let's call it t. Now ls -la /jails/j/mroot gives: total 32 drwxr-xr-x 14 root wheel - 512 Sep 24 18:16 ./ drwxr-xr-x 10 root wheel - 512 Feb 10 13:17 ../ drwxr-xr-x 2 root wheel - 1024 Sep 24 17:56 bin/ drwxr-xr-x 7 root wheel - 512 Sep 24 17:56 boot/ dr-xr-xr-x 2 root wheel - 512 Sep 24 17:56 dev/ lrwxr-xr-x 1 root wheel - 5 Sep 24 18:15 etc@ -> s/etc drwxr-xr-x 3 root wheel - 1536 Sep 24 17:56 lib/ drwxr-xr-x 2 root wheel - 512 Sep 24 17:57 libexec/ drwxr-xr-x 2 root wheel - 512 Sep 24 17:56 media/ dr-xr-xr-x 2 root wheel - 512 Sep 24 17:56 proc/ drwxr-xr-x 2 root wheel - 2560 Sep 24 17:56 rescue/ lrwxr-xr-x 1 root wheel - 6 Sep 24 18:15 root@ -> s/root drwxr-xr-x 2 root wheel - 512 Sep 24 18:14 s/ drwxr-xr-x 2 root wheel - 2560 Sep 24 17:57 sbin/ lrwxr-xr-x 1 root wheel - 11 Sep 24 17:56 sys@ -> usr/src/sys drwxr-xr-x 2 root wheel - 512 Sep 24 18:14 t/ lrwxr-xr-x 1 root wheel - 5 Sep 24 18:15 tmp@ -> t/tmp drwxr-xr-x 14 root wheel - 512 Sep 24 18:50 usr/ lrwxr-xr-x 1 root wheel - 5 Sep 24 18:16 var@ -> t/var And ls -la /jails/j/mroot/usr gives: drwxr-xr-x 14 root wheel - 512 Sep 24 18:50 ./ drwxr-xr-x 14 root wheel - 512 Sep 24 18:16 ../ lrwxr-xr-x 1 root wheel - 15 Sep 24 18:15 X11R6@ -> ../s/usr/-X11R6 drwxr-xr-x 2 root wheel - 7168 Sep 24 17:57 bin/ drwxr-xr-x 2 root wheel - 512 Sep 24 17:56 games/ drwxr-xr-x 46 root wheel - 5120 Sep 24 17:56 include/ drwxr-xr-x 6 root wheel - 11776 Sep 24 17:57 lib/ drwxr-xr-x 3 root wheel - 12288 Sep 24 17:57 lib32/ drwxr-xr-x 5 root wheel - 512 Sep 24 17:56 libdata/ drwxr-xr-x 5 root wheel - 1536 Sep 24 17:57 libexec/ lrwxr-xr-x 1 root wheel - 14 Sep 24 18:15 local@ -> ../s/usr-local drwxr-xr-x 2 root wheel - 512 Sep 24 17:56 obj/ drwxr-xr-x 68 root wheel - 1536 Sep 24 18:50 ports/ drwxr-xr-x 2 root wheel - 5120 Sep 24 17:57 sbin/ drwxr-xr-x 25 root wheel - 512 Sep 24 17:56 share/ drwxr-xr-x 22 root wheel - 1024 Sep 24 18:14 src/ As we can see, only tmp and var is linked to t, while all other symlinks are the same with the configuration proposed in the handbook. The difference is the following: In my steup, s is mounted ro and t is mounted rw. In this way, jail's /etc is mounted ro, /usr/ is mounted ro, which means that /usr/local is mounted ro, which means that /s/portbuild is mounted read onlty, which means that /root is mounted read only, and so on... So, all ports installed on the system, and deamons running through /usr/local are now read only and trojaned versions of binaries are much more difficult to be installed if the jail is compromised. In order to be able to manage those jails, I did the following trick: # cat /etc/fstab /dev/da0s1a / ufs rw 1 1 /dev/da0s1b none swap sw 0 0 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 # Jails /jails/j/mroot /jails/j/bind nullfs ro 0 0 /jails/j/mroot /jails/j/heimdal nullfs ro 0 0 /jails/j/mroot /jails/j/ldap nullfs ro 0 0 /jails/s/ldap /jails/j/ldap/s nullfs ro 0 0 /jails/s/bind /jails/j/bind/s nullfs ro 0 0 /jails/s/heimdal /jails/j/heimdal/s nullfs ro 0 0 /jails/t/heimdal /jails/j/heimdal/t nullfs rw 0 0 /jails/t/bind /jails/j/bind/t nullfs rw 0 0 /jails/t/ldap /jails/j/ldap/t nullfs rw 0 0 # Manage jails /jails/j/mroot /jails/manage/bind nullfs rw 0 0 /jails/j/mroot /jails/manage/heimdal nullfs rw 0 0 /jails/j/mroot /jails/manage/ldap nullfs rw 0 0 /jails/s/ldap /jails/manage/ldap/s nullfs rw 0 0 /jails/s/bind /jails/manage/bind/s nullfs rw 0 0 /jails/s/heimdal /jails/manage/heimdal/s nullfs rw 0 0 /jails/t/heimdal /jails/manage/heimdal/t nullfs rw 0 0 /jails/t/bind /jails/manage/bind/t nullfs rw 0 0 /jails/t/ldap /jails/manage/ldap/t nullfs rw 0 0 devfs /jails/manage/heimdal/dev devfs rw 0 0 devfs /jails/manage/bind/dev devfs rw 0 0 devfs /jails/manage/ldap/dev devfs rw 0 0 In my setup I have three jails: ldap, heimdal and bind. mroot is monted in each jail's root folder, and the s and t directories of each jail are null_mounted on each jail's s and t folder respectively. I introduced another folder, /jails/manage which has the analogous usage to /jails/j folder, only this folder's subfolders are not used as jails. I chroot to each folder when I want to have write access on it's corresponding jail, and I can perform all my administrative operations (if you notice, even mroot is mounted rw in this chroot, so changes in base disto can be performed - eg when installing perl where you are asked to change /usr/bin/perl). This is the reason why I mount devfs on these chroots. As a result, with this setup, only /var and /tmp are mounted rw in each jail, and all other filesystems are mounted ro. Management (meaning jobs that require write access, not starting and/or stopping services) is achieved by chrooting to each jail's corresponding chroot. I am working with this setup for more than 4 months without having any problems; I thought that I could propose it as another paragraph in chapter 15.6 of freebsd handbook, as an even more secure jail setup, instead of just publishing it to some blog,forum,etc. Thank you all for your time. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 12:17:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED4EC106566B for ; Wed, 10 Feb 2010 12:17: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 B2A2F8FC1A for ; Wed, 10 Feb 2010 12:17:07 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1ACH470003690 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 07:17:05 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Warren Block In-Reply-To: References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B71FFA8.3070306@mail.zedat.fu-berlin.de> <201002100202.59954.christof.schulze@gmx.com> Content-Type: text/plain Organization: FreeBSD Date: Wed, 10 Feb 2010 06:16:59 -0600 Message-Id: <1265804219.8609.42.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Christof Schulze , freebsd-stable@freebsd.org Subject: Re: freebsd7, radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 12:17:08 -0000 On Tue, 2010-02-09 at 20:41 -0700, Warren Block wrote: > On Wed, 10 Feb 2010, Christof Schulze wrote: > > >> The situation is heavily unsatisfying, since one need an expensive > >> AMD/ATi Radeon card to gain non-3D poor functionality, where a cheaper > >> one should be do the same - but the cheaper ones don't work. Even if one > >> uses AMD64, the situattion is worse and I have no reason using > >> Linux-driver on a FreeBSD box. Hope the situation gets cleared in the > >> nearest future. It's a kind of deadlock. As I said, either spenig a lot > >> of money for a working RV770 based AMD graphics card with poor > >> functionality or nothing so far, since most smaller RV730 chips aren't > >> supported properly by the most recent drivers. > > To be fair - my ATI X300 has always worked. It is a cheap card with low-end > > performance but it is perfectly fine for regular desktop-use. > > The older chipsets are better supported because the newer ones are, > well, newer. If you haven't bought a video card yet, look at the > radeon(4x) man page first. radeon IS the best choice. They (amd) are reasonably supportive of our efforts, provide docs and code. Intel also does, but they are far less interested in supporting anything except linux with their latest and greatest code. As for older cards, as things change, the older cards get less and less testing and can sometimes have issues. I only have one AGP based radeon handy (8500DV), but for PCI-E, I have representations from every chip family, from x600 up to HD4650. Basically, r300, r500, r600. I do not have one of the IGP models, which are slightly different (rv480, rs690) but AFAIK, we resolved the issues with those chips and drm like a year ago. Warren and Adam Kirchof have also always been really good about providing testing on their fleet of radeons. A lockup without drm is almost certainly a GPU crash as there isn't any real kernel interaction. If you can ssh into the box and collect some info it might help to identify the issue. GPU crashes can be tricky to isolate though, since you really don't know where the instruction that is causing the issue is coming from. Dropping back to a really simple environment and slowly working forward to find out what triggers the issue is usually the best way. robert. > Unfortunately, that doesn't help if you already have a newer card, or a > notebook. > > The other choices are Intel, where they don't have standalone video > cards, or nVidia, which has a full-featured blob and a really bare-bones > open driver. > > -Warren Block * Rapid City, South Dakota USA > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 13:31:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 384021065676 for ; Wed, 10 Feb 2010 13:31:00 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id BAE048FC16 for ; Wed, 10 Feb 2010 13:30:59 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 3269819E027; Wed, 10 Feb 2010 14:30:58 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 1671119E019; Wed, 10 Feb 2010 14:30:55 +0100 (CET) Message-ID: <4B72B50E.1030301@quip.cz> Date: Wed, 10 Feb 2010 14:30:54 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.7) Gecko/20100104 SeaMonkey/2.0.2 MIME-Version: 1.0 To: "Svein Skogen (Listmail Account)" References: <4B6F9A8D.4050907@langille.org> <4B70FEEC.6070007@modulus.org> <20100209063310.GA23387@icarus.home.lan> <4B715AC6.5090500@denninger.net> <20100209134456.GA37029@icarus.home.lan> <4B717340.6080901@quip.cz> <4B717923.7050805@stillbilde.net> In-Reply-To: <4B717923.7050805@stillbilde.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage / remote management KVM card X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 13:31:00 -0000 Svein Skogen (Listmail Account) wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 09.02.2010 15:37, Miroslav Lachman wrote: > *SNIP* >> >> I can't agree with the last statement about HP's iLO. I have addon card >> in ML110 G5 (dedicated NIC), the card is "expensive" and bugs are >> amazing. The management NIC freezes once a day (or more often) with >> older firmware and must be restarted from inside the installed system by >> IPMI command on "localhost". With newer firmware, the interface is >> periodicaly restarded. The virtual media doesn't work at all. It is my >> worst experience with remote management cards. >> I believe that other HP servers with built-in card with different FW is >> working better, this is just my experience. >> >> Next one is eLOM in Sun Fire X2100 (shared NIC using bge + ASF). ASF >> works without problem, but virtual media works only if you are >> connecting by IP address, not by domain name (from Windows machines) and >> there is some issue with timeouts of virtual media / console. >> I reported this + 8 different bugs of web management interface to Sun >> more than year ago - none was fixed. >> >> Next place is for IBM 3650 + RSA II card (dedicated NIC). Expensive, >> something works, somthing not. For example the card can't read CPU >> temperature, so you will not recieve any alert in case of overheating. >> (it was 2 years ago, maybe newer firmware is fixed) >> >> Then I have one Supermicro Twin server 6016TT-TF with built-in IPMI / >> KVM with dedicated NIC port. I found one bug with fan rpm readings (half >> the number compared to BIOS numbers) and one problem with FreeBSD 7.x >> sysinstall (USB keyboard not working, but sysinstall from 8.x works >> without problem). In installed FreeBSD system keyboard and virtual media >> is working without problems. >> >> On the top is Dell R610 DRAC (dedicated NIC) - I didn't find any bugs >> and there are a lot more features compared to concurrent products. >> > > I think the general consensus here is "nice theory lousy > implementation", and the added migraine of no such thing as a common > standard. > > Maybe creating a common standard for this could be a nice GSOC project, > to build a nice "remote console" based on SSH and arm/mips? > > p.s. I've seen the various proprietary remote console solutions. They > didn't really impress me much, so I ended up using off-the-shelf > components for building my servers. Not necessarily cheaper, but at > least it's under _MY_ control. > > //Svein Does anybody have experiences with ATEN IP8000 card? I found it today http://www.aten.com/products/productItem.php?pcid=2006041110563001&psid=20060411131311002&pid=20080401180847001&layerid=subClass1 It is not cheap, but it seems as universal solution for any motherboard with PCI slot. "Host-side OS support - Windows 2000/2003/XP /NT/VistaRedhat 7.1 and above; FreeBSD, Novell" Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 13:33:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 651EF1065670; Wed, 10 Feb 2010 13:33:29 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id D9B028FC08; Wed, 10 Feb 2010 13:33:28 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o1ADXRGe019782; Wed, 10 Feb 2010 15:33:27 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B72B5A2.7000103@eng.auth.gr> Date: Wed, 10 Feb 2010 15:33:22 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: Igor Mozolevsky References: <4B72A0DB.5010806@eng.auth.gr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-doc@freebsd.org, freebsd-stable Subject: Re: A more secure approach of jail establishment. It could be included in jail chapter of fbsd handbook X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 13:33:29 -0000 On 10/02/2010 15:10, Igor Mozolevsky wrote: > alling a full blown OS inside their jails? > You do know that it is possible to have a jail with a single program > inside and not much els Yes I do, but still in my configs I may need much more than just one program running in my jails, so I prefer the almost-full-OS option. Moreover, I find it also easier to maintain and troubleshoot, no matter how peculiar this may sound, since I don't have to chose only the files needed in each jail when I upgrade them, and I am able to run terminals in the jail, along with other which makes troubleshooting the jail easier. Of course, this is just my opinion and I think it is more of a matter of "taste" on how someone would want to setup their jails. Thank you for your answer. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 13:36:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0D4B106566B; Wed, 10 Feb 2010 13:36:27 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 307118FC13; Wed, 10 Feb 2010 13:36:26 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 25so46122eya.9 for ; Wed, 10 Feb 2010 05:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=ALsHdcwnvNbX2JiojnFq896eLZzdeaFX4/2qRoov31o=; b=ss9otR+LE2Ai3w+rXFQ683BYoX92uwXJ5bkvmaxeYyQqdN3BZtBjE9RC+Mvny49Yxh QPQ7cxijJIrE2q7VLZr657HiNf6HVpDUZtRbuWRrLs6ASKlggWwoHwcSrmXVpd0+C1Yq XTqwVp2sqEX+oN8XHNdzqy0nlinezs13dB2gc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=wVRnm9YyPVzeC9y6VzHwqrWapTZYK49kPhYHVs+DcAc9M9zuNTnaE5Wfap/znP4Flg q6/tcoNBHCqoAbiMjn52s1qynWDcj3t/gLsWZzElhWshXxb5S7u8nuZqALpH8uLT7Yu9 x7tmzO1SVjbUNPUadqhkcaRf0afuLbLWTYFfU= MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.213.96.198 with SMTP id i6mr187795ebn.45.1265807471132; Wed, 10 Feb 2010 05:11:11 -0800 (PST) In-Reply-To: <4B72A0DB.5010806@eng.auth.gr> References: <4B72A0DB.5010806@eng.auth.gr> From: Igor Mozolevsky Date: Wed, 10 Feb 2010 13:10:32 +0000 X-Google-Sender-Auth: 54efd51ee877bb46 Message-ID: To: George Mamalakis Content-Type: text/plain; charset=UTF-8 Cc: freebsd-doc@freebsd.org, freebsd-stable Subject: Re: A more secure approach of jail establishment. It could be included in jail chapter of fbsd handbook X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 13:36:27 -0000 I see people are still installing a full blown OS inside their jails? You do know that it is possible to have a jail with a single program inside and not much else, as if it were chroot()ed? Cheers, Igor From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 13:51:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6353106566B for ; Wed, 10 Feb 2010 13:51:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id CA23D8FC1B for ; Wed, 10 Feb 2010 13:51:42 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta08.emeryville.ca.mail.comcast.net with comcast id gDPe1d0051Y3wxoA8DrjEe; Wed, 10 Feb 2010 13:51:43 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id gDri1d0093S48mS8bDri4Q; Wed, 10 Feb 2010 13:51:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7EE101E3033; Wed, 10 Feb 2010 05:51:41 -0800 (PST) Date: Wed, 10 Feb 2010 05:51:41 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100210135141.GA71364@icarus.home.lan> References: <4B6F9A8D.4050907@langille.org> <4B70FEEC.6070007@modulus.org> <20100209063310.GA23387@icarus.home.lan> <4B715AC6.5090500@denninger.net> <20100209134456.GA37029@icarus.home.lan> <4B717340.6080901@quip.cz> <4B717923.7050805@stillbilde.net> <4B72B50E.1030301@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B72B50E.1030301@quip.cz> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: hardware for home use large storage / remote management KVM card X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 13:51:44 -0000 On Wed, Feb 10, 2010 at 02:30:54PM +0100, Miroslav Lachman wrote: > Svein Skogen (Listmail Account) wrote: > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >On 09.02.2010 15:37, Miroslav Lachman wrote: > >*SNIP* > >> > >>I can't agree with the last statement about HP's iLO. I have addon card > >>in ML110 G5 (dedicated NIC), the card is "expensive" and bugs are > >>amazing. The management NIC freezes once a day (or more often) with > >>older firmware and must be restarted from inside the installed system by > >>IPMI command on "localhost". With newer firmware, the interface is > >>periodicaly restarded. The virtual media doesn't work at all. It is my > >>worst experience with remote management cards. > >>I believe that other HP servers with built-in card with different FW is > >>working better, this is just my experience. > >> > >>Next one is eLOM in Sun Fire X2100 (shared NIC using bge + ASF). ASF > >>works without problem, but virtual media works only if you are > >>connecting by IP address, not by domain name (from Windows machines) and > >>there is some issue with timeouts of virtual media / console. > >>I reported this + 8 different bugs of web management interface to Sun > >>more than year ago - none was fixed. > >> > >>Next place is for IBM 3650 + RSA II card (dedicated NIC). Expensive, > >>something works, somthing not. For example the card can't read CPU > >>temperature, so you will not recieve any alert in case of overheating. > >>(it was 2 years ago, maybe newer firmware is fixed) > >> > >>Then I have one Supermicro Twin server 6016TT-TF with built-in IPMI / > >>KVM with dedicated NIC port. I found one bug with fan rpm readings (half > >>the number compared to BIOS numbers) and one problem with FreeBSD 7.x > >>sysinstall (USB keyboard not working, but sysinstall from 8.x works > >>without problem). In installed FreeBSD system keyboard and virtual media > >>is working without problems. > >> > >>On the top is Dell R610 DRAC (dedicated NIC) - I didn't find any bugs > >>and there are a lot more features compared to concurrent products. > >> > > > >I think the general consensus here is "nice theory lousy > >implementation", and the added migraine of no such thing as a common > >standard. > > > >Maybe creating a common standard for this could be a nice GSOC project, > >to build a nice "remote console" based on SSH and arm/mips? > > > >p.s. I've seen the various proprietary remote console solutions. They > >didn't really impress me much, so I ended up using off-the-shelf > >components for building my servers. Not necessarily cheaper, but at > >least it's under _MY_ control. > > > >//Svein > > Does anybody have experiences with ATEN IP8000 card? > I found it today > http://www.aten.com/products/productItem.php?pcid=2006041110563001&psid=20060411131311002&pid=20080401180847001&layerid=subClass1 > > It is not cheap, but it seems as universal solution for any > motherboard with PCI slot. > > "Host-side OS support - Windows 2000/2003/XP > /NT/VistaRedhat 7.1 and above; FreeBSD, Novell" There's also the PC Weasel[1], which does VGA-to-serial and provides reset/power-cycle capability over the serial port. 100% OS-independent. The concept itself is really cool[2], but there's 3 major problems: 1) PCI version is 5V; some systems are limited to 3.3V PCI slots (see Wikipedia: http://en.wikipedia.org/wiki/File:PCI_Keying.png) -- not to mention lots of systems are doing away with PCI altogether (in servers especially) 2) Limited to 38400 bps throughput (I run serial consoles at 115200), 3) Very expensive -- US$350 *per card*. I'm surprised no one else has come up with a similar solution especially given the regularity of DSPs, CPLDs, and FPGAs in this day and age. [1]: http://www.realweasel.com/intro.html [2]: http://www.realweasel.com/design.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 13:54:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DACEF106571E; Wed, 10 Feb 2010 13:54:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9B0FC8FC18; Wed, 10 Feb 2010 13:54:04 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2C8EE46B53; Wed, 10 Feb 2010 08:54:04 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 102068A025; Wed, 10 Feb 2010 08:54:03 -0500 (EST) From: John Baldwin To: Tom McLaughlin Date: Wed, 10 Feb 2010 08:43:14 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B6B89E7.8030002@sdf.lonestar.org> <201002091723.44625.jhb@freebsd.org> <4B71FC5A.9080601@sdf.lonestar.org> In-Reply-To: <4B71FC5A.9080601@sdf.lonestar.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201002100843.14432.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 10 Feb 2010 08:54:03 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: kib@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Recent MFC to 7 causes crash on VMware ESXi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 13:54:04 -0000 On Tuesday 09 February 2010 7:22:50 pm Tom McLaughlin wrote: > John Baldwin wrote, On 02/09/2010 05:23 PM: > > On Tuesday 09 February 2010 5:17:32 pm Tom McLaughlin wrote: > >> John Baldwin wrote, On 02/09/2010 01:52 PM: > >>> On Monday 08 February 2010 9:49:00 am John Baldwin wrote: > >>>> On Saturday 06 February 2010 4:47:16 pm Tom McLaughlin wrote: > >>>>> John Baldwin wrote, On 02/05/2010 08:27 AM: > >>>>>> On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: > >>>>>>> Hi all, a recent MFC to 7-STABLE has started to cause issues for my > > VMs > >>>>>>> on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk > >>>>>>> controller the VM just shuts off. The workaround is to change the > > disk > >>>>>>> controller to the BusLogic type. Still, it used to work up until last > >>>>>>> week. The change was made around January 26th and based on the > > commits > >>>>>>> that day I'm guessing it's either r203047 or r203073 > >>>>>>> > >>>>>>> I have the same issue with both amd64 and i386 VMs. This affects HEAD > >>>>>>> and 8-STABLE as well and first affected HEAD over the summer. (I just > >>>>>>> worked around it and went about my business at the time. :-/) I've > >>>>>>> attached a dmesg from a kernel before the problem and one from after > > it > >>>>>>> started. > >>>>>> > >>>>>> What if you set 'hw.clfush_disable=1' from the loader? > >>>>>> > >>>>> > >>>>> Yes, that corrected it on all my VMs. I've talked to people on ESXi 4 > >>>>> and they do not see the problem. I have yet to try 3.5u5 to see if this > >>>>> is a non-issue. 3.5 will be supported for awhile longer from VMware. > >>>>> I'm going to try upgrading the box during the week. > >>>> > >>>> I believe folks had to do this on HEAD/8.x as well. Perhaps we can > >>>> automatically disable clflush if we are executing under VMware or Xen: > >>> > >>> Tom, were you able to verify that this patch fixes the problem for you > >>> without requiring you to set the hw.clflush_disable tunable? > >>> > >> > >> John, I'm getting the following build error on all branches: > >> > >> /usr/src/sys/amd64/amd64/initcpu.c: In function 'initializecpucache': > >> /usr/src/sys/amd64/amd64/initcpu.c:184: error: 'vm_guest' undeclared > >> (first use in this function) > >> /usr/src/sys/amd64/amd64/initcpu.c:184: error: (Each undeclared > >> identifier is reported only once > >> /usr/src/sys/amd64/amd64/initcpu.c:184: error: for each function it > >> appears in.) > > > > Oh foo. Can you add 'extern int vm_guest;' to that file near the top? > > Adding that to the top fixed the build on 8.x and HEAD. Both of those > are also now working just fine. However, 7.x still does not build. Ok, I will work on a more formal 7.x patch. > 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 vers.c > linking kernel.debug > initcpu.o(.text+0x272): In function `initializecpucache': > /usr/src/sys/amd64/amd64/initcpu.c:186: undefined reference to `vm_guest' > *** Error code 1 > > > > > >> *** Error code 1 > >> > >> > >> tom > >> > >>>> Index: amd64/amd64/initcpu.c > >>>> =================================================================== > >>>> --- amd64/amd64/initcpu.c (revision 203430) > >>>> +++ amd64/amd64/initcpu.c (working copy) > >>>> @@ -177,17 +177,16 @@ > >>>> if ((cpu_feature & CPUID_CLFSH) != 0) > >>>> cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; > >>>> /* > >>>> - * XXXKIB: (temporary) hack to work around traps generated when > >>>> - * CLFLUSHing APIC registers window. > >>>> + * XXXKIB: (temporary) hack to work around traps generated > >>>> + * when CLFLUSHing APIC registers window under virtualization > >>>> + * environments. > >>>> */ > >>>> TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > >>>> - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && > >>>> - hw_clflush_disable == -1) > >>>> + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) > >>>> cpu_feature &= ~CPUID_CLFSH; > >>>> /* > >>>> * Allow to disable CLFLUSH feature manually by > >>>> - * hw.clflush_disable tunable. This may help Xen guest on some AMD > >>>> - * CPUs. > >>>> + * hw.clflush_disable tunable. > >>>> */ > >>>> if (hw_clflush_disable == 1) > >>>> cpu_feature &= ~CPUID_CLFSH; > >>>> Index: i386/i386/initcpu.c > >>>> =================================================================== > >>>> --- i386/i386/initcpu.c (revision 203430) > >>>> +++ i386/i386/initcpu.c (working copy) > >>>> @@ -724,17 +724,16 @@ > >>>> if ((cpu_feature & CPUID_CLFSH) != 0) > >>>> cpu_clflush_line_size = ((cpu_procinfo >> 8) & 0xff) * 8; > >>>> /* > >>>> - * XXXKIB: (temporary) hack to work around traps generated when > >>>> - * CLFLUSHing APIC registers window. > >>>> + * XXXKIB: (temporary) hack to work around traps generated > >>>> + * when CLFLUSHing APIC registers window under virtualization > >>>> + * environments. > >>>> */ > >>>> TUNABLE_INT_FETCH("hw.clflush_disable", &hw_clflush_disable); > >>>> - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS) && > >>>> - hw_clflush_disable == -1) > >>>> + if (vm_guest != 0 /* VM_GUEST_NO */ && hw_clflush_disable == -1) > >>>> cpu_feature &= ~CPUID_CLFSH; > >>>> /* > >>>> * Allow to disable CLFLUSH feature manually by > >>>> - * hw.clflush_disable tunable. This may help Xen guest on some AMD > >>>> - * CPUs. > >>>> + * hw.clflush_disable tunable. > >>>> */ > >>>> if (hw_clflush_disable == 1) > >>>> cpu_feature &= ~CPUID_CLFSH; > >>>> > >>>> -- > >>>> John Baldwin > >>>> _______________________________________________ > >>>> 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" > >>>> > >>> > >> > >> > >> -- > >> | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | > >> | FreeBSD http://www.FreeBSD.org | > >> > >> > > > > > -- > | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | > | FreeBSD http://www.FreeBSD.org | > > -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 13:54:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8C011065676 for ; Wed, 10 Feb 2010 13:54:06 +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 754DD8FC0A for ; Wed, 10 Feb 2010 13:54:06 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0B77246B52; Wed, 10 Feb 2010 08:54:06 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 3DB7B8A021; Wed, 10 Feb 2010 08:54:05 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 10 Feb 2010 08:53:18 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <20100210105226.5c825b48.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100210105226.5c825b48.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201002100853.18088.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 10 Feb 2010 08:54:05 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Gerrit =?iso-8859-1?q?K=FChn?= Subject: Re: bugs in mpt(4) and mptutil(8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 13:54:06 -0000 On Wednesday 10 February 2010 4:52:26 am Gerrit K=FChn wrote: > Hi, >=20 > I have 2 8port cards with lsi chips installed in one machine that are > driven by mpt(4). I see about the same problem (I think) when disconnecti= ng > disks as described here: > >=20 > When I simply pull a disk (without offlineing it first), zfs does not > notice it (is still listed as "online") and I get lots of >=20 > mpt1: mpt_cam_event: 0x16 > mpt1: mpt_cam_event: 0x12 > mpt1: mpt_cam_event: 0x16 > mpt1: mpt_cam_event: 0x16 > mpt1: mpt_cam_event: 0x16 > mpt1: request 0xffffff80005e0bf0:2419 timed out for ccb 0xffffff0005802800 > (req->ccb 0xffffff0005802800) mpt1: attempting to abort req > 0xffffff80005e0bf0:2419 function 0 mpt1: completing timedout/aborted req > 0xffffff80005e0bf0:2419 mpt1: abort of req 0xffffff80005e0bf0:0 completed > mpt1: request 0xffffff80005dc000:2810 timed out for ccb 0xffffff000fa66800 > (req->ccb 0xffffff000fa66800) mpt1: request 0xffffff80005dc3f0:2811 timed > out for ccb 0xffffff0005802800 (req->ccb 0xffffff0005802800) mpt1: > attempting to abort req 0xffffff80005dc000:2810 function 0 mpt1: > completing timedout/aborted req 0xffffff80005dc3f0:2811 mpt1: completing > timedout/aborted req 0xffffff80005dc000:2810 > [...goes on for ages...] >=20 > I don't know if this would ever stop. It ceased when I put the disk back > in. In the thread above it is mentioned that there are some fixes for mpt > (4) in -current to try out. However, I do not want to run -current on this > machine. So, does anyone here know how the chances are that the mentioned > patches are MFCed soon? >=20 >=20 > One more thing I noticed is that mptutil does not play well with my > controllers: >=20 > pigpen# mptutil show adapter > mpt0 Adapter: > Board Name: USASLP-L8i > Board Assembly: USASLP-L8i > Chip Name: C1068E > Chip Revision: B3 > RAID Levels: none > mptutil: Reading config page header failed: Invalid configuration page You can ignore this message, and it is cleaned up in HEAD. Use 'mptutil -u= 1=20 show adapter' to examine the second controller. > pigpen# mptutil show drives > mpt0 Physical Drives: > da0 ( 466G) ONLINE SATA bus 0 id 0 > da1 ( 466G) ONLINE SATA bus 0 id 1 > da6 ( 466G) ONLINE SATA bus 0 id 2 > da11 ( 466G) ONLINE SATA bus 0 id 3 > da3 ( 466G) ONLINE SATA bus 0 id 0 > da4 ( 466G) ONLINE SATA bus 0 id 1 > da5 ( 466G) ONLINE SATA bus 0 id 2 > da2 ( 75G) ONLINE SATA bus 0 id 3 > da7 ( 75G) ONLINE SATA bus 0 id 4 > da8 ( 466G) ONLINE SATA bus 0 id 5 > da9 ( 466G) ONLINE SATA bus 0 id 6 > da10 ( 466G) ONLINE SATA bus 0 id 7 > da12 ( 3824M) ONLINE SCSI-0 bus 0 id 0 >=20 >=20 > This output is definitely wrong, because the drives are split up on mpt0 > and mpt1 (and the USB stick is not connected to mpt at all :-) as can be > seen with camcontrol: Hmm, I asked the previous reporter to debug this by examining the results t= hat=20 CAM returns from the bus scan using gdb, but I haven't heard back. =20 Unfortunately I do not have access to any hardware with this sort of setup = to=20 debug this. =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 15:11:20 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 289AC106566B; Wed, 10 Feb 2010 15:11:20 +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 C3A7A8FC15; Wed, 10 Feb 2010 15:11:19 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1AFBGKs004607 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 10:11:17 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Vitaly Magerya In-Reply-To: <4B728A7A.60706@gmail.com> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> Content-Type: text/plain Organization: FreeBSD Date: Wed, 10 Feb 2010 09:11:10 -0600 Message-Id: <1265814670.8609.58.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@freebsd.org, x11@FreeBSD.org, freebsd-x11@freebsd.org, Oliver Pinter Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 15:11:20 -0000 On Wed, 2010-02-10 at 12:29 +0200, Vitaly Magerya wrote: > Oliver Pinter wrote: > > After updated the xorg* and dri* and dependency, the system going to > > deadlock at second start of xserver. I think it is not an uniqe issue, > > as others wrote them at freebsd-x11: > > http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html > > I have a similar problem with ATI Mobility Radeon 9000 (r250) and > FreeBSD 8.0-RELEASE-p2 i386 (dmesg is at [1]). The system hangs when I > run Xorg with xorg.conf obtained by `Xorg -configure' and do either of > these: > > * pkill Xorg > * close xorg via ^C and start it again > * close xorg via ^C and kldunload radeon > > I did not try using 'option "DRI" "OFF"' though, I will this evening. > > Unfortunately I can't currently say if it works under different > conditions, since after a number of hangs I switched to VESA. But if > anyone is interested, I'll investigate further and will provide any > additional information -- just name it. I have a strong suspicion that the issue is with bus_dma. If this is a pci based card, then it is trying to allocate 32MB of contiguous physical ram when the drm device is opened. This usually succeeds the first time that the driver opens the device, but later, after memory has become fragmented, this can become an issue. As I have mentioned, I have code that reworks this whole process and I'll try and make a patch available soon, but my I don't have a lot of time now, so it might be the weekend before I can rebase the code and get a clean patch. robert. > [1] http://tx97.net/~magv/dmesg-t40.80-p2.txt > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 15:22:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE0471065676 for ; Wed, 10 Feb 2010 15:22:52 +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 7FAA48FC1C for ; Wed, 10 Feb 2010 15:22:52 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1AFMndQ004697 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 10:22:50 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "O. Hartmann" In-Reply-To: <4B728ED3.7040309@zedat.fu-berlin.de> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B71FFA8.3070306@mail.zedat.fu-berlin.de> <201002100202.59954.christof.schulze@gmx.com> <4B728ED3.7040309@zedat.fu-berlin.de> Content-Type: text/plain Organization: FreeBSD Date: Wed, 10 Feb 2010 09:22:43 -0600 Message-Id: <1265815364.8609.68.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Warren Block , Christof Schulze , freebsd-stable@freebsd.org Subject: Re: freebsd7, radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 15:22:52 -0000 On Wed, 2010-02-10 at 10:47 +0000, O. Hartmann wrote: > On 02/10/10 03:41, Warren Block wrote: > > On Wed, 10 Feb 2010, Christof Schulze wrote: > > > >>> The situation is heavily unsatisfying, since one need an expensive > >>> AMD/ATi Radeon card to gain non-3D poor functionality, where a cheaper > >>> one should be do the same - but the cheaper ones don't work. Even if > >>> one > >>> uses AMD64, the situattion is worse and I have no reason using > >>> Linux-driver on a FreeBSD box. Hope the situation gets cleared in the > >>> nearest future. It's a kind of deadlock. As I said, either spenig a lot > >>> of money for a working RV770 based AMD graphics card with poor > >>> functionality or nothing so far, since most smaller RV730 chips aren't > >>> supported properly by the most recent drivers. > >> To be fair - my ATI X300 has always worked. It is a cheap card with > >> low-end > >> performance but it is perfectly fine for regular desktop-use. > > > > The older chipsets are better supported because the newer ones are, > > well, newer. If you haven't bought a video card yet, look at the > > radeon(4x) man page first. > > > > Unfortunately, that doesn't help if you already have a newer card, or > > a notebook. > > > > The other choices are Intel, where they don't have standalone video > > cards, or nVidia, which has a full-featured blob and a really > > bare-bones open driver. > > > > -Warren Block * Rapid City, South Dakota USA > > You said it. Alternatives? Barely. Having Intel-X58 based mainboards for > our workstations, there is no onboard-Intel solution. > Speaking of nVidia - 64Bit FreeBSD-support isn't mature and, as far as I > know, not yet arrived, but underway, but this is in the future and isn't > subject of any consideration if I need to make my choices now. > Our department orders, in most cases, a bunch of systems completely > equipted also with graphics boards. In many cases, there is no reason, > economically, buying outdated graphics boards which are 5 years old and > older, despite the fact that many shops do not offer them. > > On Linux, most of those modern ATi/AMD video cards not working with X11 > on FreeBSD/amd64 work on Linux due to the fact most Linux derivates have > a more modern OpenSource Xorg environment, including 'cutting' edge DRI > and drivers. The alternative is to play with the well supported 32- and > 64-Bit blob even AMD/ATi offers for Linux. We use more or less, the same code that linux does. We don't have KMS/TTM yet, but generally, I think you will probably find more issues using those than you will with the slightly older driver. If you are having issues with the radeon driver, then you need to report that to me and be willing to provide details. The guys at AMD are pretty willing to offer support where needed, but I can't look into issues that I don't know about. The very newest radeons still aren't supported in any code, but all HD4xxx and below should be. I don't have the time that I have in the past, but I'll try and sort out issues as I can. robert. > Regards, > Oliver > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 15:36:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 080A710656A4 for ; Wed, 10 Feb 2010 15:36:24 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B76508FC5F for ; Wed, 10 Feb 2010 15:36:23 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1NfEc1-0003IZ-Sd for freebsd-stable@freebsd.org; Wed, 10 Feb 2010 16:36:21 +0100 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 ; Wed, 10 Feb 2010 16:36:16 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Feb 2010 16:36:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 10 Feb 2010 16:36:00 +0100 Lines: 15 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20100118 Thunderbird/3.0 Sender: news Cc: freebsd-hackers@freebsd.org Subject: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 15:36:24 -0000 It looks like I've stumbled upon a bug in vSphere 4 (recent update) with FreeBSD/amd64 8.0/8-stable (but not 7.x) guests on Opteron(s). In this combination, everything works fine until a moderate load is started - a buildworld is enough. About five minutes after the load starts, the vSphere client starts getting timeouts while talking with the host and soon after the guest VM is forcibly shut down without any trace of a reason in various logs. The same VM runs fine on hosts with Xeon CPUs. The shutdown happens regardless if there is a vSphere client connected. This is very repeatable, on Sun Fire X4140 hosts. With 7.x/7.stable guests everything works fine. I'm posting this for future reference and to see if anyone has encountered something like that, or has an idea why this happens. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 15:46:08 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 358E1106566C; Wed, 10 Feb 2010 15:46:08 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 6283D8FC16; Wed, 10 Feb 2010 15:46:06 +0000 (UTC) Received: by fxm24 with SMTP id 24so143824fxm.3 for ; Wed, 10 Feb 2010 07:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=CaxtEGvDFjwJjrB4M8+tRaR2P5jdW54JddSxY4vDi2Q=; b=yAT+QXc/3msX7oN0JLl4eWDE5ZOZRpoHqyA7vyHkUhfGtuJcU7qQbonRUnqXDyIAJN qrCN/QeuzR8FGkPuNWGgEiOdK1vgYFgfT5JciaW72SM4aGUiTV81p5pzzJAA22HK3sfV SAuHaYRjWu31JMxOX2l6yNpGhsIjrB/BiuVJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=cmd+mYVQsK8P3smHB38UpJtXhHXZtZ3XQQcUO6F6SBgIaAA4CB7GBibSXmaiANOUsi 16tWrOOA0y9GCqL8bkAeBl4pmNplYi7nU4uIVOsmmALBJ8vPj91yil2W6l/2eOl0X5wI p4WAQ7Bx3hrlLZs9VU5BUzHxc8MR4vjWEkCNw= Received: by 10.87.61.4 with SMTP id o4mr3367802fgk.31.1265816766085; Wed, 10 Feb 2010 07:46:06 -0800 (PST) Received: from ?172.16.0.7? ([85.198.160.156]) by mx.google.com with ESMTPS id 14sm671080fxm.3.2010.02.10.07.46.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Feb 2010 07:46:04 -0800 (PST) Message-ID: <4B72D4B9.6020109@gmail.com> Date: Wed, 10 Feb 2010 17:46:01 +0200 From: Vitaly Magerya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Robert Noland References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <1265814670.8609.58.camel@balrog.2hip.net> In-Reply-To: <1265814670.8609.58.camel@balrog.2hip.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, x11@FreeBSD.org, freebsd-x11@freebsd.org, Oliver Pinter Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 15:46:08 -0000 Robert Noland wrote: >> I have a similar problem with ATI Mobility Radeon 9000 (r250) and >> FreeBSD 8.0-RELEASE-p2 i386 (dmesg is at [1]). The system hangs when I >> run Xorg with xorg.conf obtained by `Xorg -configure' and do either of >> these: >> >> * pkill Xorg >> * close xorg via ^C and start it again >> * close xorg via ^C and kldunload radeon >> >> I did not try using 'option "DRI" "OFF"' though, I will this evening. With DRI disabled, no hang occurs and I'm once again happy. >> Unfortunately I can't currently say if it works under different >> conditions, since after a number of hangs I switched to VESA. But if >> anyone is interested, I'll investigate further and will provide any >> additional information -- just name it. > > I have a strong suspicion that the issue is with bus_dma. If this is a > pci based card, then it is trying to allocate 32MB of contiguous > physical ram when the drm device is opened. This usually succeeds the > first time that the driver opens the device, but later, after memory has > become fragmented, this can become an issue. As I have mentioned, I > have code that reworks this whole process and I'll try and make a patch > available soon, but my I don't have a lot of time now, so it might be > the weekend before I can rebase the code and get a clean patch. No pressure from me. I'm already grateful that you single-handedly keep the whole DRI-on-FreeBSD thing going. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 15:49:23 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD206106566B; Wed, 10 Feb 2010 15:49:23 +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 979568FC0A; Wed, 10 Feb 2010 15:49:22 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA05092; Wed, 10 Feb 2010 17:49:18 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B72D57D.6080002@icyb.net.ua> Date: Wed, 10 Feb 2010 17:49:17 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Vitaly Magerya References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> In-Reply-To: <4B728A7A.60706@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, freebsd-x11@freebsd.org, Robert Noland , Oliver Pinter Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 15:49:23 -0000 on 10/02/2010 12:29 Vitaly Magerya said the following: > Oliver Pinter wrote: >> After updated the xorg* and dri* and dependency, the system going to >> deadlock at second start of xserver. I think it is not an uniqe issue, >> as others wrote them at freebsd-x11: >> http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html > > I have a similar problem with ATI Mobility Radeon 9000 (r250) and > FreeBSD 8.0-RELEASE-p2 i386 (dmesg is at [1]). The system hangs when I > run Xorg with xorg.conf obtained by `Xorg -configure' and do either of > these: > > * pkill Xorg > * close xorg via ^C and start it again > * close xorg via ^C and kldunload radeon > > I did not try using 'option "DRI" "OFF"' though, I will this evening. > > Unfortunately I can't currently say if it works under different > conditions, since after a number of hangs I switched to VESA. But if > anyone is interested, I'll investigate further and will provide any > additional information -- just name it. Please check if your X binary is linked with libthr (using ldd). I saw similar problems when it was not. That was because it was compiled without HAL support. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 15:59:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF6BB106568F for ; Wed, 10 Feb 2010 15:59:28 +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 09F508FC08 for ; Wed, 10 Feb 2010 15:59:27 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA05371; Wed, 10 Feb 2010 17:59:22 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B72D7DA.3050305@icyb.net.ua> Date: Wed, 10 Feb 2010 17:59:22 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Rohit Grover References: <426bed111002080049u16354c87pd4fb8830e0542972@mail.gmail.com> <20100208114734.GA99245@icarus.home.lan> <426bed111002091752g1cf96cd0qf7be5098ab5c9742@mail.gmail.com> <426bed111002100335x538a14bbo38f511566fe05fb2@mail.gmail.com> In-Reply-To: <426bed111002100335x538a14bbo38f511566fe05fb2@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, utisoft@gmail.com, Jeremy Chadwick Subject: Re: Unresponsive keyboard after a few boots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 15:59:28 -0000 on 10/02/2010 13:35 Rohit Grover said the following: > Thanks for replying. I would like to pursue this problem. I have > verified that this problem doesn't happen with 8.0/RELEASE, and there > are some improvements in 8.0/STABLE which I need, so it is very > important for me to be able to use the latest 8.0/STABLE. Could you please try hw.pci.usb_early_takeover="0" in loader.conf? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 16:01:26 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C66601065670; Wed, 10 Feb 2010 16:01:26 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id EE6198FC23; Wed, 10 Feb 2010 16:01:25 +0000 (UTC) Received: by fxm24 with SMTP id 24so160699fxm.3 for ; Wed, 10 Feb 2010 08:01:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=hBscAag4uNE7oODitE2j+W1lBqP+l3ArO0nm5ehOev4=; b=niXm9kHJQID+wj7Pg5A7zQjqG7Yk8ylhgQ36RCmoN/LaI+i4mWeWC/1zWvIXatSAPK nvEF/B+6cKONmQ/K1Gh4g+dgbQUgJzYPifFmacAuMHI9rlLf1TjIVsdR65sk2REknvUp axbOwK55C24YBOOK6raivYPrEduYg71kH/OTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=L73rCgcmhoHN4IcJHxIGhJSuyleATp88E0fNeGgNErRkzdxgx55U7tgIKpV1HcUGmw 9RefB4qTOX47+fxO3tYZgnybBsaaS1ces0ZyewKdry280Nkes4L99CiCDmC8s4yI1qvM NxLBA598+u/CIiXSLXsJzrsXM9Pq/VbeQFMAk= Received: by 10.223.5.87 with SMTP id 23mr495313fau.87.1265817684611; Wed, 10 Feb 2010 08:01:24 -0800 (PST) Received: from ?172.16.0.7? ([85.198.160.156]) by mx.google.com with ESMTPS id 16sm672453fxm.12.2010.02.10.08.01.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Feb 2010 08:01:23 -0800 (PST) Message-ID: <4B72D854.5080902@gmail.com> Date: Wed, 10 Feb 2010 18:01:24 +0200 From: Vitaly Magerya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> In-Reply-To: <4B72D57D.6080002@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, freebsd-x11@freebsd.org, Robert Noland , Oliver Pinter Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 16:01:26 -0000 Andriy Gapon wrote: > Please check if your X binary is linked with libthr (using ldd). > I saw similar problems when it was not. > That was because it was compiled without HAL support. It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; should I try rebuilding xorg-server with HAL? From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 16:03:40 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 579BF106566B; Wed, 10 Feb 2010 16:03:40 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (mail.farley.org [IPv6:2001:470:1f0f:20:2::11]) by mx1.freebsd.org (Postfix) with ESMTP id 206DC8FC25; Wed, 10 Feb 2010 16:03:40 +0000 (UTC) Received: from thor.farley.org (HPooka@thor.farley.org [IPv6:2001:470:1f0f:20:1::5]) by mail.farley.org (8.14.4/8.14.4) with ESMTP id o1AG3dLP018677; Wed, 10 Feb 2010 10:03:39 -0600 (CST) (envelope-from scf@FreeBSD.org) Date: Wed, 10 Feb 2010 10:03:20 -0600 (CST) From: "Sean C. Farley" To: Ivan Voras In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.farley.org Cc: freebsd-hackers@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 16:03:40 -0000 On Wed, 10 Feb 2010, Ivan Voras wrote: > It looks like I've stumbled upon a bug in vSphere 4 (recent update) > with FreeBSD/amd64 8.0/8-stable (but not 7.x) guests on Opteron(s). In > this combination, everything works fine until a moderate load is > started - a buildworld is enough. About five minutes after the load > starts, the vSphere client starts getting timeouts while talking with > the host and soon after the guest VM is forcibly shut down without any > trace of a reason in various logs. The same VM runs fine on hosts > with Xeon CPUs. The shutdown happens regardless if there is a vSphere > client connected. > > This is very repeatable, on Sun Fire X4140 hosts. > > With 7.x/7.stable guests everything works fine. > > I'm posting this for future reference and to see if anyone has > encountered something like that, or has an idea why this happens. Is it related to this thread: http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/054755.html I have been fighting other issues (mainly countless "Command WRITE(10) took X.XYZ seconds" in the VM's vmware.log file under moderate I/O) with VMware Workstation 7 on a Linux host with an AMD Phenom(tm) II X4 945 Processor, but I still have more testing to see if I can work through it. I also do not want to take over this thread. Sean -- scf@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 16:05:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 358DD1065693; Wed, 10 Feb 2010 16:05:34 +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 10E868FC1F; Wed, 10 Feb 2010 16:05:32 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA05558; Wed, 10 Feb 2010 18:05:31 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B72D94A.8030509@icyb.net.ua> Date: Wed, 10 Feb 2010 18:05:30 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 16:05:34 -0000 on 10/02/2010 17:36 Ivan Voras said the following: > It looks like I've stumbled upon a bug in vSphere 4 (recent update) with > FreeBSD/amd64 8.0/8-stable (but not 7.x) guests on Opteron(s). In this > combination, everything works fine until a moderate load is started - a > buildworld is enough. About five minutes after the load starts, the > vSphere client starts getting timeouts while talking with the host and > soon after the guest VM is forcibly shut down without any trace of a > reason in various logs. The same VM runs fine on hosts with Xeon CPUs. > The shutdown happens regardless if there is a vSphere client connected. > > This is very repeatable, on Sun Fire X4140 hosts. > > With 7.x/7.stable guests everything works fine. > > I'm posting this for future reference and to see if anyone has > encountered something like that, or has an idea why this happens. Wild guess - try disabling superpages in the guests. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 16:07:23 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C33CD10656A4; Wed, 10 Feb 2010 16:07:23 +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 8152A8FC13; Wed, 10 Feb 2010 16:07:22 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA05603; Wed, 10 Feb 2010 18:07:18 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B72D9B5.7000300@icyb.net.ua> Date: Wed, 10 Feb 2010 18:07:17 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Vitaly Magerya References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> In-Reply-To: <4B72D854.5080902@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, freebsd-x11@freebsd.org, Robert Noland , Oliver Pinter Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 16:07:23 -0000 on 10/02/2010 18:01 Vitaly Magerya said the following: > Andriy Gapon wrote: >> Please check if your X binary is linked with libthr (using ldd). >> I saw similar problems when it was not. >> That was because it was compiled without HAL support. > > It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; > should I try rebuilding xorg-server with HAL? Please try, if even just to see if it helps. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 16:12:59 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79332106568B; Wed, 10 Feb 2010 16:12:59 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 39CDE8FC21; Wed, 10 Feb 2010 16:12:58 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1AGCohE005043 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 11:12:54 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Vitaly Magerya In-Reply-To: <4B72D854.5080902@gmail.com> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> Content-Type: text/plain Organization: FreeBSD Date: Wed, 10 Feb 2010 10:12:42 -0600 Message-Id: <1265818363.8609.70.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-x11@freebsd.org, stable@freebsd.org, Andriy Gapon , Oliver Pinter Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 16:12:59 -0000 On Wed, 2010-02-10 at 18:01 +0200, Vitaly Magerya wrote: > Andriy Gapon wrote: > > Please check if your X binary is linked with libthr (using ldd). > > I saw similar problems when it was not. > > That was because it was compiled without HAL support. > > It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; > should I try rebuilding xorg-server with HAL? Yes, you can still disable hal at runtime by setting AutoAddDevices "Off" in xorg.conf. robert. -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 16:35:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D7EA1065670 for ; Wed, 10 Feb 2010 16:35:45 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 653D38FC0C for ; Wed, 10 Feb 2010 16:35:45 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.4/8.14.1) with ESMTP id o1AGZiYk022984 for ; Wed, 10 Feb 2010 08:35:44 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.14.4/8.13.4/Submit) id o1AGZi8m022983; Wed, 10 Feb 2010 08:35:44 -0800 (PST) Date: Wed, 10 Feb 2010 08:35:44 -0800 (PST) From: Matthew Dillon Message-Id: <201002101635.o1AGZi8m022983@apollo.backplane.com> To: freebsd-stable@freebsd.org References: <4B6F9A8D.4050907@langille.org> <4B718EBB.6080709@acm.poly.edu> <4B723609.8010802@langille.org> <201002101127.53444.pieter@service2media.com> <20100210105516.GA65506@icarus.home.lan> Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 16:35:45 -0000 :Correction -- more than likely on a consumer motherboard you *will not* :be able to put a non-VGA card into the PCIe x16 slot. I have numerous :Asus and Gigabyte motherboards which only accept graphics cards in their :PCIe x16 slots; this """feature""" is documented in user manuals. I :don't know how/why these companies chose to do this, but whatever. : :I would strongly advocate that the OP (who has stated he's focusing on :stability and reliability over speed) purchase a server motherboard that :has a PCIe x8 slot on it and/or server chassis (usually best to buy both :of these things from the same vendor) and be done with it. : :-- :| Jeremy Chadwick jdc@parodius.com | It is possible this is related to the way Intel on-board graphics work in recent chipsets. e.g. i915 or i925 chipsets. The on-motherboard video uses a 16-lane internal PCI-e connection which is SHARED with the 16-lane PCI-e slot. If you plug something into the slot (e.g. a graphics card), it disables the on-motherboard video. I'm not sure if the BIOS can still boot if you plug something other than a video card into these MBs and no video at all is available. Presumably it should be able to, you just wouldn't have any video at all. Insofar as I know AMD-based MBs with on-board video don't have this issue, though it should also be noted that AMD-based MBs tend to be about 6-8 months behind Intel ones in terms of features. -Matt From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 17:06:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3ACA2106566B for ; Wed, 10 Feb 2010 17:06:17 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id E817D8FC0A for ; Wed, 10 Feb 2010 17:06:16 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1NfG11-0006GT-A1 for freebsd-stable@freebsd.org; Wed, 10 Feb 2010 18:06:15 +0100 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 ; Wed, 10 Feb 2010 18:06:15 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Feb 2010 18:06:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 10 Feb 2010 18:05:59 +0100 Lines: 25 Message-ID: References: <4B72D94A.8030509@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20100118 Thunderbird/3.0 In-Reply-To: <4B72D94A.8030509@icyb.net.ua> Sender: news Cc: freebsd-hackers@freebsd.org Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 17:06:17 -0000 On 02/10/10 17:05, Andriy Gapon wrote: > on 10/02/2010 17:36 Ivan Voras said the following: >> It looks like I've stumbled upon a bug in vSphere 4 (recent update) with >> FreeBSD/amd64 8.0/8-stable (but not 7.x) guests on Opteron(s). In this >> combination, everything works fine until a moderate load is started - a >> buildworld is enough. About five minutes after the load starts, the >> vSphere client starts getting timeouts while talking with the host and >> soon after the guest VM is forcibly shut down without any trace of a >> reason in various logs. The same VM runs fine on hosts with Xeon CPUs. >> The shutdown happens regardless if there is a vSphere client connected. >> >> This is very repeatable, on Sun Fire X4140 hosts. >> >> With 7.x/7.stable guests everything works fine. >> >> I'm posting this for future reference and to see if anyone has >> encountered something like that, or has an idea why this happens. > > Wild guess - try disabling superpages in the guests. It looks like your guess is perfectly correct :) The guest has been doing buildworlds for an hour and it works fine. Thanks! It's strange how this doesn't affect the Xeons... From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 17:13:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A02A106566B; Wed, 10 Feb 2010 17:13:36 +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 54FF08FC13; Wed, 10 Feb 2010 17:13:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA06644; Wed, 10 Feb 2010 19:13:33 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B72E93C.80102@icyb.net.ua> Date: Wed, 10 Feb 2010 19:13:32 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Ivan Voras References: <4B72D94A.8030509@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 17:13:36 -0000 on 10/02/2010 19:05 Ivan Voras said the following: > On 02/10/10 17:05, Andriy Gapon wrote: >> on 10/02/2010 17:36 Ivan Voras said the following: >>> It looks like I've stumbled upon a bug in vSphere 4 (recent update) with >>> FreeBSD/amd64 8.0/8-stable (but not 7.x) guests on Opteron(s). In this >>> combination, everything works fine until a moderate load is started - a >>> buildworld is enough. About five minutes after the load starts, the >>> vSphere client starts getting timeouts while talking with the host and >>> soon after the guest VM is forcibly shut down without any trace of a >>> reason in various logs. The same VM runs fine on hosts with Xeon CPUs. >>> The shutdown happens regardless if there is a vSphere client connected. >>> >>> This is very repeatable, on Sun Fire X4140 hosts. >>> >>> With 7.x/7.stable guests everything works fine. >>> >>> I'm posting this for future reference and to see if anyone has >>> encountered something like that, or has an idea why this happens. >> >> Wild guess - try disabling superpages in the guests. > > It looks like your guess is perfectly correct :) The guest has been > doing buildworlds for an hour and it works fine. Thanks! > > It's strange how this doesn't affect the Xeons... I really can not tell more but there seems to be an issue between our implementation of superpages (very unique) and AMD processors from 10h family. I'd recommend not using superpages feature with those processors for time being. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:00:43 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE1D7106568D; Wed, 10 Feb 2010 18:00:43 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 451878FC15; Wed, 10 Feb 2010 18:00:43 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o1AI0gIH006563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 19:00:42 +0100 (CET) (envelope-from uqs@FreeBSD.org) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o1AI0g7I006562; Wed, 10 Feb 2010 19:00:42 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Wed, 10 Feb 2010 19:00:42 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Robert Noland Message-ID: <20100210180042.GF9748@acme.spoerlein.net> Mail-Followup-To: Robert Noland , Vitaly Magerya , stable@freebsd.org, Oliver Pinter References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <1265814670.8609.58.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1265814670.8609.58.camel@balrog.2hip.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@FreeBSD.org, Vitaly Magerya , Oliver Pinter Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:00:43 -0000 On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: > I have a strong suspicion that the issue is with bus_dma. If this is a > pci based card, then it is trying to allocate 32MB of contiguous > physical ram when the drm device is opened. This usually succeeds the > first time that the driver opens the device, but later, after memory has > become fragmented, this can become an issue. As I have mentioned, I > have code that reworks this whole process and I'll try and make a patch > available soon, but my I don't have a lot of time now, so it might be > the weekend before I can rebase the code and get a clean patch. No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without the recent Xorg update (haven't done that yet) I usually startx right after boot, and this usually works fine. One time I had massive ZFS/git jobs running headless first and wanted to startx afterwards. X11 took quite some time to come up and although window "switching" was snappy, *moving* windows around was slow as hell, window contents were re-drawing at ~1FPS. This also seems to always happen if I stop X11 and startx it again. So I made a diff from a regular Xorg startup against the slow one: --- Xorg.0.log 2010-02-09 20:59:16.000000000 +0100 +++ Xorg.slow.log 2010-01-31 11:04:08.000000000 +0100 ... @@ -599,49 +599,22 @@ (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 -(II) RADEON(0): [pci] ring handle = 0xed1a5000 -(II) RADEON(0): [pci] Ring mapped at 0x802aa0000 -(II) RADEON(0): [pci] Ring contents 0x00000000 -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 -(II) RADEON(0): [pci] Ring read ptr contents 0x00000000 -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c00000 -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000 -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 -(II) RADEON(0): [drm] register handle = 0xfe8e0000 -(II) RADEON(0): [dri] Visual configs initialized +(EE) RADEON(0): [pci] Out of memory (-12) +(EE) RADEON(0): [pci] PCI failed to initialize. Disabling the DRI. +(II) RADEON(0): [drm] removed 1 reserved context for kernel +(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xffffff8014a6d000 at 0x8006d4000 +(II) RADEON(0): [drm] Closed DRM master. (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x001f0000 (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 (==) RADEON(0): Backing store disabled -(II) RADEON(0): [DRI] installation complete -(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers -(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers -(II) RADEON(0): [drm] dma control initialized, using IRQ 256 -(II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 -(WW) RADEON(0): DRI init changed memory map, adjusting ... -(WW) RADEON(0): MC_FB_LOCATION was: 0x00ef00d0 is: 0x00ef00d0 -(WW) RADEON(0): MC_AGP_LOCATION was: 0x003f0000 is: 0x00030000 -(II) RADEON(0): RADEONRestoreMemMapRegisters() : -(II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 -(II) RADEON(0): MC_AGP_LOCATION : 0x00030000 -(II) RADEON(0): Direct rendering enabled -(II) RADEON(0): Setting EXA maxPitchBytes -(II) EXA(0): Offscreen pixmap area of 111050752 bytes -(II) EXA(0): Driver registered support for the following operations: -(II) Solid -(II) Copy -(II) Composite (RENDER acceleration) -(II) UploadToScreen -(II) DownloadFromScreen -(II) RADEON(0): Acceleration enabled +(WW) RADEON(0): Direct rendering disabled +(EE) RADEON(0): Acceleration initialization failed +(II) RADEON(0): Acceleration disabled (**) Option "dpms" (**) RADEON(0): DPMS enabled (==) RADEON(0): Silken mouse enabled -(II) RADEON(0): Set up textured video +(II) RADEON(0): Textured video requires CP on R5xx/R6xx/R7xx/IGP Output CRT2 disable success (II) RADEON(0): UNIPHY1 transmitter: Coherent Mode enabled Output UNIPHY1 transmitter setup success @@ -661,7 +634,7 @@ Mode 1920x1200 - 2080 1235 9 (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 -(II) RADEON(0): MC_AGP_LOCATION : 0x00030000 +(II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 freq: 154000000 best_freq: 153900000 best_feedback_div: 57 Pretty obvious what went wrong... Bye, Uli From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:03:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D2F11065670; Wed, 10 Feb 2010 18:03:27 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id D7D638FC1A; Wed, 10 Feb 2010 18:03:26 +0000 (UTC) Received: by fxm24 with SMTP id 24so293360fxm.3 for ; Wed, 10 Feb 2010 10:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=ILeZE0pAcZgN1NuEZ9f1xxhqFECs0jwRUlHpY3gSQE8=; b=S2ak9MnlOeEaGJ2sB5lpyE6IDGoj3iwLjYkb7ShYjonLqs8MMYnYbTAwew5qtyeQVD fqtxI9IBcGPobep4zng1ejB889sKeEzdxsJSGSVrO+EYeQtXuoCSHHLAtQ/HVdl8R6fq RJ3b5HT0UOfvG2lW0ZQ0LwmXyzWo7AJCy4vGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=NvkfdzDy1OY6GFjBJNeH34yj9y207q0ZtvtlgSJ6Ndb3dbogtZC/n7witZjzpzHd3W mcJt2HnvbtGIDOfIkNcXAzZ6eBp0zJQ2YQeZjS4NCbFwh4YV3hEWd0CLXzpoXMoxnEOm hEbCLLqA/uxN5gMhvVnvOIrS2buvVx9HKGolQ= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.87.194 with SMTP id y44mr311778wee.157.1265825005201; Wed, 10 Feb 2010 10:03:25 -0800 (PST) In-Reply-To: <4B72E93C.80102@icyb.net.ua> References: <4B72D94A.8030509@icyb.net.ua> <4B72E93C.80102@icyb.net.ua> From: Ivan Voras Date: Wed, 10 Feb 2010 19:03:05 +0100 X-Google-Sender-Auth: e40ea41441270bf6 Message-ID: <9bbcef731002101003r203f5189xf139700a0d48afa0@mail.gmail.com> To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:03:27 -0000 On 10 February 2010 18:13, Andriy Gapon wrote: > on 10/02/2010 19:05 Ivan Voras said the following: >> On 02/10/10 17:05, Andriy Gapon wrote: >>> Wild guess - try disabling superpages in the guests. >> >> It looks like your guess is perfectly correct :) The guest has been >> doing buildworlds for an hour and it works fine. Thanks! >> >> It's strange how this doesn't affect the Xeons... > > I really can not tell more but there seems to be an issue between our > implementation of superpages (very unique) and AMD processors from 10h family. > I'd recommend not using superpages feature with those processors for time being. When you say "very unique" is it in the "it is not Linux or Windows" sense or do we do something nonstandard? From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:05:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8380106568D for ; Wed, 10 Feb 2010 18:05:05 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 6812C8FC28 for ; Wed, 10 Feb 2010 18:05:05 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so84910qwd.7 for ; Wed, 10 Feb 2010 10:05:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Eqn7CC8rZKDAQpru+SEP9mRRELNSaNKwuCZ6BWJN/uA=; b=QcoKKgY0c63+LnnMrPHc9PosQwdmZPjuUtLA7WGebchpPi6rOczLijqEaCuFpknC5N MMfzOT2AdewE3HWBiiPhIE4biyE8dU0zl41F4/fVwTJDzdCZR4fBAAsXjiDp5Laxep3Y 4wwtCHtbOSE9FpTzlZiSbO6BzKdElZpHYthM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Mx431BeHzhS05qkQhqIxwaIzyjNWt8vCbSkaXSLpm8jhFflSSoTVkiuBWWXbARwm4R 0xPJpS9JttVqMj3sfs9AsDoiBlaR+QoOEYFd5ae60Dptyxqht3k6fa/aKTJ2uF3VrGyx sfHMdm1+j2IqobrokAirg5TzQwjBdXouHiAo8= Received: by 10.224.80.66 with SMTP id s2mr334254qak.293.1265825104116; Wed, 10 Feb 2010 10:05:04 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 40sm13602739vws.17.2010.02.10.10.05.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Feb 2010 10:05:02 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 10 Feb 2010 10:04:55 -0800 From: Pyun YongHyeon Date: Wed, 10 Feb 2010 10:04:55 -0800 To: Olivier Cochard-Labb? Message-ID: <20100210180455.GN1358@michelle.cdnetworks.com> References: <20100202193616.GA16953@osiris.chen.org.nz> <3131aa531002091231o3003a60ay7e83b17fa995063b@mail.gmail.com> <20100209215110.GJ1358@michelle.cdnetworks.com> <3131aa531002092235t396664aajf247f7a69b6ef12b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3131aa531002092235t396664aajf247f7a69b6ef12b@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE outgoing scp stalling frequently. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:05:05 -0000 On Wed, Feb 10, 2010 at 07:35:27AM +0100, Olivier Cochard-Labb? wrote: > On Tue, Feb 9, 2010 at 10:51 PM, Pyun YongHyeon wrote: > > > > I guess I fixed all known vge(4) issues, how recent stable/8 you > > use? > > > > Hi, > > my mistake, it's a release and not a stable version that I'm using: > All issues except poor Tx performance was fixed. I'm still not sure whether the poor Tx performance on PCIe VT6130 comes from the limitation of controller which seems to limit the number of outstanding DMA cycles. > uname -a > > FreeBSD dev.bsdrp.net 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue > Jan 5 16:02:27 UTC 2010 > root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 > Ok, if you encounter vge(4) issues in stable/8 let us know. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:05:37 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8D461065672; Wed, 10 Feb 2010 18:05:37 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3A3ED8FC19; Wed, 10 Feb 2010 18:05:37 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o1AI5awB019391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 19:05:36 +0100 (CET) (envelope-from uqs@FreeBSD.org) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o1AI5abb019390; Wed, 10 Feb 2010 19:05:36 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Wed, 10 Feb 2010 19:05:35 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Ruslan Ermilov Message-ID: <20100210180535.GG9748@acme.spoerlein.net> Mail-Followup-To: Ruslan Ermilov , stable@freebsd.org References: <20100210085814.GE9748@acme.spoerlein.net> <20100210104904.GA85373@edoofus.dev.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100210104904.GA85373@edoofus.dev.vega.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@FreeBSD.org Subject: Re: numeric sort(1) is broken on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:05:37 -0000 On Wed, 10.02.2010 at 13:49:05 +0300, Ruslan Ermilov wrote: > On Wed, Feb 10, 2010 at 09:58:14AM +0100, Ulrich Spörlein wrote: > > Hi guys, > > > > not sure if this is a pilot error, but it seems to me that gnu sort -n > > is broken on at least -STABLE (couldn't test -CURRENT yet). > > > > It somehow does not manifest when using a simple list and sorting on a > > specific column, but it always happens to me when using it in > > combination with find(1). > > > > % truncate -s10m a; truncate -s5m b; truncate -s800k c > > % find a b c -ls|sort -nk7,7 > > 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a > > 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b > > 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c > > I bet you're using some non-C locale for LC_NUMERIC. > What does "locale" output tell you? Yes and no. LC_NUMERIC is still at C, LC_CTYPE is set to UTF-8, but as there are no non-ASCII symbols in that output it shouldn't matter, right? For me, 819200 is smaller than 10485760 in pretty much all locales. Why the hell is a numeric gnusort locale dependant? Why is -g working anyway? % locale LANG= LC_CTYPE=de_DE.UTF-8 LC_COLLATE="C" LC_TIME="C" LC_NUMERIC="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= % find a b c -ls | LC_ALL=C sort -nk7,7 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a Great, now I'm even more angry at sort(1) than before ... Regards, Uli From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:05:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC21D10656B6; Wed, 10 Feb 2010 18:05:45 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [92.53.116.15]) by mx1.freebsd.org (Postfix) with ESMTP id 634FC8FC08; Wed, 10 Feb 2010 18:05:45 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NfGb3-0007xC-NF; Wed, 10 Feb 2010 20:43:29 +0300 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 3FC12B860; Wed, 10 Feb 2010 20:43:38 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 2DCC5B829; Wed, 10 Feb 2010 20:43:38 +0300 (MSK) Date: Wed, 10 Feb 2010 20:43:38 +0300 From: Dmitry Marakasov To: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20100210174338.GC39752@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:05:45 -0000 Hi! I think I've reported that before, the I thought it's been fixed, however I still get data corruptions when writing on NFS volumes. Now I wonder - is nobody really using NFS, or do I have that much of uncommon setup, or this is some kind of local problem? Client: 8.0-RELEASE i386 Server: 8.0-RELEASE amd64 mount options: nfs rw,nosuid,noexec,nfsv3,intr,soft,tcp,bg,nolockd Server has ZFS, but the same thing happens when sharing UFS placed on md(4). I've prepared a special 1GB file to determine the details of corruption: it's filled with 32-bit numbers each equal to it's own offset in the file. That is, like that: 00000000 00 00 00 00 04 00 00 00 08 00 00 00 0c 00 00 00 |................| 00000010 10 00 00 00 14 00 00 00 18 00 00 00 1c 00 00 00 |................| 00000020 20 00 00 00 24 00 00 00 28 00 00 00 2c 00 00 00 | ...$...(...,...| 00000030 30 00 00 00 34 00 00 00 38 00 00 00 3c 00 00 00 |0...4...8...<...| I've copied that file over NFS from client to server around 50 times, and got 3 corruptions on 8th, 28th and 36th copies. Case1: single currupted block 3779CF88-3779FFFF (12408 bytes). Data in block is shifted 68 bytes up, loosing first 68 bytes are filling last 68 bytes with garbage. Interestingly, among that garbage is my hostname. Case2: single currupted block 2615CFA0-2615FFFF (12384 bytes). Data is shifted by 44 bytes in the same way. Case3: single currepted block 3AA947A8-3AA97FFF (14424 bytes). Data is shifted by 36 bytes in the same way. Any ideas? PS. Diffs of corrupted blocks in a text format are here: http://people.freebsd.org/~amdmi3/diff.1.txt http://people.freebsd.org/~amdmi3/diff.2.txt http://people.freebsd.org/~amdmi3/diff.3.txt -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:07:13 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 416461065695; Wed, 10 Feb 2010 18:07:13 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id 438B58FC17; Wed, 10 Feb 2010 18:07:11 +0000 (UTC) Received: by bwz3 with SMTP id 3so296586bwz.13 for ; Wed, 10 Feb 2010 10:07:10 -0800 (PST) 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=nvitfV6nvVoCGdJJs1k3afBorK+2GlLYkqgSvBBKbL4=; b=u6UkLrfLaMoEM2ihNizN0OCTOVFG5xWxERfIXSohdRLwUzE7shYG04zvamkFVJO0j3 Au/HTLKpoC9j4Dh2/gG3YNpB3AInMoAkfyCJrzospVjYrSw2ROTYKHtyGRjmn69F21i6 kBmeC0/e7wZXTWTATzq5uk1UfAwwPjPhk5qRg= 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=d6fCwr69iuj1V9zYbg1aDPlabf0kQgjjtjETQ1RXtBa6Evsg+S++PMechN5dtg2lW/ CHBCe/h3Xc554o0olTkT4Ovw+uNr9t5smfDErOoTVMGHOry+mw0lQ7/MUJXNGqU8p5rQ K2RD0bIsOHf+0UiOXjmQRYwXAmufThsOtZqIc= MIME-Version: 1.0 Received: by 10.204.7.139 with SMTP id d11mr379931bkd.162.1265825230757; Wed, 10 Feb 2010 10:07:10 -0800 (PST) In-Reply-To: <1265763880.8609.17.camel@balrog.2hip.net> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B71FFA8.3070306@mail.zedat.fu-berlin.de> <1265763880.8609.17.camel@balrog.2hip.net> Date: Wed, 10 Feb 2010 18:07:06 +0000 Message-ID: <6101e8c41002101007k75fe6348t589d8cc0ea0756c2@mail.gmail.com> From: Oliver Pinter To: Robert Noland Content-Type: text/plain; charset=ISO-8859-1 Cc: "O. Hartmann" , x11@freebsd.org, stable@freebsd.org, freebsd-x11@freebsd.org Subject: Re: freebsd7, radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:07:13 -0000 this card is radeon hd3450 vgapci0@pci0:1:0:0: class=0x030000 card=0xe400174b chip=0x95c51002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'HD 3400 Series (Radeon)' class = display subclass = VGA hdac0@pci0:1:0:1: class=0x040300 card=0xaa28174b chip=0xaa281002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Radeon HD 3400 Series (3400)' class = multimedia subclass = HDA On 2/10/10, Robert Noland wrote: > On Wed, 2010-02-10 at 01:36 +0100, O. Hartmann wrote: >> On 02/10/10 00:24, Oliver Pinter wrote: >> > Hi all! >> > >> > After updated the xorg* and dri* and dependency, the system going to >> > deadlock at second start of xserver. I think it is not an uniqe issue, >> > as others wrote them at freebsd-x11: >> > http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html >> > >> > The symptoms: >> > * independent from enabled or disabled DRI or GLX, first I think, this >> > is the error, but not >> > * the system going to deadlock state >> > * no coredumps of xorgs >> > * no panic, but the system is unusuable >> > * independent from the driver: probed the radeon and radeonhd driver >> > * independent from the WITHOUT_NOUVEAU or WITH_NOUVEAU compile options >> > (make.conf) >> > * the system is: FreeBSD peonia.teteny.bme.hu 7.3-PRERELEASE FreeBSD >> > 7.3-PRERELEASE #29 r203612+fa83fdf: Mon Feb 8 02:11:08 CET 2010 >> > root@peonia.teteny.bme.hu:/usr/obj/usr/src/sys/stable amd64 >> > _______________________________________________ >> > freebsd-stable@freebsd.org mailing list, >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to >> > "freebsd-stable-unsubscribe@freebsd.org" >> >> I had a similar freezing on several FreeBSD 8.0 boxes with either >> 'radeon' or 'radeonhd/radeonhd-devel' with recent ports. With more >> expensive graphics cards, like HD4830, HD4850 we never had the issue, >> but with smaller cards, like HD4670. HD4670 never worked. HD4770 cards >> work with explicit set >> >> option "DRI" "OFF" >> >> As far as I know, WITHOUT_NOUVEAU does have no effect on the current >> ports, since it is reported in ports/UPDATING, it prevents building >> nouveau driver which is broken when using newer libdrm/dri and libGLUT, >> but those new ports do not seem to be merged into the tree. >> >> The situation is heavily unsatisfying, since one need an expensive >> AMD/ATi Radeon card to gain non-3D poor functionality, where a cheaper >> one should be do the same - but the cheaper ones don't work. Even if one >> uses AMD64, the situattion is worse and I have no reason using >> Linux-driver on a FreeBSD box. Hope the situation gets cleared in the >> nearest future. It's a kind of deadlock. As I said, either spenig a lot >> of money for a working RV770 based AMD graphics card with poor >> functionality or nothing so far, since most smaller RV730 chips aren't >> supported properly by the most recent drivers. > > I'm only aware of one issue which leads to corruption. I have patches > that resolve that issue which are not yet committed. If your are > experiencing lockups with DRI disabled, then something very strange is > going on and you will need to provide more details. I don't remember > exactly what drm code I have committed to 7 right now, but it should be > fairly current as I don't think I have much in the way of outstanding > MFCs. The current drm and radeon drivers work on every card that I > have, which in the r600 class are HD 3650,3850,4650. > > robert. > >> Regards, >> Oliver >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- > Robert Noland > FreeBSD > > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:08:22 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 224931065679 for ; Wed, 10 Feb 2010 18:08: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 CC2E58FC17 for ; Wed, 10 Feb 2010 18:08:21 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1AI8IKk005681 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 13:08:19 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Ulrich =?ISO-8859-1?Q?Sp=F6rlein?= In-Reply-To: <20100210180042.GF9748@acme.spoerlein.net> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <1265814670.8609.58.camel@balrog.2hip.net> <20100210180042.GF9748@acme.spoerlein.net> Content-Type: text/plain; charset="ISO-8859-1" Organization: FreeBSD Date: Wed, 10 Feb 2010 12:08:12 -0600 Message-Id: <1265825292.8609.81.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@FreeBSD.org, Vitaly Magerya , Oliver Pinter Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:08:22 -0000 On Wed, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote: > On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: > > I have a strong suspicion that the issue is with bus_dma. If this is a > > pci based card, then it is trying to allocate 32MB of contiguous > > physical ram when the drm device is opened. This usually succeeds the > > first time that the driver opens the device, but later, after memory has > > become fragmented, this can become an issue. As I have mentioned, I > > have code that reworks this whole process and I'll try and make a patch > > available soon, but my I don't have a lot of time now, so it might be > > the weekend before I can rebase the code and get a clean patch. > > No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without > the recent Xorg update (haven't done that yet) I usually startx right after > boot, and this usually works fine. > > One time I had massive ZFS/git jobs running headless first and wanted to > startx afterwards. X11 took quite some time to come up and although > window "switching" was snappy, *moving* windows around was slow as hell, > window contents were re-drawing at ~1FPS. > > This also seems to always happen if I stop X11 and startx it again. > So I made a diff from a regular Xorg startup against the slow one: > > --- Xorg.0.log 2010-02-09 20:59:16.000000000 +0100 > +++ Xorg.slow.log 2010-01-31 11:04:08.000000000 +0100 > ... > @@ -599,49 +599,22 @@ > (II) RADEON(0): [drm] added 1 reserved context for kernel > (II) RADEON(0): X context handle = 0x1 > (II) RADEON(0): [drm] installed DRM signal handler > -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 > -(II) RADEON(0): [pci] ring handle = 0xed1a5000 > -(II) RADEON(0): [pci] Ring mapped at 0x802aa0000 > -(II) RADEON(0): [pci] Ring contents 0x00000000 > -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 > -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 > -(II) RADEON(0): [pci] Ring read ptr contents 0x00000000 > -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 > -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c00000 > -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000 > -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 > -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 > -(II) RADEON(0): [drm] register handle = 0xfe8e0000 > -(II) RADEON(0): [dri] Visual configs initialized > +(EE) RADEON(0): [pci] Out of memory (-12) Yes, drm failed to allocate the 32MB to back the GART, so drm was disabled. Hopefully, the new allocation strategy will resolve this since it will just require 32MB of physical ram below 4GB without needing it to be contiguous. robert. > +(EE) RADEON(0): [pci] PCI failed to initialize. Disabling the DRI. > +(II) RADEON(0): [drm] removed 1 reserved context for kernel > +(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xffffff8014a6d000 at 0x8006d4000 > +(II) RADEON(0): [drm] Closed DRM master. > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x001f0000 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > (==) RADEON(0): Backing store disabled > -(II) RADEON(0): [DRI] installation complete > -(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers > -(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers > -(II) RADEON(0): [drm] dma control initialized, using IRQ 256 > -(II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 > -(WW) RADEON(0): DRI init changed memory map, adjusting ... > -(WW) RADEON(0): MC_FB_LOCATION was: 0x00ef00d0 is: 0x00ef00d0 > -(WW) RADEON(0): MC_AGP_LOCATION was: 0x003f0000 is: 0x00030000 > -(II) RADEON(0): RADEONRestoreMemMapRegisters() : > -(II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 > -(II) RADEON(0): MC_AGP_LOCATION : 0x00030000 > -(II) RADEON(0): Direct rendering enabled > -(II) RADEON(0): Setting EXA maxPitchBytes > -(II) EXA(0): Offscreen pixmap area of 111050752 bytes > -(II) EXA(0): Driver registered support for the following operations: > -(II) Solid > -(II) Copy > -(II) Composite (RENDER acceleration) > -(II) UploadToScreen > -(II) DownloadFromScreen > -(II) RADEON(0): Acceleration enabled > +(WW) RADEON(0): Direct rendering disabled > +(EE) RADEON(0): Acceleration initialization failed > +(II) RADEON(0): Acceleration disabled > (**) Option "dpms" > (**) RADEON(0): DPMS enabled > (==) RADEON(0): Silken mouse enabled > -(II) RADEON(0): Set up textured video > +(II) RADEON(0): Textured video requires CP on R5xx/R6xx/R7xx/IGP > Output CRT2 disable success > (II) RADEON(0): UNIPHY1 transmitter: Coherent Mode enabled > Output UNIPHY1 transmitter setup success > @@ -661,7 +634,7 @@ > Mode 1920x1200 - 2080 1235 9 > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 > -(II) RADEON(0): MC_AGP_LOCATION : 0x00030000 > +(II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > freq: 154000000 > best_freq: 153900000 > best_feedback_div: 57 > > > Pretty obvious what went wrong... > > Bye, > Uli > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:10:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC201106568D; Wed, 10 Feb 2010 18:10:10 +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 8C9EB8FC2A; Wed, 10 Feb 2010 18:10:09 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA07270; Wed, 10 Feb 2010 20:10:08 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B72F67F.4000209@icyb.net.ua> Date: Wed, 10 Feb 2010 20:10:07 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Ivan Voras References: <4B72D94A.8030509@icyb.net.ua> <4B72E93C.80102@icyb.net.ua> <9bbcef731002101003r203f5189xf139700a0d48afa0@mail.gmail.com> In-Reply-To: <9bbcef731002101003r203f5189xf139700a0d48afa0@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:10:10 -0000 on 10/02/2010 20:03 Ivan Voras said the following: > When you say "very unique" is it in the "it is not Linux or Windows" > sense or do we do something nonstandard? The former - neither Linux, Windows or OpenSolaris seem to have what we have. So we might be the first testers for certain processor features. We don't do anything that strays from specifications. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:12:45 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09C3E1065670; Wed, 10 Feb 2010 18:12:45 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4028FC12; Wed, 10 Feb 2010 18:12:43 +0000 (UTC) Received: by bwz3 with SMTP id 3so302685bwz.13 for ; Wed, 10 Feb 2010 10:12:43 -0800 (PST) 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=MtbpmkGLoinK16dDuHPoobYjkZfMXJOqvEb5Vyy1fkE=; b=g8un74GzY6E9xl6RfeRlJCb5RObJuk0x/1uZn/Fmd5jxcOeVonXz2X6nJAY52IID5e pKnMYv+jKOg90ahgMQkecqs1TUXOjv8HQQ7IhTX8DjbL7E7OnvYFB11UVGVNENuywmBl C53v9mztf/XplDnAukIbqtBbxtSg+KkuezTIY= 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=nTN3R0TyaYmWuIWTMEBD3J6slM0mz95Tl8j5aaFPFBIx714ioMkPJr3Iy+5fNfsKWp 7ZdgnBwm4OK2NxNBTKAXprW6Cy14QpgoQJFdaR53Z2IXb+4uXwKJOGrYL2T3nMH3xlKx H96K4TKqr5M+YwAZq0EukaiGr1cC/7XTUUiYs= MIME-Version: 1.0 Received: by 10.204.33.196 with SMTP id i4mr386789bkd.155.1265825562655; Wed, 10 Feb 2010 10:12:42 -0800 (PST) In-Reply-To: References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> Date: Wed, 10 Feb 2010 18:12:42 +0000 Message-ID: <6101e8c41002101012v4ae8a311y3780643051b6d6f7@mail.gmail.com> From: Oliver Pinter To: Masoom Shaikh Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, x11@freebsd.org, freebsd-x11@freebsd.org Subject: Re: freebsd7, radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:12:45 -0000 no, it's a desktop system, without wifi it is a asus p5q-e motherboard On 2/10/10, Masoom Shaikh wrote: > On Wed, Feb 10, 2010 at 4:54 AM, Oliver Pinter wrote: > >> Hi all! >> >> After updated the xorg* and dri* and dependency, the system going to >> deadlock at second start of xserver. I think it is not an uniqe issue, >> as others wrote them at freebsd-x11: >> http://lists.freebsd.org/pipermail/freebsd-x11/2010-February/009370.html >> >> The symptoms: >> * independent from enabled or disabled DRI or GLX, first I think, this >> is the error, but not >> * the system going to deadlock state >> * no coredumps of xorgs >> * no panic, but the system is unusuable >> * independent from the driver: probed the radeon and radeonhd driver >> * independent from the WITHOUT_NOUVEAU or WITH_NOUVEAU compile options >> (make.conf) >> * the system is: FreeBSD peonia.teteny.bme.hu 7.3-PRERELEASE FreeBSD >> 7.3-PRERELEASE #29 r203612+fa83fdf: Mon Feb 8 02:11:08 CET 2010 >> root@peonia.teteny.bme.hu:/usr/obj/usr/src/sys/stable amd64 >> _______________________________________________ >> 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" >> > > are you using intel wireless cards ? I had/having similar issues when such > freeze happens hard boot is the only option. I think it has something to do > with wlandev or something related to wpi driver. I cannot comment more since > coredumps are occasional and back trace suggests it is doadump(). > > here is my report earlier > http://lists.freebsd.org/pipermail/freebsd-questions/2009-November/207768.html > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:26:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33C45106568B; Wed, 10 Feb 2010 18:26:40 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 8FA158FC1A; Wed, 10 Feb 2010 18:26:39 +0000 (UTC) Received: by fxm24 with SMTP id 24so318932fxm.3 for ; Wed, 10 Feb 2010 10:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=rLOFHoifHpdEEeWqb6h/k7yInCX7qxnyE586LhymT5A=; b=TKxM9FY9vZCvzhftzXU3wn+bvAZ7wm0L8MGhdI4/ddlvwZ8xWoEKPFB4UaVjLYX0xK DlN3+uq4r4y8KaqjhDL2/rNxhve2dOEFtNlXQg8cCpSTUuIZUgE5RYW33y1i+OA53VHQ o9/LqoHcidmJdYmKEUF6YWICdh6vWfULKHnqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=dpNt442dYb/6ifrIVEDEf++5mmEzL2o8Hd4JwLMRm82nQDVIXoZd5eqZ+Kp3uL7IUC 3raK3d5bKeiW1LKAnl1/L6cZnb9aPHZVsTWGGR/pYhKeiIqeo0I2nOda+nOAApypW89M VOdCWCs3yO6M/0jS4d259pXwVIuSSItxVJD6s= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.89.70 with SMTP id b48mr354877wef.160.1265826398257; Wed, 10 Feb 2010 10:26:38 -0800 (PST) In-Reply-To: <4B72F67F.4000209@icyb.net.ua> References: <4B72D94A.8030509@icyb.net.ua> <4B72E93C.80102@icyb.net.ua> <9bbcef731002101003r203f5189xf139700a0d48afa0@mail.gmail.com> <4B72F67F.4000209@icyb.net.ua> From: Ivan Voras Date: Wed, 10 Feb 2010 19:26:18 +0100 X-Google-Sender-Auth: 87b0762993d2470b Message-ID: <9bbcef731002101026k5007075cqf97fc80404ac3fa7@mail.gmail.com> To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:26:40 -0000 On 10 February 2010 19:10, Andriy Gapon wrote: > on 10/02/2010 20:03 Ivan Voras said the following: >> When you say "very unique" is it in the "it is not Linux or Windows" >> sense or do we do something nonstandard? > > The former - neither Linux, Windows or OpenSolaris seem to have what we have. I can't find the exact documents but I think both Windows MegaUltimateServer (the highest priced version of Windows Server, whatever it's called today) and Linux (though disabled and marked Experimental) have it, or have some kind of support for large pages that might not be as pervasive (maybe they use it for kernel only?). I have no idea about (Open)Solaris. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:29:22 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7BA11065670; Wed, 10 Feb 2010 18:29:22 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id F3B628FC17; Wed, 10 Feb 2010 18:29:21 +0000 (UTC) Received: by fxm24 with SMTP id 24so321834fxm.3 for ; Wed, 10 Feb 2010 10:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=BvgTSJsFqCQcEy3hupnfSXkFdEbRrCqufjPj+ituxSE=; b=M1yLQwXjiRBLHDYjiJ1ExPq2WhN+CkqrPVu5Q+9AM4gmM6mXi02FH1QE9OZ/YxKY1Q 8s/8ea9tRJnE17eRWMa/IMtf0QnDx2MASxr1Kmwr2yzTp8mJSPTLFPhFkhA0HeacW99K O48izyQNcBV3g1yPuS5/K3AEUbSkbCvIjEX+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ElAsj+QsfIaHwcKdHiYxKskHnamiYxYIaCM2zyx589aLrvpwo4+61+bBEEQkaUtQxi /YzxFoR5RJanosAnHO+HHfXoXLE+SFAlr5a9Rrrz4ERMfTcF7wgRpX1EOHJC38MV3Q98 nC2tb05Zjm0CaE9qPjdTdirLFyzva+RzF7gtU= Received: by 10.223.14.89 with SMTP id f25mr815471faa.15.1265826560589; Wed, 10 Feb 2010 10:29:20 -0800 (PST) Received: from ?172.16.0.7? ([85.198.160.156]) by mx.google.com with ESMTPS id 15sm745306fxm.14.2010.02.10.10.29.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Feb 2010 10:29:19 -0800 (PST) Message-ID: <4B72FB00.3000105@gmail.com> Date: Wed, 10 Feb 2010 20:29:20 +0200 From: Vitaly Magerya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Robert Noland References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> In-Reply-To: <1265818363.8609.70.camel@balrog.2hip.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-x11@freebsd.org, stable@freebsd.org, Andriy Gapon , Oliver Pinter Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:29:22 -0000 Robert Noland wrote: >> It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; >> should I try rebuilding xorg-server with HAL? > > Yes, you can still disable hal at runtime by setting AutoAddDevices > "Off" in xorg.conf. Seems to work with HAL. Unloading radeon also works, but the kernel prints this warning: Warning: memory type drm_bufs leaked memory on destroy (4 allocations, 128 bytes leaked). And Xorg fails on start afterward with: Fatal server error: no screens found (The number of allocations and the amount of leaked memory may vary; 32 bytes per allocation is constant though). I guess this means I should not unload it. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:31:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD91B1065679; Wed, 10 Feb 2010 18:31:07 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by mx1.freebsd.org (Postfix) with ESMTP id 247508FC15; Wed, 10 Feb 2010 18:31:06 +0000 (UTC) Received: by ewy1 with SMTP id 1so40398ewy.34 for ; Wed, 10 Feb 2010 10:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=uDhNx/O1tZqi0L7fdSzVm1mCJTJVcOuA+OOpgo3hr14=; b=NgECo+iOYLigLPXm//snbCw4MqmGUhyUPIh6SJys35E0xVgxPwWo5hgQT3SX0br2H6 3wXEPvZX0iJPftR7ZAi7ntyO3rowxD5ZqCRSegNyaVYyuARMfGBD9KeLNAmRx2QIYNEQ AOW4bPv2m9AYaxZVjTkbJefryH1oJtZZMNTAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=l/ddtKm1Fpg5q4TMSYeeBDSAQx7NCD4om/PYc/uha06zUbu7VFGMPyadLonrOHfvxh /owmlLPIZzKqqHTa3jlrPBv8vWbGpUoqBz8nlpjxDo7Q1r/Xtb0jC5GHAebQ08ykCzgH mEN4GXUePwCMytUsrJ0lnTq/04wxHig5gVxd4= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.87.134 with SMTP id y6mr411421wee.20.1265826665135; Wed, 10 Feb 2010 10:31:05 -0800 (PST) In-Reply-To: <9bbcef731002101026k5007075cqf97fc80404ac3fa7@mail.gmail.com> References: <4B72D94A.8030509@icyb.net.ua> <4B72E93C.80102@icyb.net.ua> <9bbcef731002101003r203f5189xf139700a0d48afa0@mail.gmail.com> <4B72F67F.4000209@icyb.net.ua> <9bbcef731002101026k5007075cqf97fc80404ac3fa7@mail.gmail.com> From: Ivan Voras Date: Wed, 10 Feb 2010 19:30:45 +0100 X-Google-Sender-Auth: d5a55f1ef4576fe8 Message-ID: <9bbcef731002101030s119afcb6ndc9f5c9af649528c@mail.gmail.com> To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:31:07 -0000 On 10 February 2010 19:26, Ivan Voras wrote: > On 10 February 2010 19:10, Andriy Gapon wrote: >> on 10/02/2010 20:03 Ivan Voras said the following: >>> When you say "very unique" is it in the "it is not Linux or Windows" >>> sense or do we do something nonstandard? >> >> The former - neither Linux, Windows or OpenSolaris seem to have what we have. > > I can't find the exact documents but I think both Windows > MegaUltimateServer (the highest priced version of Windows Server, > whatever it's called today) and Linux (though disabled and marked > Experimental) have it, or have some kind of support for large pages > that might not be as pervasive (maybe they use it for kernel only?). I > have no idea about (Open)Solaris. VMWare documentation about large pages: http://www.vmware.com/files/pdf/large_pg_performance.pdf I think I remember reading that on Windows, the application must use a special syscall to allocate an area with large pages, but I can't find the document. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:33:53 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98035106566C; Wed, 10 Feb 2010 18:33:53 +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 711228FC17; Wed, 10 Feb 2010 18:33:51 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA07711; Wed, 10 Feb 2010 20:33:46 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B72FC0A.1020701@icyb.net.ua> Date: Wed, 10 Feb 2010 20:33:46 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Vitaly Magerya References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> In-Reply-To: <4B72FB00.3000105@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, freebsd-x11@FreeBSD.org, Robert Noland , Oliver Pinter Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:33:53 -0000 on 10/02/2010 20:29 Vitaly Magerya said the following: > Robert Noland wrote: >>> It is not, and yes I use WITHOUT_HAL. Currently disabling DRI helps; >>> should I try rebuilding xorg-server with HAL? >> Yes, you can still disable hal at runtime by setting AutoAddDevices >> "Off" in xorg.conf. > > Seems to work with HAL. I've long thought that xorg server should be linked with libthr regardless of HAL option. Unfortunately, I never came up with patch, nor have anyone else. Xorg server really uses pthreads when doing DRM and HAL brings in libthr dependency only as an accident. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:35:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32341106568D; Wed, 10 Feb 2010 18:35:05 +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 0B6808FC17; Wed, 10 Feb 2010 18:35:03 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA07753; Wed, 10 Feb 2010 20:35:02 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B72FC55.2090508@icyb.net.ua> Date: Wed, 10 Feb 2010 20:35:01 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Ivan Voras References: <4B72D94A.8030509@icyb.net.ua> <4B72E93C.80102@icyb.net.ua> <9bbcef731002101003r203f5189xf139700a0d48afa0@mail.gmail.com> <4B72F67F.4000209@icyb.net.ua> <9bbcef731002101026k5007075cqf97fc80404ac3fa7@mail.gmail.com> In-Reply-To: <9bbcef731002101026k5007075cqf97fc80404ac3fa7@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:35:05 -0000 on 10/02/2010 20:26 Ivan Voras said the following: > On 10 February 2010 19:10, Andriy Gapon wrote: >> on 10/02/2010 20:03 Ivan Voras said the following: >>> When you say "very unique" is it in the "it is not Linux or Windows" >>> sense or do we do something nonstandard? >> The former - neither Linux, Windows or OpenSolaris seem to have what we have. > > I can't find the exact documents but I think both Windows > MegaUltimateServer (the highest priced version of Windows Server, > whatever it's called today) and Linux (though disabled and marked > Experimental) have it, or have some kind of support for large pages > that might not be as pervasive (maybe they use it for kernel only?). I > have no idea about (Open)Solaris. I haven't said that those OSes do not use large pages. I've said what I've said :-) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:36:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7541A1065693 for ; Wed, 10 Feb 2010 18:36:39 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 10E048FC2D for ; Wed, 10 Feb 2010 18:36:38 +0000 (UTC) Received: (qmail 98823 invoked from network); 10 Feb 2010 18:36:38 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 10 Feb 2010 18:36:38 -0000 Message-ID: <4B72FC5A.5030100@acm.poly.edu> Date: Wed, 10 Feb 2010 13:35:06 -0500 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.23 (X11/20091021) MIME-Version: 1.0 To: Dan Langille References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> <20100209161817.GI4648@cesium.hyperfine.info> <4B718EBB.6080709@acm.poly.edu> <4B723609.8010802@langille.org> In-Reply-To: <4B723609.8010802@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Peter C. Lai" , Charles Sprickman , FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:36:39 -0000 Dan Langille wrote: > Boris Kochergin wrote: >> Peter C. Lai wrote: >>> On 2010-02-09 06:37:47AM -0500, Dan Langille wrote: >>> >>>> Charles Sprickman wrote: >>>> >>>>> On Mon, 8 Feb 2010, Dan Langille wrote: >>>>> Also, it seems like >>>>> people who use zfs (or gmirror + gstripe) generally end up buying >>>>> pricey hardware raid cards for compatibility reasons. There seem >>>>> to be no decent add-on SATA cards that play nice with FreeBSD >>>>> other than that weird supermicro card that has to be physically >>>>> hacked about to fit. >>>>> >>> >>> Mostly only because certain cards have issues w/shoddy JBOD >>> implementation. Some cards (most notably ones like Adaptec 2610A >>> which was rebranded by Dell as the "CERC SATA 1.5/6ch" back in the >>> day) won't let you run the drives in passthrough mode and seem to >>> all want to stick their grubby little RAID paws into your JBOD setup >>> (i.e. the only way to have minimal >>> participation from the "hardware" RAID is to set each disk as its >>> own RAID-0/volume in the controller BIOS) which then cascades into >>> issues with SMART, AHCI, "triple caching"/write reordering, etc on >>> the FreeBSD side (the controller's own craptastic cache, ZFS vdev >>> cache, vmm/app cache, oh my!). So *some* people go with something >>> tried-and-true (basically bordering on server-level cards that let >>> you ditch any BIOS type of RAID config and present the raw disk >>> devices to the kernel) >> As someone else has mentioned, recent SiL stuff works well. I have >> multiple >> http://www.newegg.com/Product/Product.aspx?Item=N82E16816132008 cards >> servicing RAID-Z2 and GEOM_RAID3 arrays on 8.0-RELEASE and 8.0-STABLE >> machines using both the old ata(4) driver and ATA_CAM. Don't let the >> RAID label scare you--that stuff is off by default and the controller >> just presents the disks to the operating system. Hot swap works. I >> haven't had the time to try the siis(4) driver for them, which would >> result in better performance. > > That's a really good price. :) > > If needed, I could host all eight SATA drives for $160, much cheaper > than any of the other RAID cards I've seen. > > The issue then is finding a motherboard which has 4x PCI Express > slots. ;) If you want to go this route, I bought one a while ago so that I could stuff as many dual-port Gigabit Ethernet controllers into it as possible (it was a SPAN port replicator): http://www.newegg.com/Product/Product.aspx?Item=N82E16813130136. Newegg doesn't carry it anymore, but if you can find it elsewhere, I can vouch for its stability: # uptime 1:20PM up 494 days, 5:23, 1 user, load averages: 0.05, 0.07, 0.05 In my setups with those Silicon Image cards, though, they serve as additional controllers, with the following onboard SATA controllers being used to provide most of the ports: SB600 (AMD/ATI) SB700 (AMD/ATI) ICH9 (Intel) 63XXESB2 (Intel) I haven't had any problems with any of them. -Boris From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:39:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1B6110656A4; Wed, 10 Feb 2010 18:39:00 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0AB8FC1E; Wed, 10 Feb 2010 18:38:59 +0000 (UTC) Received: by ewy3 with SMTP id 3so336281ewy.13 for ; Wed, 10 Feb 2010 10:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=X8BktFnjK8Ic+WUIGymsiGKbzIIzBAFfqLH9T5J8yNA=; b=Pqg0lg1fu6085cZ6gP7qqKZC1Jc49Nf9zElQnbVCZS7no/Hg4opgqj7Kmmzb8fJ+4b uQca3WoYkLzw1+HvnP6aygNyqDcGZAYByPC2Fp4VpSF9HgnxA3jWcMfUwQN7tLfwK+Py oyRejcKdTlwZKkK+GlmBBbeATSWFyeLUZo5Wg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=qVqi5TkFwFztGAqDN246FtnfRoDzqUmg9f5GOm9QfjcCVbHb0t59J6QkcMUS6c3YtL 1/UvVUGN7FKSckuR/iDio+UuVuhzdfOQSYckCCwZGeOdYx1JyoM+f4lNwO3O+lZG7gqH emQQBxudVzD947ddwx9UbQvB7dgZ7cZs2dPrQ= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.88.85 with SMTP id z63mr376883wee.129.1265827138285; Wed, 10 Feb 2010 10:38:58 -0800 (PST) In-Reply-To: <4B72FC55.2090508@icyb.net.ua> References: <4B72D94A.8030509@icyb.net.ua> <4B72E93C.80102@icyb.net.ua> <9bbcef731002101003r203f5189xf139700a0d48afa0@mail.gmail.com> <4B72F67F.4000209@icyb.net.ua> <9bbcef731002101026k5007075cqf97fc80404ac3fa7@mail.gmail.com> <4B72FC55.2090508@icyb.net.ua> From: Ivan Voras Date: Wed, 10 Feb 2010 19:38:37 +0100 X-Google-Sender-Auth: c2a6d550cb8d3f7c Message-ID: <9bbcef731002101038r1ac04141t505216816489376f@mail.gmail.com> To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:39:00 -0000 On 10 February 2010 19:35, Andriy Gapon wrote: > on 10/02/2010 20:26 Ivan Voras said the following: >> On 10 February 2010 19:10, Andriy Gapon wrote: >>> on 10/02/2010 20:03 Ivan Voras said the following: >>>> When you say "very unique" is it in the "it is not Linux or Windows" >>>> sense or do we do something nonstandard? >>> The former - neither Linux, Windows or OpenSolaris seem to have what we have. >> >> I can't find the exact documents but I think both Windows >> MegaUltimateServer (the highest priced version of Windows Server, >> whatever it's called today) and Linux (though disabled and marked >> Experimental) have it, or have some kind of support for large pages >> that might not be as pervasive (maybe they use it for kernel only?). I >> have no idea about (Open)Solaris. > > I haven't said that those OSes do not use large pages. > I've said what I've said :-) Ok :) Is there a difference between "large pages" as they are commonly known and "superpages" as in FreeBSD ? In other words - are you referencing some specific mechanism, like automatic promotion / demotion of the large pages or maybe something else? From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:46:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E28451065672 for ; Wed, 10 Feb 2010 18:46:42 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6628FC1A for ; Wed, 10 Feb 2010 18:46:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id D5BC950830; Wed, 10 Feb 2010 18:46:41 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay3KEgTotDDJ; Wed, 10 Feb 2010 18:46:41 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id F227150823 ; Wed, 10 Feb 2010 18:46:40 +0000 (GMT) Message-ID: <4B72FF12.5020309@langille.org> Date: Wed, 10 Feb 2010 13:46:42 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Boris Kochergin References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> <20100209161817.GI4648@cesium.hyperfine.info> <4B718EBB.6080709@acm.poly.edu> <4B723609.8010802@langille.org> <4B72FC5A.5030100@acm.poly.edu> In-Reply-To: <4B72FC5A.5030100@acm.poly.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:46:43 -0000 Boris Kochergin wrote: > Dan Langille wrote: >> Boris Kochergin wrote: >>> Peter C. Lai wrote: >>>> On 2010-02-09 06:37:47AM -0500, Dan Langille wrote: >>>> >>>>> Charles Sprickman wrote: >>>>> >>>>>> On Mon, 8 Feb 2010, Dan Langille wrote: >>>>>> Also, it seems like >>>>>> people who use zfs (or gmirror + gstripe) generally end up buying >>>>>> pricey hardware raid cards for compatibility reasons. There seem >>>>>> to be no decent add-on SATA cards that play nice with FreeBSD >>>>>> other than that weird supermicro card that has to be physically >>>>>> hacked about to fit. >>>>>> >>>> >>>> Mostly only because certain cards have issues w/shoddy JBOD >>>> implementation. Some cards (most notably ones like Adaptec 2610A >>>> which was rebranded by Dell as the "CERC SATA 1.5/6ch" back in the >>>> day) won't let you run the drives in passthrough mode and seem to >>>> all want to stick their grubby little RAID paws into your JBOD setup >>>> (i.e. the only way to have minimal >>>> participation from the "hardware" RAID is to set each disk as its >>>> own RAID-0/volume in the controller BIOS) which then cascades into >>>> issues with SMART, AHCI, "triple caching"/write reordering, etc on >>>> the FreeBSD side (the controller's own craptastic cache, ZFS vdev >>>> cache, vmm/app cache, oh my!). So *some* people go with something >>>> tried-and-true (basically bordering on server-level cards that let >>>> you ditch any BIOS type of RAID config and present the raw disk >>>> devices to the kernel) >>> As someone else has mentioned, recent SiL stuff works well. I have >>> multiple >>> http://www.newegg.com/Product/Product.aspx?Item=N82E16816132008 cards >>> servicing RAID-Z2 and GEOM_RAID3 arrays on 8.0-RELEASE and 8.0-STABLE >>> machines using both the old ata(4) driver and ATA_CAM. Don't let the >>> RAID label scare you--that stuff is off by default and the controller >>> just presents the disks to the operating system. Hot swap works. I >>> haven't had the time to try the siis(4) driver for them, which would >>> result in better performance. >> >> That's a really good price. :) >> >> If needed, I could host all eight SATA drives for $160, much cheaper >> than any of the other RAID cards I've seen. >> >> The issue then is finding a motherboard which has 4x PCI Express >> slots. ;) > If you want to go this route, I bought one a while ago so that I could > stuff as many dual-port Gigabit Ethernet controllers into it as possible > (it was a SPAN port replicator): > http://www.newegg.com/Product/Product.aspx?Item=N82E16813130136. Newegg > doesn't carry it anymore, but if you can find it elsewhere, I can vouch > for its stability: > > # uptime > 1:20PM up 494 days, 5:23, 1 user, load averages: 0.05, 0.07, 0.05 > > In my setups with those Silicon Image cards, though, they serve as > additional controllers, with the following onboard SATA controllers > being used to provide most of the ports: I don't know what the above means. I think it means you are primarily using the onboard SATA contollers and have those Silicon Image cards providing additional ports where required. > > SB600 (AMD/ATI) > SB700 (AMD/ATI) > ICH9 (Intel) > 63XXESB2 (Intel) These are the chipsets on that motherboard? > > I haven't had any problems with any of them. > > -Boris From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 18:47:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 460F71065694 for ; Wed, 10 Feb 2010 18:47:40 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 294A58FC0C for ; Wed, 10 Feb 2010 18:47:39 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta05.emeryville.ca.mail.comcast.net with comcast id gJhX1d00C1afHeLA5Jnfam; Wed, 10 Feb 2010 18:47:40 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.emeryville.ca.mail.comcast.net with comcast id gJmS1d0013S48mS8dJmWa0; Wed, 10 Feb 2010 18:46:35 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 97F1D1E3033; Wed, 10 Feb 2010 10:46:23 -0800 (PST) Date: Wed, 10 Feb 2010 10:46:23 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100210184623.GA78851@icarus.home.lan> References: <4B72D94A.8030509@icyb.net.ua> <4B72E93C.80102@icyb.net.ua> <9bbcef731002101003r203f5189xf139700a0d48afa0@mail.gmail.com> <4B72F67F.4000209@icyb.net.ua> <9bbcef731002101026k5007075cqf97fc80404ac3fa7@mail.gmail.com> <4B72FC55.2090508@icyb.net.ua> <9bbcef731002101038r1ac04141t505216816489376f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9bbcef731002101038r1ac04141t505216816489376f@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:47:40 -0000 On Wed, Feb 10, 2010 at 07:38:37PM +0100, Ivan Voras wrote: > On 10 February 2010 19:35, Andriy Gapon wrote: > > on 10/02/2010 20:26 Ivan Voras said the following: > >> On 10 February 2010 19:10, Andriy Gapon wrote: > >>> on 10/02/2010 20:03 Ivan Voras said the following: > >>>> When you say "very unique" is it in the "it is not Linux or Windows" > >>>> sense or do we do something nonstandard? > >>> The former - neither Linux, Windows or OpenSolaris seem to have what we have. > >> > >> I can't find the exact documents but I think both Windows > >> MegaUltimateServer (the highest priced version of Windows Server, > >> whatever it's called today) and Linux (though disabled and marked > >> Experimental) have it, or have some kind of support for large pages > >> that might not be as pervasive (maybe they use it for kernel only?). I > >> have no idea about (Open)Solaris. > > > > I haven't said that those OSes do not use large pages. > > I've said what I've said :-) > > Ok :) > > Is there a difference between "large pages" as they are commonly known > and "superpages" as in FreeBSD ? In other words - are you referencing > some specific mechanism, like automatic promotion / demotion of the > large pages or maybe something else? I read what Andriy wrote to mean that the way FreeBSD utilises 4MB TLB on certain models of AMD processors is broken/quirky, and on those CPUs, users should stick to vm.pmap.pg_ps_enabled="0" (loader.conf). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 19:11:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D6D7106566C for ; Wed, 10 Feb 2010 19:11:46 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id D67C28FC13 for ; Wed, 10 Feb 2010 19:11:45 +0000 (UTC) Received: (qmail 99691 invoked from network); 10 Feb 2010 19:11:44 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 10 Feb 2010 19:11:44 -0000 Message-ID: <4B730494.6080001@acm.poly.edu> Date: Wed, 10 Feb 2010 14:10:12 -0500 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.23 (X11/20091021) MIME-Version: 1.0 To: Dan Langille References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> <20100209161817.GI4648@cesium.hyperfine.info> <4B718EBB.6080709@acm.poly.edu> <4B723609.8010802@langille.org> <4B72FC5A.5030100@acm.poly.edu> <4B72FF12.5020309@langille.org> In-Reply-To: <4B72FF12.5020309@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:11:46 -0000 Dan Langille wrote: > Boris Kochergin wrote: >> Dan Langille wrote: >>> Boris Kochergin wrote: >>>> Peter C. Lai wrote: >>>>> On 2010-02-09 06:37:47AM -0500, Dan Langille wrote: >>>>> >>>>>> Charles Sprickman wrote: >>>>>> >>>>>>> On Mon, 8 Feb 2010, Dan Langille wrote: >>>>>>> Also, it seems like >>>>>>> people who use zfs (or gmirror + gstripe) generally end up >>>>>>> buying pricey hardware raid cards for compatibility reasons. >>>>>>> There seem to be no decent add-on SATA cards that play nice with >>>>>>> FreeBSD other than that weird supermicro card that has to be >>>>>>> physically hacked about to fit. >>>>>>> >>>>> >>>>> Mostly only because certain cards have issues w/shoddy JBOD >>>>> implementation. Some cards (most notably ones like Adaptec 2610A >>>>> which was rebranded by Dell as the "CERC SATA 1.5/6ch" back in the >>>>> day) won't let you run the drives in passthrough mode and seem to >>>>> all want to stick their grubby little RAID paws into your JBOD >>>>> setup (i.e. the only way to have minimal >>>>> participation from the "hardware" RAID is to set each disk as its >>>>> own RAID-0/volume in the controller BIOS) which then cascades into >>>>> issues with SMART, AHCI, "triple caching"/write reordering, etc on >>>>> the FreeBSD side (the controller's own craptastic cache, ZFS vdev >>>>> cache, vmm/app cache, oh my!). So *some* people go with something >>>>> tried-and-true (basically bordering on server-level cards that let >>>>> you ditch any BIOS type of RAID config and present the raw disk >>>>> devices to the kernel) >>>> As someone else has mentioned, recent SiL stuff works well. I have >>>> multiple >>>> http://www.newegg.com/Product/Product.aspx?Item=N82E16816132008 >>>> cards servicing RAID-Z2 and GEOM_RAID3 arrays on 8.0-RELEASE and >>>> 8.0-STABLE machines using both the old ata(4) driver and ATA_CAM. >>>> Don't let the RAID label scare you--that stuff is off by default >>>> and the controller just presents the disks to the operating system. >>>> Hot swap works. I haven't had the time to try the siis(4) driver >>>> for them, which would result in better performance. >>> >>> That's a really good price. :) >>> >>> If needed, I could host all eight SATA drives for $160, much cheaper >>> than any of the other RAID cards I've seen. >>> >>> The issue then is finding a motherboard which has 4x PCI Express >>> slots. ;) >> If you want to go this route, I bought one a while ago so that I >> could stuff as many dual-port Gigabit Ethernet controllers into it as >> possible (it was a SPAN port replicator): >> http://www.newegg.com/Product/Product.aspx?Item=N82E16813130136. >> Newegg doesn't carry it anymore, but if you can find it elsewhere, I >> can vouch for its stability: >> >> # uptime >> 1:20PM up 494 days, 5:23, 1 user, load averages: 0.05, 0.07, 0.05 >> >> In my setups with those Silicon Image cards, though, they serve as >> additional controllers, with the following onboard SATA controllers >> being used to provide most of the ports: > > I don't know what the above means. > > I think it means you are primarily using the onboard SATA contollers > and have those Silicon Image cards providing additional ports where > required. Correct. > >> >> SB600 (AMD/ATI) >> SB700 (AMD/ATI) >> ICH9 (Intel) >> 63XXESB2 (Intel) > > These are the chipsets on that motherboard? Those are the SATA controller chipsets. Here are the corresponding chipsets advertised on the motherboards, in north bridge/south bridge form: SB600 SATA: AMD 770/AMD SB600 SB700 SATA: AMD SR5690/AMD SP5100 ICH9 SATA: Intel 3200/Intel ICH9 63XXESB2 SATA: Intel 5000X/Intel ESB2 -Boris > >> >> I haven't had any problems with any of them. >> >> -Boris > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 19:39:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA4CA1065670 for ; Wed, 10 Feb 2010 19:39:49 +0000 (UTC) (envelope-from davidn04@gmail.com) Received: from mail-qy0-f189.google.com (mail-qy0-f189.google.com [209.85.221.189]) by mx1.freebsd.org (Postfix) with ESMTP id 917B58FC1A for ; Wed, 10 Feb 2010 19:39:49 +0000 (UTC) Received: by qyk27 with SMTP id 27so349222qyk.3 for ; Wed, 10 Feb 2010 11:39:48 -0800 (PST) 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=AlGCoa7BpO5jg4jl8rnXE8vE0uMdf6z9ZHNDhszV8yc=; b=BQC18CtwAtn76wAsBwkH4U2eNHIw/cgADvuZiBNpSFev74mSKy9e4ak/DT5uziOk8l HRJBEXEBO1AefxnaSpWgtpfdiYSK36rV4KXOp7XqLCL0vqPp8mU1HFtKAtRPNXdghaeF SI9o5glkovAdD4fXVwJylkddU1dNFKh0S13pg= 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=t6E57w6OCVvBJThq8T4JhlgczLcWmWhROIcxnl8DiDHXYycDbYMxs5maMOaaHGktMP YieIZNDPYQzcD/rcLa2+SOOn7SW1uA9BsOzxZj6T3UysHBE92PfV0fjdKHykoVfRjDk4 EO81oacMFweFz8NMPykKEqgIXZ7ppWQQVN3/4= MIME-Version: 1.0 Received: by 10.229.192.207 with SMTP id dr15mr356910qcb.1.1265829003656; Wed, 10 Feb 2010 11:10:03 -0800 (PST) In-Reply-To: References: <4B6F9A8D.4050907@langille.org> <201002081556.54782.doconnor@gsoft.com.au> <20100209053002.GA9449@over-yonder.net> Date: Thu, 11 Feb 2010 06:10:03 +1100 Message-ID: <4d7dd86f1002101110v3152c284gf639966878c31395@mail.gmail.com> From: David N To: Christian Weisgerber Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:39:49 -0000 On 10 February 2010 08:33, Christian Weisgerber wrote: > Matthew D. Fuller wrote: > >> > I have something similar (5x1Tb) - I have a Gigabyte GA-MA785GM-US2H >> > with an Athlon X2 and 4Gb of RAM (only half filled - 2x2Gb) >> > >> > Note that it doesn't support ECC, I don't know if that is a problem. >> >> How's that? =A0Is the BIOS just stupid, or is the board physically >> missing traces? > > Doesn't matter really, does it? > > I have a GA-MA78G-DS3H. =A0According to the specs, it supports ECC > memory. =A0And that is all the mention of ECC you will find anywhere. > There is nothing in the BIOS. =A0My best guess is that they quite > literally mean that you can plug ECC memory into the board and it > will work, but that there are no provisions to actually use ECC. > > That said, I also have an Asus M2N-SLI Deluxe. =A0If I enable ECC in > the BIOS, the board locks up sooner or later, even when just sitting > in the BIOS. =A0memtest86 dies a screaming death immediately. =A0When > I disable ECC, the board is solid, both in actual use and with > memtest. > > I thought if I built a PC from components, I'd be already a step > above the lowest dregs of the consumer market, but apparently not. > > -- > Christian "naddy" Weisgerber =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0naddy@mips.inka.de > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > I had an M2A-VM HDMI that had the ECC problem, ASUS released a BIOS update for it, not sure for the M2N if they fixed that problem. >From what I've seen, most ASUS boards have the ECC option, dont take my word for it though. Regards David N From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 19:39:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E45AA106566C for ; Wed, 10 Feb 2010 19:39:52 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8EFD88FC08 for ; Wed, 10 Feb 2010 19:39:52 +0000 (UTC) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta14.westchester.pa.mail.comcast.net with comcast id gFpU1d00K0bG4ec5EKfsxc; Wed, 10 Feb 2010 19:39:52 +0000 Received: from [10.0.0.51] ([71.199.122.142]) by omta03.westchester.pa.mail.comcast.net with comcast id gKfr1d00l34Sj4f3PKfsNG; Wed, 10 Feb 2010 19:39:52 +0000 Message-ID: <4B730B94.1050205@comcast.net> Date: Wed, 10 Feb 2010 14:40:04 -0500 From: Steve Polyack User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dan Langille References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> <4B71AED5.4030002@wensing.org> <201002091949.o19JntPo009017@apollo.backplane.com> <4B723DF9.3070105@langille.org> In-Reply-To: <4B723DF9.3070105@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:39:53 -0000 On 2/10/2010 12:02 AM, Dan Langille wrote: > Trying to make sense of stuff I don't know about... > > Matthew Dillon wrote: >> >> AHCI on-motherboard with equivalent capabilities do not appear to be >> in wide distribution yet. Most AHCI chips can do NCQ to a single >> target (even a single target behind a PM), but not concurrently to >> multiple targets behind a port multiplier. Even though SATA >> bandwidth >> constraints might seem to make this a reasonable alternative it >> actually isn't because any seek heavy activity to multiple drives >> will be serialized and perform EXTREMELY poorly. Linear performance >> will be fine. Random performance will be horrible. > > Don't use a port multiplier and this goes away. I was hoping to avoid > a PM and using something like the Syba PCI Express SATA II 4 x Ports > RAID Controller seems to be the best solution so far. > > http://www.amazon.com/Syba-Express-Ports-Controller-SY-PEX40008/dp/B002R0DZWQ/ref=sr_1_22?ie=UTF8&s=electronics&qid=1258452902&sr=1-22 > Dan, I can personally vouch for these cards under FreeBSD. We have 3 of them in one system, with almost every port connected to a port multiplier (SiI5xxx PMs). Using the siis(4) driver on 8.0-RELEASE provides very good performance, and supports both NCQ and FIS-based switching (an essential for decent port-multiplier performance). One thing to consider, however, is that the card is only single-lane PCI-Express. The bandwidth available is only 2.5Gb/s (~312MB/sec, slightly less than that of the SATA-2 link spec), so if you have 4 high-performance drives connected, you may hit a bottleneck at the bus. I'd be particularly interested if anyone can find any similar Silicon Image SATA controllers with a PCI-E 4x or 8x interface ;) > >> >> It should be noted that while hotswap is supported with silicon >> image >> chipsets and port multiplier enclosures (which also use Sili >> chips in >> the enclosure), the hot-swap capability is not anywhere near as >> robust >> as you would find with a more costly commercial SAS setup. SI chips >> are very poorly made (this is the same company that went bust under >> another name a few years back due to shoddy chipsets), and have a >> lot >> of on-chip hardware bugs, but fortunately OSS driver writers (linux >> guys) have been able to work around most of them. So even though >> the >> chipset is a bit shoddy actual operation is quite good. However, >> this does mean you generally want to idle all activity on the >> enclosure >> to safely hot swap anything, not just the drive you are pulling out. >> I've done a lot of testing and hot-swapping an idle disk while other >> drives in the same enclosure are hot is not reliable (for a cheap >> port >> multiplier enclosure using a Sili chip inside, which nearly all do). > > I haven't had such bad experience as the above, but it is certainly a concern. Using ZFS we simply 'offline' the device, pull, replace with a new one, glabel, and zfs replace. It seems to work fine as long as nothing is accessing the device you are replacing (otherwise you will get a kernel panic a few minutes down the line). mav@FreeBSD.org has also committed a large patch set to 9-CURRENT which implements "proper" SATA/AHCI hot-plug support and error-recovery through CAM. -Steve Polyack From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 20:06:50 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B07FA1065694; Wed, 10 Feb 2010 20:06:50 +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 6B8CE8FC24; Wed, 10 Feb 2010 20:06:50 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1AK6eah006445 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 15:06:43 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Peter Jeremy In-Reply-To: <20100210195811.GA59533@server.vk2pj.dyndns.org> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> <4B72FC0A.1020701@icyb.net.ua> <20100210195811.GA59533@server.vk2pj.dyndns.org> Content-Type: text/plain Organization: FreeBSD Date: Wed, 10 Feb 2010 14:06:33 -0600 Message-Id: <1265832393.8609.100.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@FreeBSD.org, Oliver Pinter , Andriy Gapon , freebsd-x11@FreeBSD.org, Vitaly Magerya Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:06:50 -0000 On Thu, 2010-02-11 at 06:58 +1100, Peter Jeremy wrote: > On 2010-Feb-10 20:33:46 +0200, Andriy Gapon wrote: > >I've long thought that xorg server should be linked with libthr regardless of HAL > >option. Unfortunately, I never came up with patch, nor have anyone else. > >Xorg server really uses pthreads when doing DRM and HAL brings in libthr > >dependency only as an accident. > > Try Ports/139011 - this adds an option to enable GLX TLS - which > appears to be the underlying problem. GLX TLS, just plain does not work on FreeBSD. It has to be enabled in both the server and mesa and just makes bad things happen. I can make it all build, but having it actually work is a whole other matter. robert. > http://www.freebsd.org/cgi/query-pr.cgi?pr=139011 > -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 20:17:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90F411065670 for ; Wed, 10 Feb 2010 20:17:01 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from mail.kc8onw.net (kc8onw.net [206.55.209.81]) by mx1.freebsd.org (Postfix) with ESMTP id 68A468FC12 for ; Wed, 10 Feb 2010 20:17:00 +0000 (UTC) Received: from [128.211.161.202] (pal-161-202.itap.purdue.edu [128.211.161.202]) by mail.kc8onw.net (Postfix) with ESMTPSA id 141AC8A055 for ; Wed, 10 Feb 2010 15:17:00 -0500 (EST) Message-ID: <4B73143C.1050105@kc8onw.net> Date: Wed, 10 Feb 2010 15:17:00 -0500 From: Jonathan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B6F9A8D.4050907@langille.org> In-Reply-To: <4B6F9A8D.4050907@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:17:01 -0000 On 2/8/2010 12:01 AM, Dan Langille wrote: > Hi, > > I'm thinking of 8x1TB (or larger) SATA drives. I've found a case[2] with > hot-swap bays[3], that seems interesting. I haven't looked at power > supplies, but given that number of drives, I expect something beefy with > a decent reputation is called for. I have a system with two of these [1] and an 8 port LSI SAS card that runs fine for me. I run an 8 drive ZFS array off the LSI card and then have 2 drives mirrored off the motherboard SATA ports for booting with ZFS. Hotswap works fine for me as well with this hardware. Jonathan http://www.newegg.com/Product/Product.aspx?Item=N82E16816215001 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 20:20:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D11C51065676 for ; Wed, 10 Feb 2010 20:20:39 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 5A1EA8FC1B for ; Wed, 10 Feb 2010 20:20:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id o1AKKbJ4008355; Wed, 10 Feb 2010 23:20:37 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Wed, 10 Feb 2010 23:20:37 +0300 (MSK) From: Dmitry Morozovsky To: Dan Langille In-Reply-To: <4B6F9A8D.4050907@langille.org> Message-ID: References: <4B6F9A8D.4050907@langille.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Wed, 10 Feb 2010 23:20:37 +0300 (MSK) Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:20:39 -0000 On Mon, 8 Feb 2010, Dan Langille wrote: DL> I'm looking at creating a large home use storage machine. Budget is a DL> concern, but size and reliability are also a priority. Noise is also a DL> concern, since this will be at home, in the basement. That, and cost, DL> pretty much rules out a commercial case, such as a 3U case. It would be DL> nice, but it greatly inflates the budget. This pretty much restricts me to DL> a tower case. [snip] We use the following at work, but it's still pretty cheap and pretty silent: Chieftec WH-02B-B (9x5.25 bays) filled with 2 x Supermicro CSE-MT35T http://www.supermicro.nl/products/accessories/mobilerack/CSE-M35T-1.cfm for regular storage, 2 x raidz1 1 x Promise SuperSwap 1600 http://www.promise.com/product/product_detail_eng.asp?product_id=169 for changeable external backups and still have 2 5.25 bays for anything interesting ;-) other parts are regular SocketAM2+ motherboard, Athlon X4, 8G ram, FreeBSD/amd64 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 20:24:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0220B1065670 for ; Wed, 10 Feb 2010 20:24:14 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 7EFCC8FC0C for ; Wed, 10 Feb 2010 20:24:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id o1AKOCw0008444; Wed, 10 Feb 2010 23:24:12 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Wed, 10 Feb 2010 23:24:12 +0300 (MSK) From: Dmitry Morozovsky To: Dan Langille In-Reply-To: Message-ID: References: <4B6F9A8D.4050907@langille.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Wed, 10 Feb 2010 23:24:12 +0300 (MSK) Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:24:14 -0000 On Wed, 10 Feb 2010, Dmitry Morozovsky wrote: DM> other parts are regular SocketAM2+ motherboard, Athlon X4, 8G ram, DM> FreeBSD/amd64 well, not exactly "regular" - it's ASUS M2N-LR-SATA with 10 SATA channels, but I suppose there are comparable in "workstation" mobo market now... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 20:47:12 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 425DE1065676; Wed, 10 Feb 2010 20:47:12 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id B9BFB8FC18; Wed, 10 Feb 2010 20:47:11 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o1AKkru2085174; Wed, 10 Feb 2010 21:47:08 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o1AKkrvj085173; Wed, 10 Feb 2010 21:46:53 +0100 (CET) (envelope-from olli) Date: Wed, 10 Feb 2010 21:46:53 +0100 (CET) Message-Id: <201002102046.o1AKkrvj085173@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, amdmi3@amdmi3.ru In-Reply-To: X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 10 Feb 2010 21:47:08 +0100 (CET) Cc: Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:47:12 -0000 Dmitry Marakasov wrote: > I think I've reported that before, the I thought it's been fixed, > however I still get data corruptions when writing on NFS volumes. > Now I wonder - is nobody really using NFS, or do I have that much > of uncommon setup, or this is some kind of local problem? NFS works fine for me. I'm using -stable, not -release, though. > Client: 8.0-RELEASE i386 > Server: 8.0-RELEASE amd64 > > mount options: > nfs rw,nosuid,noexec,nfsv3,intr,soft,tcp,bg,nolockd I recommend not using the "soft" option. This is an excerpt from Solaris' mount_nfs(1M) manpage: File systems that are mounted read-write or that con- tain executable files should always be mounted with the hard option. Applications using soft mounted file systems may incur unexpected I/O errors, file corrup- tion, and unexpected program core dumps. The soft option is not recommended. FreeBSD's manual page doesn't contain such a warning, but maybe it should. (It contains a warning not to use "soft" with NFSv4, though, for different reasons.) Also note that the "nolockd" option means that processes on different clients won't see each other's locks. That means that you will get corruption if they rely on locking. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Perl will consistently give you what you want, unless what you want is consistency." -- Larry Wall From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 21:00:13 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C27ED1065694 for ; Wed, 10 Feb 2010 21:00:13 +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 8069E8FC16 for ; Wed, 10 Feb 2010 21:00:13 +0000 (UTC) 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 o1AL08s0087835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Feb 2010 15:00:08 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.3) with ESMTP id o1AL08Ib019365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Feb 2010 15:00:08 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o1AL0776019363; Wed, 10 Feb 2010 15:00:07 -0600 (CST) (envelope-from dan) Date: Wed, 10 Feb 2010 15:00:07 -0600 From: Dan Nelson To: Ruslan Ermilov , stable@freebsd.org Message-ID: <20100210210007.GB9318@dan.emsphone.com> References: <20100210085814.GE9748@acme.spoerlein.net> <20100210104904.GA85373@edoofus.dev.vega.ru> <20100210180535.GG9748@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100210180535.GG9748@acme.spoerlein.net> X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at 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]); Wed, 10 Feb 2010 15:00:11 -0600 (CST) X-Scanned-By: MIMEDefang 2.45 Cc: Subject: Re: numeric sort(1) is broken on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 21:00:13 -0000 In the last episode (Feb 10), Ulrich Spörlein said: > On Wed, 10.02.2010 at 13:49:05 +0300, Ruslan Ermilov wrote: > > On Wed, Feb 10, 2010 at 09:58:14AM +0100, Ulrich Spörlein wrote: > > > not sure if this is a pilot error, but it seems to me that gnu sort -n > > > is broken on at least -STABLE (couldn't test -CURRENT yet). > > > > > > It somehow does not manifest when using a simple list and sorting on a > > > specific column, but it always happens to me when using it in > > > combination with find(1). > > > > > > % truncate -s10m a; truncate -s5m b; truncate -s800k c > > > % find a b c -ls|sort -nk7,7 > > > 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a > > > 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b > > > 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c > > > > I bet you're using some non-C locale for LC_NUMERIC. What does "locale" > > output tell you? > > Yes and no. LC_NUMERIC is still at C, LC_CTYPE is set to UTF-8, but as > there are no non-ASCII symbols in that output it shouldn't matter, right? > For me, 819200 is smaller than 10485760 in pretty much all locales. Why > the hell is a numeric gnusort locale dependant? Why is -g working anyway? Try adding a 'b' to your sort flags. I bet the leading spaces in front of your numbers are being treated as part of the sort key. Maybe de_DE.UTF-8 and C have different ideas of what is whitespace? -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 21:05:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3E45106568B for ; Wed, 10 Feb 2010 21:05:58 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id A8D7D8FC13 for ; Wed, 10 Feb 2010 21:05:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 1198050842; Wed, 10 Feb 2010 21:05:58 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uao+4TbJuwiZ; Wed, 10 Feb 2010 21:05:57 +0000 (GMT) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 19F8450823 ; Wed, 10 Feb 2010 21:05:57 +0000 (GMT) Message-ID: <4B731FB5.8010304@langille.org> Date: Wed, 10 Feb 2010 16:05:57 -0500 From: Dan Langille User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dmitry Morozovsky References: <4B6F9A8D.4050907@langille.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 21:05:58 -0000 Dmitry Morozovsky wrote: > On Wed, 10 Feb 2010, Dmitry Morozovsky wrote: > > DM> other parts are regular SocketAM2+ motherboard, Athlon X4, 8G ram, > DM> FreeBSD/amd64 > > well, not exactly "regular" - it's ASUS M2N-LR-SATA with 10 SATA channels, but > I suppose there are comparable in "workstation" mobo market now... 10 SATA channels? Newegg claims only 6: http://www.newegg.com/Product/Product.aspx?Item=N82E16813131134 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 21:32:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23441106566B for ; Wed, 10 Feb 2010 21:32:17 +0000 (UTC) (envelope-from mik@pc.dk) Received: from pqueueb.post.tele.dk (pqueueb.post.tele.dk [193.162.153.10]) by mx1.freebsd.org (Postfix) with ESMTP id D80378FC18 for ; Wed, 10 Feb 2010 21:32:16 +0000 (UTC) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by pqueueb.post.tele.dk (Postfix) with ESMTP id 01A7780B2 for ; Wed, 10 Feb 2010 22:07:14 +0100 (CET) Received: from alpha.miknet.dk (0x5738c19d.rdnqu2.dynamic.dsl.tele.dk [87.56.193.157]) by pfepa.post.tele.dk (Postfix) with ESMTP id 9867FA50054 for ; Wed, 10 Feb 2010 22:06:47 +0100 (CET) Date: Wed, 10 Feb 2010 22:05:08 +0100 From: Martin Kristensen To: freebsd-stable@freebsd.org Message-ID: <20100210220508.790ee773@alpha.miknet.dk> In-Reply-To: <4B72FC0A.1020701@icyb.net.ua> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> <4B72FC0A.1020701@icyb.net.ua> Organization: Private X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 21:32:17 -0000 On Wed, 10 Feb 2010 20:33:46 +0200 Andriy Gapon wrote: > on 10/02/2010 20:29 Vitaly Magerya said the following: > > Robert Noland wrote: > >>> It is not, and yes I use WITHOUT_HAL. Currently disabling DRI > >>> helps; should I try rebuilding xorg-server with HAL? > >> Yes, you can still disable hal at runtime by setting AutoAddDevices > >> "Off" in xorg.conf. > > > > Seems to work with HAL. > > I've long thought that xorg server should be linked with libthr > regardless of HAL option. Unfortunately, I never came up with patch, > nor have anyone else. Xorg server really uses pthreads when doing DRM > and HAL brings in libthr dependency only as an accident. > This is my first post to this list, so hello all. I have been running with NoAccel for a long time, since disabling DRI alone would cause a complete deadlock (screen to standby, no ssh, no response to keyboard, etc.). However, I rebuilt xorg-server with HAL support, and now simply disabling DRI allows me to start X. The card is RV790 based. -- Martin Kristensen From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 21:50:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 237F7106566B; Wed, 10 Feb 2010 21:50:09 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from k7.mavetju.org (ppp113-58.static.internode.on.net [150.101.113.58]) by mx1.freebsd.org (Postfix) with ESMTP id C7B858FC0A; Wed, 10 Feb 2010 21:50:08 +0000 (UTC) Received: by k7.mavetju.org (Postfix, from userid 1001) id 1E66B45186; Thu, 11 Feb 2010 08:30:58 +1100 (EST) Date: Thu, 11 Feb 2010 08:30:58 +1100 From: Edwin Groothuis To: Igor Mozolevsky Message-ID: <20100210213058.GA24555@mavetju.org> References: <4B72A0DB.5010806@eng.auth.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable , freebsd-doc@freebsd.org, George Mamalakis Subject: Re: A more secure approach of jail establishment. It could be included in jail chapter of fbsd handbook X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 21:50:09 -0000 On Wed, Feb 10, 2010 at 01:10:32PM +0000, Igor Mozolevsky wrote: > I see people are still installing a full blown OS inside their jails? > You do know that it is possible to have a jail with a single program > inside and not much else, as if it were chroot()ed? There are two different kind of purposes for jails: First one is the isolation of single processes, the other one is the isolation of environments. For the first one you are right on the ball on, for the second one you still need the whole userland. Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 21:57:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66204106566B for ; Wed, 10 Feb 2010 21:57:55 +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 246E68FC1B for ; Wed, 10 Feb 2010 21:57:54 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1ALvnlb007175 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 16:57:52 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Martin Kristensen In-Reply-To: <20100210220508.790ee773@alpha.miknet.dk> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> <4B72FC0A.1020701@icyb.net.ua> <20100210220508.790ee773@alpha.miknet.dk> Content-Type: text/plain Organization: FreeBSD Date: Wed, 10 Feb 2010 15:57:42 -0600 Message-Id: <1265839062.8609.101.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 21:57:55 -0000 On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: > On Wed, 10 Feb 2010 20:33:46 +0200 > Andriy Gapon wrote: > > > on 10/02/2010 20:29 Vitaly Magerya said the following: > > > Robert Noland wrote: > > >>> It is not, and yes I use WITHOUT_HAL. Currently disabling DRI > > >>> helps; should I try rebuilding xorg-server with HAL? > > >> Yes, you can still disable hal at runtime by setting AutoAddDevices > > >> "Off" in xorg.conf. > > > > > > Seems to work with HAL. > > > > I've long thought that xorg server should be linked with libthr > > regardless of HAL option. Unfortunately, I never came up with patch, > > nor have anyone else. Xorg server really uses pthreads when doing DRM > > and HAL brings in libthr dependency only as an accident. > > > > This is my first post to this list, so hello all. > > I have been running with NoAccel for a long time, since disabling DRI > alone would cause a complete deadlock (screen to standby, no ssh, no > response to keyboard, etc.). > > However, I rebuilt xorg-server with HAL support, and now simply > disabling DRI allows me to start X. > > The card is RV790 based. Is that an HD5xxx? robert. -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 22:02:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C18E81065676 for ; Wed, 10 Feb 2010 22:02:12 +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 809668FC1A for ; Wed, 10 Feb 2010 22:02:12 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1AM24qL007220 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 17:02:10 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Martin Kristensen In-Reply-To: <20100210220508.790ee773@alpha.miknet.dk> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> <4B72FC0A.1020701@icyb.net.ua> <20100210220508.790ee773@alpha.miknet.dk> Content-Type: text/plain Organization: FreeBSD Date: Wed, 10 Feb 2010 16:01:58 -0600 Message-Id: <1265839318.8609.104.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 22:02:12 -0000 On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: > On Wed, 10 Feb 2010 20:33:46 +0200 > Andriy Gapon wrote: > > > on 10/02/2010 20:29 Vitaly Magerya said the following: > > > Robert Noland wrote: > > >>> It is not, and yes I use WITHOUT_HAL. Currently disabling DRI > > >>> helps; should I try rebuilding xorg-server with HAL? > > >> Yes, you can still disable hal at runtime by setting AutoAddDevices > > >> "Off" in xorg.conf. > > > > > > Seems to work with HAL. > > > > I've long thought that xorg server should be linked with libthr > > regardless of HAL option. Unfortunately, I never came up with patch, > > nor have anyone else. Xorg server really uses pthreads when doing DRM > > and HAL brings in libthr dependency only as an accident. > > > > This is my first post to this list, so hello all. > > I have been running with NoAccel for a long time, since disabling DRI > alone would cause a complete deadlock (screen to standby, no ssh, no > response to keyboard, etc.). > > However, I rebuilt xorg-server with HAL support, and now simply > disabling DRI allows me to start X. > > The card is RV790 based. Just checked... This card should work with Accel and DRI... At least on -CURRENT with updated ports. Check UPDATING, and set WITHOUT_NOUVEAU to get correct version of libdrm. robert. -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 22:06:58 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29EAE106566B for ; Wed, 10 Feb 2010 22:06:58 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id CB0EF8FC0C for ; Wed, 10 Feb 2010 22:06:56 +0000 (UTC) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1AJwK1F025983 for ; Thu, 11 Feb 2010 06:58:20 +1100 Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1AJwEIL010234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 06:58:17 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o1AJwBXA059569; Thu, 11 Feb 2010 06:58:11 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o1AJwBnc059568; Thu, 11 Feb 2010 06:58:11 +1100 (EST) (envelope-from peter) Date: Thu, 11 Feb 2010 06:58:11 +1100 From: Peter Jeremy To: Andriy Gapon Message-ID: <20100210195811.GA59533@server.vk2pj.dyndns.org> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> <4B72FC0A.1020701@icyb.net.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <4B72FC0A.1020701@icyb.net.ua> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@FreeBSD.org, Oliver Pinter , Vitaly Magerya , Robert Noland , freebsd-x11@FreeBSD.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 22:06:58 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-10 20:33:46 +0200, Andriy Gapon wrote: >I've long thought that xorg server should be linked with libthr regardless= of HAL >option. Unfortunately, I never came up with patch, nor have anyone else. >Xorg server really uses pthreads when doing DRM and HAL brings in libthr >dependency only as an accident. Try Ports/139011 - this adds an option to enable GLX TLS - which appears to be the underlying problem. =20 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D139011 --=20 Peter Jeremy --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktzD9MACgkQ/opHv/APuIfa4gCeP9TiFTRFTuEuy1cyXN2SW+9a cacAoJe++JPJz9ZqWyejs1tPOWZY4T7I =cCwl -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 22:36:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D8EA10656B5 for ; Wed, 10 Feb 2010 22:36:42 +0000 (UTC) (envelope-from mik@pc.dk) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by mx1.freebsd.org (Postfix) with ESMTP id C47FA8FC16 for ; Wed, 10 Feb 2010 22:36:41 +0000 (UTC) Received: from alpha.miknet.dk (0x5738c19d.rdnqu2.dynamic.dsl.tele.dk [87.56.193.157]) by pfepa.post.tele.dk (Postfix) with ESMTP id 40CC4A5001C for ; Wed, 10 Feb 2010 23:36:15 +0100 (CET) Date: Wed, 10 Feb 2010 23:34:52 +0100 From: Martin Kristensen To: freebsd-stable@freebsd.org Message-ID: <20100210233452.26e48f7e@alpha.miknet.dk> In-Reply-To: <1265839062.8609.101.camel@balrog.2hip.net> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> <4B72FC0A.1020701@icyb.net.ua> <20100210220508.790ee773@alpha.miknet.dk> <1265839062.8609.101.camel@balrog.2hip.net> Organization: Private X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 22:36:42 -0000 On Wed, 10 Feb 2010 15:57:42 -0600 Robert Noland wrote: > On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: > > On Wed, 10 Feb 2010 20:33:46 +0200 > > Andriy Gapon wrote: > > > > > on 10/02/2010 20:29 Vitaly Magerya said the following: > > > > Robert Noland wrote: > > > >>> It is not, and yes I use WITHOUT_HAL. Currently disabling DRI > > > >>> helps; should I try rebuilding xorg-server with HAL? > > > >> Yes, you can still disable hal at runtime by setting > > > >> AutoAddDevices "Off" in xorg.conf. > > > > > > > > Seems to work with HAL. > > > > > > I've long thought that xorg server should be linked with libthr > > > regardless of HAL option. Unfortunately, I never came up with > > > patch, nor have anyone else. Xorg server really uses pthreads > > > when doing DRM and HAL brings in libthr dependency only as an > > > accident. > > > > > > > This is my first post to this list, so hello all. > > > > I have been running with NoAccel for a long time, since disabling > > DRI alone would cause a complete deadlock (screen to standby, no > > ssh, no response to keyboard, etc.). > > > > However, I rebuilt xorg-server with HAL support, and now simply > > disabling DRI allows me to start X. > > > > The card is RV790 based. > > Is that an HD5xxx? > > robert. > > No, HD4890. -- Martin Kristensen From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 22:44:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A89D10656C5 for ; Wed, 10 Feb 2010 22:44:48 +0000 (UTC) (envelope-from mik@pc.dk) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by mx1.freebsd.org (Postfix) with ESMTP id 254018FC0C for ; Wed, 10 Feb 2010 22:44:47 +0000 (UTC) Received: from alpha.miknet.dk (0x5738c19d.rdnqu2.dynamic.dsl.tele.dk [87.56.193.157]) by pfepa.post.tele.dk (Postfix) with ESMTP id C8511A50039 for ; Wed, 10 Feb 2010 23:44:37 +0100 (CET) Date: Wed, 10 Feb 2010 23:43:15 +0100 From: Martin Kristensen To: freebsd-stable@freebsd.org Message-ID: <20100210234315.7abde83c@alpha.miknet.dk> In-Reply-To: <1265839318.8609.104.camel@balrog.2hip.net> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> <4B72FC0A.1020701@icyb.net.ua> <20100210220508.790ee773@alpha.miknet.dk> <1265839318.8609.104.camel@balrog.2hip.net> Organization: Private X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 22:44:48 -0000 On Wed, 10 Feb 2010 16:01:58 -0600 Robert Noland wrote: > On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: > > On Wed, 10 Feb 2010 20:33:46 +0200 > > Andriy Gapon wrote: > > > > > on 10/02/2010 20:29 Vitaly Magerya said the following: > > > > Robert Noland wrote: > > > >>> It is not, and yes I use WITHOUT_HAL. Currently disabling DRI > > > >>> helps; should I try rebuilding xorg-server with HAL? > > > >> Yes, you can still disable hal at runtime by setting > > > >> AutoAddDevices "Off" in xorg.conf. > > > > > > > > Seems to work with HAL. > > > > > > I've long thought that xorg server should be linked with libthr > > > regardless of HAL option. Unfortunately, I never came up with > > > patch, nor have anyone else. Xorg server really uses pthreads > > > when doing DRM and HAL brings in libthr dependency only as an > > > accident. > > > > > > > This is my first post to this list, so hello all. > > > > I have been running with NoAccel for a long time, since disabling > > DRI alone would cause a complete deadlock (screen to standby, no > > ssh, no response to keyboard, etc.). > > > > However, I rebuilt xorg-server with HAL support, and now simply > > disabling DRI allows me to start X. > > > > The card is RV790 based. > > Just checked... This card should work with Accel and DRI... At least > on -CURRENT with updated ports. Check UPDATING, and set > WITHOUT_NOUVEAU to get correct version of libdrm. > > robert. > I am on -STABLE built on Jan. 19. I updated mesa today (to libdrm-2.4.17), and rebuilt xorg-server and drivers. I have WITHOUT_NOUVEAU="YES" in /etc/make.conf. pkg_info reports libGL-7.6.1. I have tried loading radeon.ko manually before startx. If it will help, I can switch to -CURRENT to see if that changes anything. Martin PS. Robert, in researching this I got some idea of the effort you put into this, thanks! -- Martin Kristensen From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 23:09:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E15210656FF for ; Wed, 10 Feb 2010 23:09:22 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id B102F8FC16 for ; Wed, 10 Feb 2010 23:09:21 +0000 (UTC) Received: by bwz3 with SMTP id 3so571846bwz.13 for ; Wed, 10 Feb 2010 15:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=WW7YhgK/pbaQIjVVpUx1JA3U8kNHeUM5LeaFSvVETg8=; b=Ssg6GXyHI1hdBbLnOvKMDvioj42zDWRAJ1QHeZ7745QVTCoLdQ9liSFVnFXR6vcTyP M+OVKzhf6JKiMbmoLXnKS658kEm3YeQvI2E0ZDkLn/BDUEoNov+eLQ7M4g0gkEwqANrh FlDcCd7DBBu7iI31TNs5bjzlBtQ/51Wdss0RI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=BuS6/Af1rpfFtRV6aT11J0l82u44BUGQhZalxDggu6wlya3qjYislWD/aIdHEGm+6G CmCaS0uMH++Pvh6vKJTAyHAIqL83JXR4wz6or0JBLiUh/3IroE/jYQ6RuxpGPK02PUfo 9HAhjCP1sY6iRkmjAjYxYH4Vsol9WxZEdpXg8= MIME-Version: 1.0 Received: by 10.204.3.207 with SMTP id 15mr622588bko.91.1265843358108; Wed, 10 Feb 2010 15:09:18 -0800 (PST) In-Reply-To: References: <426bed111002080049u16354c87pd4fb8830e0542972@mail.gmail.com> <20100208114734.GA99245@icarus.home.lan> <426bed111002091752g1cf96cd0qf7be5098ab5c9742@mail.gmail.com> From: Chris Rees Date: Wed, 10 Feb 2010 23:08:58 +0000 Message-ID: To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Unresponsive keyboard after a few boots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 23:09:22 -0000 On 10 February 2010 07:10, Mehmet Erol Sanliturk wrote: > > > On Tue, Feb 9, 2010 at 8:52 PM, Rohit Grover wrote: > Initially start FreeBSD and dump all of the related circuit register values > . This may require a key board . Problem is to override this requirement . > If in the system there is also a PS/2 key board slot , a PS/2 keyboard may > be utilized . Another way may be a shell script or program starting on boot > automatically to dump the required values . In that case , a key board may > not be required . There are no PS/2 or any other legacy connectors on any Intel Mac. USB only (firewire keyboards are a rarity, but maybe worth a try!) Chris From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 23:10:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EE9610656FD for ; Wed, 10 Feb 2010 23:10:51 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 8236A8FC08 for ; Wed, 10 Feb 2010 23:10:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id o1ANAm06011923; Thu, 11 Feb 2010 02:10:48 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 11 Feb 2010 02:10:48 +0300 (MSK) From: Dmitry Morozovsky To: Dan Langille In-Reply-To: <4B731FB5.8010304@langille.org> Message-ID: References: <4B6F9A8D.4050907@langille.org> <4B731FB5.8010304@langille.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (woozle.rinet.ru [0.0.0.0]); Thu, 11 Feb 2010 02:10:48 +0300 (MSK) Cc: FreeBSD Stable Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 23:10:51 -0000 On Wed, 10 Feb 2010, Dan Langille wrote: DL> Dmitry Morozovsky wrote: DL> > On Wed, 10 Feb 2010, Dmitry Morozovsky wrote: DL> > DL> > DM> other parts are regular SocketAM2+ motherboard, Athlon X4, 8G ram, DM> DL> > FreeBSD/amd64 DL> > DL> > well, not exactly "regular" - it's ASUS M2N-LR-SATA with 10 SATA channels, DL> > but I suppose there are comparable in "workstation" mobo market now... DL> DL> 10 SATA channels? Newegg claims only 6: You refer to regular M2N-LR, M2N-LR-SATA contains additional 4-channel Marvell chip: marck@moose:~> grep '^atapci.*: <' /var/run/dmesg.boot atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 4.0 on pci0 atapci1: port 0xc400-0xc407,0xc080-0xc083,0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb88f mem 0xef9bd000-0xef9bdfff irq 21 at device 5.0 on pci0 atapci2: port 0xb800-0xb807,0xb480-0xb483,0xb400-0xb407,0xb080-0xb083,0xb000-0xb00f mem 0xef9bc000-0xef9bcfff irq 22 at device 5.1 on pci0 atapci3: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f mem 0xef9b3000-0xef9b3fff irq 23 at device 5.2 on pci0 atapci4: port 0xe800-0xe8ff mem 0xefd00000-0xefdfffff irq 17 at device 0.0 on pci3 atapci5: port 0xe400-0xe4ff mem 0xefb00000-0xefbfffff irq 18 at device 6.0 on pci3 (atapci4 is now used for 1-disk Promise enclosure; I tried to use SiL card to use eSATA port native, but it failed to initialize there, so I use simple SATA-eSATA bracket to use eSATA capabilities to this Eternal Beast [tm] ;-P) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 02:17:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B6CF106566B for ; Thu, 11 Feb 2010 02:17:52 +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 123078FC16 for ; Thu, 11 Feb 2010 02:17:51 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1B2Hnk0008695 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 21:17:50 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Martin Kristensen In-Reply-To: <20100210234315.7abde83c@alpha.miknet.dk> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> <4B72FC0A.1020701@icyb.net.ua> <20100210220508.790ee773@alpha.miknet.dk> <1265839318.8609.104.camel@balrog.2hip.net> <20100210234315.7abde83c@alpha.miknet.dk> Content-Type: text/plain Organization: FreeBSD Date: Wed, 10 Feb 2010 20:17:43 -0600 Message-Id: <1265854663.8609.117.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 02:17:52 -0000 On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: > On Wed, 10 Feb 2010 16:01:58 -0600 > Robert Noland wrote: > > > On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: > > > On Wed, 10 Feb 2010 20:33:46 +0200 > > > Andriy Gapon wrote: > > > > > > > on 10/02/2010 20:29 Vitaly Magerya said the following: > > > > > Robert Noland wrote: > > > > >>> It is not, and yes I use WITHOUT_HAL. Currently disabling DRI > > > > >>> helps; should I try rebuilding xorg-server with HAL? > > > > >> Yes, you can still disable hal at runtime by setting > > > > >> AutoAddDevices "Off" in xorg.conf. > > > > > > > > > > Seems to work with HAL. > > > > > > > > I've long thought that xorg server should be linked with libthr > > > > regardless of HAL option. Unfortunately, I never came up with > > > > patch, nor have anyone else. Xorg server really uses pthreads > > > > when doing DRM and HAL brings in libthr dependency only as an > > > > accident. > > > > > > > > > > This is my first post to this list, so hello all. > > > > > > I have been running with NoAccel for a long time, since disabling > > > DRI alone would cause a complete deadlock (screen to standby, no > > > ssh, no response to keyboard, etc.). > > > > > > However, I rebuilt xorg-server with HAL support, and now simply > > > disabling DRI allows me to start X. > > > > > > The card is RV790 based. > > > > Just checked... This card should work with Accel and DRI... At least > > on -CURRENT with updated ports. Check UPDATING, and set > > WITHOUT_NOUVEAU to get correct version of libdrm. > > > > robert. > > > > I am on -STABLE built on Jan. 19. I updated mesa today (to > libdrm-2.4.17), and rebuilt xorg-server and drivers. I have > WITHOUT_NOUVEAU="YES" in /etc/make.conf. pkg_info reports libGL-7.6.1. Is that 8-STABLE or 7? 8 should work, and I think 7 should as well, but just checking. 6 won't work. > I have tried loading radeon.ko manually before startx. What are the results? If things are not working, I'll want to see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X started if you can get it. robert. > If it will help, I can switch to -CURRENT to see if that changes > anything. > > Martin > > PS. Robert, in researching this I got some idea of the effort you put > into this, thanks! -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 03:00:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C206106568D for ; Thu, 11 Feb 2010 03:00:47 +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 29B7F8FC1B for ; Thu, 11 Feb 2010 03:00:47 +0000 (UTC) Received: from compute2.internal (compute2.internal [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id BBF7AE0A57 for ; Wed, 10 Feb 2010 22:00:46 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 10 Feb 2010 22:00:46 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=QZ+E25+5TFM/tXtqc1pWgaRvvlE=; b=dfCrG+UAZ+gt3GCQXrHq8D6fHpPe7f2ASWykdx4BRYhlHMq+po7vGKr0yYLep7fhxtwpWLOgFggWzCyxANfeLaGbguzN9X9V6vQABhVEktdsOVv8dpomlTdR3BkDHQMHXS62+/ES92m+e4MX80GzOi1jtyNDj17tgT8nGt+acJI= X-Sasl-enc: D1xb2vOnqG8ChUFhXAT76bm5/Y/DuyWSybLrrNA41OEH 1265857246 Received: from anglepoise.lon.incunabulum.net (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4FEC64AD2E8 for ; Wed, 10 Feb 2010 22:00:46 -0500 (EST) Message-ID: <4B7372D7.9060108@incunabulum.net> Date: Thu, 11 Feb 2010 03:00:39 +0000 From: Bruce Simpson User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100207 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> <4B71AED5.4030002@wensing.org> <201002091949.o19JntPo009017@apollo.backplane.com> <4B723DF9.3070105@langille.org> <4B730B94.1050205@comcast.net> In-Reply-To: <4B730B94.1050205@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 03:00:47 -0000 On 02/10/10 19:40, Steve Polyack wrote: > > I haven't had such bad experience as the above, but it is certainly a > concern. Using ZFS we simply 'offline' the device, pull, replace with > a new one, glabel, and zfs replace. It seems to work fine as long as > nothing is accessing the device you are replacing (otherwise you will > get a kernel panic a few minutes down the line). mav@FreeBSD.org has > also committed a large patch set to 9-CURRENT which implements > "proper" SATA/AHCI hot-plug support and error-recovery through CAM. I've been running with this patch in 8-STABLE for well over a week now on my desktop w/o issues; I am using main disk for dev, and eSATA disk pack for light multimedia use. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 05:04:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05F0D106568B for ; Thu, 11 Feb 2010 05:04:11 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-pz0-f179.google.com (mail-pz0-f179.google.com [209.85.222.179]) by mx1.freebsd.org (Postfix) with ESMTP id C30498FC0A for ; Thu, 11 Feb 2010 05:04:10 +0000 (UTC) Received: by pzk9 with SMTP id 9so1001256pzk.28 for ; Wed, 10 Feb 2010 21:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=PBA1YrSv+Loz7rjzEBgbENqhwK6oV3BBKcMvJkQSV9o=; b=fPuK3TN86Bt8r7IuVjd9qlehS2pobKvKNiXuilKMXdLeLvmbVSwd9rSzuwLr2U0foC RmPpWTxErfEVkWr9pEgwkfYxSMnOa6zQ1B3eW+Hx1ZW/NEsnOWpTTj7Ka4GeMdNdH1D1 yDwBp75ntQiYDL182kHPyFwLjkhOZ2BXhc5Bw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=it3ZLfr38/8QShsnu/ENcIRKyAgeu+8SsBUMwxzQmJroBHDMz+VaE+vKvyOf6D6Atu ZKZcd019DNNCksGOSn6l2xmUerIsN7IJrcgdqjwxWartHc0RMxWTPAXr7Ddiv/nRipTp 4FzOFIDcc+Iykhb4ARZvJkeiW395RS8DezpMs= MIME-Version: 1.0 Received: by 10.142.121.10 with SMTP id t10mr809513wfc.152.1265863028607; Wed, 10 Feb 2010 20:37:08 -0800 (PST) In-Reply-To: <20100210184623.GA78851@icarus.home.lan> References: <4B72D94A.8030509@icyb.net.ua> <4B72E93C.80102@icyb.net.ua> <9bbcef731002101003r203f5189xf139700a0d48afa0@mail.gmail.com> <4B72F67F.4000209@icyb.net.ua> <9bbcef731002101026k5007075cqf97fc80404ac3fa7@mail.gmail.com> <4B72FC55.2090508@icyb.net.ua> <9bbcef731002101038r1ac04141t505216816489376f@mail.gmail.com> <20100210184623.GA78851@icarus.home.lan> Date: Wed, 10 Feb 2010 22:37:08 -0600 Message-ID: From: Alan Cox To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 05:04:11 -0000 On Wed, Feb 10, 2010 at 12:46 PM, Jeremy Chadwick wrote: [snip] > > I read what Andriy wrote to mean that the way FreeBSD utilises 4MB TLB > on certain models of AMD processors is broken/quirky, and on those CPUs, > users should stick to vm.pmap.pg_ps_enabled="0" (loader.conf). > > No. He said, "We don't do anything that strays from specifications." So, he is not saying that FreeBSD is doing anything broken. Here is what I know. Several of us, myself included, have been able to reproduce either lockups or machine check exceptions when BOTH the machine check driver and superpages are enabled on AMD family 10h processors. There have been no reports of this problem on either Intel or earlier AMD processors. Moreover, there is no evidence of instability in AMD family 10h processors until the machine check driver is enabled. By default, FreeBSD 8.0 enables superpages but disables the machine check driver. So, running natively, i.e., without virtualization, you shouldn't experience a problem, unless you explicitly enable the machine check driver. However, running on top of a hypervisor, like vSphere 4, you might face a problem because the hypervisor might enable machine check exceptions, regardless of what the FreeBSD guest does. I really don't know whether vSphere 4 enables machine check exception or not. If it does, then either you disable the use of superpages in the FreeBSD guest, or you find a way to disable the machine check driver in the hypervisor. Both Andriy and I have reported this problem to people at AMD, but we haven't yet received AMD's analysis. These things take time. Regards, Alan From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 06:45:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4544F106566C for ; Thu, 11 Feb 2010 06:45:11 +0000 (UTC) (envelope-from rgrover1@gmail.com) Received: from mail-pz0-f179.google.com (mail-pz0-f179.google.com [209.85.222.179]) by mx1.freebsd.org (Postfix) with ESMTP id 16F138FC17 for ; Thu, 11 Feb 2010 06:45:11 +0000 (UTC) Received: by pzk9 with SMTP id 9so1113570pzk.28 for ; Wed, 10 Feb 2010 22:45:10 -0800 (PST) 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=Ueqi8HEnZFtXXkbCIXwRjVOjXUoPU5imWUq0a6kwNPU=; b=Vxtx9/yswBHk30tkUkXHDqC5edDZAsyRP/gtVmZDsWks693jqCN7GzObtkVmhanM3R ZQJZrnfGtZiYUVS5zZmJ3VJKtPBXM45enyR1I4SGz1j7tfhQoOY9kwIn/Rg75bijFfik rx8tKpQUFv3AiIs2sdsrlRyRUsBQbQukZ79T0= 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=q+vJVNwrreyM3ne0UH+wMBQIbb+1h11slvd46GNmdjpXqpF541a9eqUDRRv/EoxFpK F/S912V3l4edh2hgfiNdxCmhRBsLRhsaMtEmHhMPshWUv0mpUk1LVqLc6m/K0nW3blXo 9Qm8vvap9fGrvQHQbCmHG1VIsW5CE3xDHavJs= MIME-Version: 1.0 Received: by 10.141.90.20 with SMTP id s20mr903430rvl.80.1265870710498; Wed, 10 Feb 2010 22:45:10 -0800 (PST) In-Reply-To: <4B72D7DA.3050305@icyb.net.ua> References: <426bed111002080049u16354c87pd4fb8830e0542972@mail.gmail.com> <20100208114734.GA99245@icarus.home.lan> <426bed111002091752g1cf96cd0qf7be5098ab5c9742@mail.gmail.com> <426bed111002100335x538a14bbo38f511566fe05fb2@mail.gmail.com> <4B72D7DA.3050305@icyb.net.ua> Date: Thu, 11 Feb 2010 12:15:10 +0530 Message-ID: <426bed111002102245ga1c1fdbu26a6772e25451875@mail.gmail.com> From: Rohit Grover To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, utisoft@gmail.com, Jeremy Chadwick Subject: Re: Unresponsive keyboard after a few boots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 06:45:11 -0000 I added hw.pci.usb_early_takeover="0" to /boot/loader.conf, but it hasn't made any reliable difference. I am not resorting to a binary search of revisions along stable/8.0 to find the culprit, but this is going to be a very slow and wasteful process--it takes me multiple boots (first into MacOSx and then repeatedly into FreeBSD) before I can move from one kernel to another. Any ideas to short-circuit the binary search would be greatly appreciated. Thanks. On Wed, Feb 10, 2010 at 9:29 PM, Andriy Gapon wrote: > on 10/02/2010 13:35 Rohit Grover said the following: >> Thanks for replying. I would like to pursue this problem. I have >> verified that this problem doesn't happen with 8.0/RELEASE, and there >> are some improvements in 8.0/STABLE which I need, so it is very >> important for me to be able to use the latest 8.0/STABLE. > > Could you please try hw.pci.usb_early_takeover="0" in loader.conf? > > -- > Andriy Gapon > From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 06:48:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48269106566B for ; Thu, 11 Feb 2010 06:48:44 +0000 (UTC) (envelope-from rgrover1@gmail.com) Received: from mail-px0-f199.google.com (mail-px0-f199.google.com [209.85.216.199]) by mx1.freebsd.org (Postfix) with ESMTP id 18BBF8FC1F for ; Thu, 11 Feb 2010 06:48:44 +0000 (UTC) Received: by pxi37 with SMTP id 37so600965pxi.9 for ; Wed, 10 Feb 2010 22:48:43 -0800 (PST) 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=6pPko2IQOBfavwti4+jAl4Xlfw9zadKuND0RNzZs+6Y=; b=n+cdfZZfx2jejk+yzrK+0dQDxIM05m2RykXxGtizUoT6vCmY4LBjtBKw963BrvyoH5 P3DCV+I4xZuc1+hu2JZN/OWqHFHJIZUb0Rw+pglwX0Av1XGRdWsNWsP+l9oK7n5jQ0hZ wua875blXEY1vROlldnC0Y12ZLk6ZO+iAm9I0= 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=tS4W3lvNZC7sVaoWlxEenNXZ4PCbF8Y/uFfdMEwa19I0A5uqKHflsC2z85E+9BAHt2 NEwqME6Jy7rhG8r/oJb53SgvQIPqffkMNZgJVRfBJD+O9zCOLLFN1OlQe/ptAEEWwpBT rtWTqNqwljAuivE6Ko+2bGpu7X/2J0Y6w+P3U= MIME-Version: 1.0 Received: by 10.141.187.5 with SMTP id o5mr914163rvp.59.1265870917054; Wed, 10 Feb 2010 22:48:37 -0800 (PST) In-Reply-To: <426bed111002102245ga1c1fdbu26a6772e25451875@mail.gmail.com> References: <426bed111002080049u16354c87pd4fb8830e0542972@mail.gmail.com> <20100208114734.GA99245@icarus.home.lan> <426bed111002091752g1cf96cd0qf7be5098ab5c9742@mail.gmail.com> <426bed111002100335x538a14bbo38f511566fe05fb2@mail.gmail.com> <4B72D7DA.3050305@icyb.net.ua> <426bed111002102245ga1c1fdbu26a6772e25451875@mail.gmail.com> Date: Thu, 11 Feb 2010 12:18:37 +0530 Message-ID: <426bed111002102248q45211855icafe9191bc79ee65@mail.gmail.com> From: Rohit Grover To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, utisoft@gmail.com, Jeremy Chadwick Subject: Re: Unresponsive keyboard after a few boots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 06:48:44 -0000 On Thu, Feb 11, 2010 at 12:15 PM, Rohit Grover wrote: > I am not resorting to a binary search of revisions along stable/8.0 to Oops; typo above. I AM going to binary search revisions along stable/8.0 So far, I have also discovered that the first reboot following a kernel install is very likely to not have this problem. regards, From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 07:40:59 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B06921065670; Thu, 11 Feb 2010 07:40:59 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 31A1A8FC18; Thu, 11 Feb 2010 07:40:59 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o1B7eqs8033125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 08:40:52 +0100 (CET) (envelope-from uqs@FreeBSD.org) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o1B7ep2g033124; Thu, 11 Feb 2010 08:40:51 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Thu, 11 Feb 2010 08:40:51 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Dan Nelson Message-ID: <20100211074051.GI9748@acme.spoerlein.net> Mail-Followup-To: Dan Nelson , Ruslan Ermilov , stable@freebsd.org References: <20100210085814.GE9748@acme.spoerlein.net> <20100210104904.GA85373@edoofus.dev.vega.ru> <20100210180535.GG9748@acme.spoerlein.net> <20100210210007.GB9318@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100210210007.GB9318@dan.emsphone.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@FreeBSD.org, Ruslan Ermilov Subject: Re: numeric sort(1) is broken on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 07:40:59 -0000 On Wed, 10.02.2010 at 15:00:07 -0600, Dan Nelson wrote: > In the last episode (Feb 10), Ulrich Spörlein said: > > On Wed, 10.02.2010 at 13:49:05 +0300, Ruslan Ermilov wrote: > > > On Wed, Feb 10, 2010 at 09:58:14AM +0100, Ulrich Spörlein wrote: > > > > not sure if this is a pilot error, but it seems to me that gnu sort -n > > > > is broken on at least -STABLE (couldn't test -CURRENT yet). > > > > > > > > It somehow does not manifest when using a simple list and sorting on a > > > > specific column, but it always happens to me when using it in > > > > combination with find(1). > > > > > > > > % truncate -s10m a; truncate -s5m b; truncate -s800k c > > > > % find a b c -ls|sort -nk7,7 > > > > 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a > > > > 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b > > > > 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c > > > > > > I bet you're using some non-C locale for LC_NUMERIC. What does "locale" > > > output tell you? > > > > Yes and no. LC_NUMERIC is still at C, LC_CTYPE is set to UTF-8, but as > > there are no non-ASCII symbols in that output it shouldn't matter, right? > > For me, 819200 is smaller than 10485760 in pretty much all locales. Why > > the hell is a numeric gnusort locale dependant? Why is -g working anyway? > > Try adding a 'b' to your sort flags. I bet the leading spaces in front of > your numbers are being treated as part of the sort key. Maybe de_DE.UTF-8 > and C have different ideas of what is whitespace? Indeed, 'b' is working too. So I've stocked up on the number of workarounds for this problem. What amazes me, is that no one seems to be as shocked as I to find out something basic like sorting on a number is not DTRT. Bye, Uli From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 07:49:36 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96E331065670; Thu, 11 Feb 2010 07:49:36 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 31F7D8FC15; Thu, 11 Feb 2010 07:49:36 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o1B7nYV3033245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 08:49:34 +0100 (CET) (envelope-from uqs@FreeBSD.org) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o1B7nY4e033244; Thu, 11 Feb 2010 08:49:34 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Thu, 11 Feb 2010 08:49:33 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Robert Noland Message-ID: <20100211074933.GJ9748@acme.spoerlein.net> Mail-Followup-To: Robert Noland , stable@freebsd.org References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <1265814670.8609.58.camel@balrog.2hip.net> <20100210180042.GF9748@acme.spoerlein.net> <1265825292.8609.81.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1265825292.8609.81.camel@balrog.2hip.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@FreeBSD.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 07:49:36 -0000 On Wed, 10.02.2010 at 12:08:12 -0600, Robert Noland wrote: > On Wed, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote: > > On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: > > > I have a strong suspicion that the issue is with bus_dma. If this is a > > > pci based card, then it is trying to allocate 32MB of contiguous > > > physical ram when the drm device is opened. This usually succeeds the > > > first time that the driver opens the device, but later, after memory has > > > become fragmented, this can become an issue. As I have mentioned, I > > > have code that reworks this whole process and I'll try and make a patch > > > available soon, but my I don't have a lot of time now, so it might be > > > the weekend before I can rebase the code and get a clean patch. > > > > No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without > > the recent Xorg update (haven't done that yet) I usually startx right after > > boot, and this usually works fine. > > > > One time I had massive ZFS/git jobs running headless first and wanted to > > startx afterwards. X11 took quite some time to come up and although > > window "switching" was snappy, *moving* windows around was slow as hell, > > window contents were re-drawing at ~1FPS. > > > > This also seems to always happen if I stop X11 and startx it again. > > So I made a diff from a regular Xorg startup against the slow one: > > > > --- Xorg.0.log 2010-02-09 20:59:16.000000000 +0100 > > +++ Xorg.slow.log 2010-01-31 11:04:08.000000000 +0100 > > ... > > @@ -599,49 +599,22 @@ > > (II) RADEON(0): [drm] added 1 reserved context for kernel > > (II) RADEON(0): X context handle = 0x1 > > (II) RADEON(0): [drm] installed DRM signal handler > > -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 > > -(II) RADEON(0): [pci] ring handle = 0xed1a5000 > > -(II) RADEON(0): [pci] Ring mapped at 0x802aa0000 > > -(II) RADEON(0): [pci] Ring contents 0x00000000 > > -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 > > -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 > > -(II) RADEON(0): [pci] Ring read ptr contents 0x00000000 > > -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 > > -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c00000 > > -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000 > > -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 > > -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 > > -(II) RADEON(0): [drm] register handle = 0xfe8e0000 > > -(II) RADEON(0): [dri] Visual configs initialized > > +(EE) RADEON(0): [pci] Out of memory (-12) > > Yes, drm failed to allocate the 32MB to back the GART, so drm was > disabled. Hopefully, the new allocation strategy will resolve this > since it will just require 32MB of physical ram below 4GB without > needing it to be contiguous. Hmm, given that today, 32MB isn't really that much, wouldn't it make more sense to have radeon(4) reserve those 32MB on load and never let go? I have radeon_load=YES set in loader.conf so it has a fair chance to always get it's 32MB contig. memory during startup. Given ZFS' memory hunger, there may not be enough free physical RAM below 4GB ... But it's your call, you obviously know more about this than me anyway :) Bye, Uli From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 09:25:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43A9F1065672 for ; Thu, 11 Feb 2010 09:25:25 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from authsmtp.rrzn.uni-hannover.de (authsmtp.rrzn.uni-hannover.de [130.75.2.107]) by mx1.freebsd.org (Postfix) with ESMTP id AB3708FC08 for ; Thu, 11 Feb 2010 09:25:24 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by authsmtp.rrzn.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1B9PLkG021306; Thu, 11 Feb 2010 10:25:22 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 952D724; Thu, 11 Feb 2010 10:25:21 +0100 (CET) Date: Thu, 11 Feb 2010 10:25:21 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: John Baldwin Message-Id: <20100211102521.4f214a44.gerrit@pmp.uni-hannover.de> In-Reply-To: <201002100853.18088.jhb@freebsd.org> References: <20100210105226.5c825b48.gerrit@pmp.uni-hannover.de> <201002100853.18088.jhb@freebsd.org> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.11.90925 Cc: freebsd-stable@freebsd.org Subject: Re: bugs in mpt(4) and mptutil(8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 09:25:25 -0000 On Wed, 10 Feb 2010 08:53:18 -0500 John Baldwin wrote about Re: bugs in mpt(4) and mptutil(8): JB> > This output is definitely wrong, because the drives are split up on JB> > mpt0 and mpt1 (and the USB stick is not connected to mpt at all :-) JB> > as can be seen with camcontrol: JB> Hmm, I asked the previous reporter to debug this by examining the JB> results that CAM returns from the bus scan using gdb, but I haven't JB> heard back. Unfortunately I do not have access to any hardware with JB> this sort of setup to debug this. I will do some debugging work here, if you can tell me what to do. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 10:50:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DC4A106566C; Thu, 11 Feb 2010 10:50:37 +0000 (UTC) (envelope-from mik@pc.dk) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5AB8FC15; Thu, 11 Feb 2010 10:50:36 +0000 (UTC) Received: from alpha.miknet.dk (0x5738c19d.rdnqu2.dynamic.dsl.tele.dk [87.56.193.157]) by pfepb.post.tele.dk (Postfix) with ESMTP id 1E402F8401F; Thu, 11 Feb 2010 11:50:34 +0100 (CET) Date: Thu, 11 Feb 2010 11:49:10 +0100 From: Martin Kristensen To: Robert Noland Message-ID: <20100211114910.392f919e@alpha.miknet.dk> In-Reply-To: <1265854663.8609.117.camel@balrog.2hip.net> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> <4B72FC0A.1020701@icyb.net.ua> <20100210220508.790ee773@alpha.miknet.dk> <1265839318.8609.104.camel@balrog.2hip.net> <20100210234315.7abde83c@alpha.miknet.dk> <1265854663.8609.117.camel@balrog.2hip.net> Organization: Private X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/RRT0e24jNjfVrtBkGC=1hte" Cc: freebsd-stable@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 10:50:37 -0000 --MP_/RRT0e24jNjfVrtBkGC=1hte Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, 10 Feb 2010 20:17:43 -0600 Robert Noland wrote: > On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: > > On Wed, 10 Feb 2010 16:01:58 -0600 > > Robert Noland wrote: > > > > > On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: > > > > On Wed, 10 Feb 2010 20:33:46 +0200 > > > > Andriy Gapon wrote: > > > > > > > > > on 10/02/2010 20:29 Vitaly Magerya said the following: > > > > > > Robert Noland wrote: > > > > > >>> It is not, and yes I use WITHOUT_HAL. Currently disabling > > > > > >>> DRI helps; should I try rebuilding xorg-server with HAL? > > > > > >> Yes, you can still disable hal at runtime by setting > > > > > >> AutoAddDevices "Off" in xorg.conf. > > > > > > > > > > > > Seems to work with HAL. > > > > > > > > > > I've long thought that xorg server should be linked with > > > > > libthr regardless of HAL option. Unfortunately, I never came > > > > > up with patch, nor have anyone else. Xorg server really uses > > > > > pthreads when doing DRM and HAL brings in libthr dependency > > > > > only as an accident. > > > > > > > > > > > > > This is my first post to this list, so hello all. > > > > > > > > I have been running with NoAccel for a long time, since > > > > disabling DRI alone would cause a complete deadlock (screen to > > > > standby, no ssh, no response to keyboard, etc.). > > > > > > > > However, I rebuilt xorg-server with HAL support, and now simply > > > > disabling DRI allows me to start X. > > > > > > > > The card is RV790 based. > > > > > > Just checked... This card should work with Accel and DRI... At > > > least on -CURRENT with updated ports. Check UPDATING, and set > > > WITHOUT_NOUVEAU to get correct version of libdrm. > > > > > > robert. > > > > > > > I am on -STABLE built on Jan. 19. I updated mesa today (to > > libdrm-2.4.17), and rebuilt xorg-server and drivers. I have > > WITHOUT_NOUVEAU="YES" in /etc/make.conf. pkg_info reports > > libGL-7.6.1. > > Is that 8-STABLE or 7? 8 should work, and I think 7 should as well, > but just checking. 6 won't work. > I am on 8-STABLE. > > I have tried loading radeon.ko manually before startx. > > What are the results? If things are not working, I'll want to see > your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X > started if you can get it. > > robert. > I have attached the output from pciconf -lvb, sysctl -a |grep ^hw.dri reports: hw.dri.0.name: radeon 0x96 hw.dri.0.vm: hw.dri.0.clients: hw.dri.0.vblank: hw.dri.0.debug: 0 I loaded radeon.ko from within my X session, which was started with DRI "OFF". If I run startx with DRI "True" or without an xorg.conf, the screen goes into standby as if the pc is turned off, the mouse and keyboard stops responding to keypresses (ie. numlock-led will not respond to me pressing the key.) and I cannot ssh into the machine. As far as I can tell it has crashed. There is nothing in /var/log/messages, which gives any indication that something went wrong (If I boot the machine - startx and force a reboot I get 2 x dmesg plus fsck messages). Xorg.0.log contains only messages from the last successful start of xorg, and is a far as I can tell useless in tracking this down. > > If it will help, I can switch to -CURRENT to see if that changes > > anything. > > > > Martin > > > > PS. Robert, in researching this I got some idea of the effort you > > put into this, thanks! > Martin -- Martin Kristensen --MP_/RRT0e24jNjfVrtBkGC=1hte Content-Type: application/octet-stream; name=pciconf.out Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=pciconf.out aG9zdGIwQHBjaTA6MDowOjA6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHg4Mjk1MTA0MyBjaGlwPTB4 MjllMDgwODYgcmV2PTB4MDEgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9y YXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1gzOC9YNDggKEJlYXJsYWtlKSBQcm9jZXNzb3IgdG8g SS9PIENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0g SE9TVC1QQ0kKcGNpYjFAcGNpMDowOjE6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDgyOTUxMDQz IGNoaXA9MHgyOWUxODA4NiByZXY9MHgwMSBoZHI9MHgwMQogICAgdmVuZG9yICAgICA9ICdJbnRl bCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnWDM4L1g0OCAoQmVhcmxha2UpIFBDSWUg Um9vdCBQb3J0IDEnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJ LVBDSQp1aGNpMEBwY2kwOjA6MjY6MDoJY2xhc3M9MHgwYzAzMDAgY2FyZD0weDgyNzcxMDQzIGNo aXA9MHgyOTM3ODA4NiByZXY9MHgwMiBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBD b3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnODI4MDFJQi9JUi9JSCAoSUNIOSBGYW1pbHkp IFVTQiBVbml2ZXJzYWwgSG9zdCBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBi dXMKICAgIHN1YmNsYXNzICAgPSBVU0IKICAgIGJhciAgIFsyMF0gPSB0eXBlIEkvTyBQb3J0LCBy YW5nZSAzMiwgYmFzZSAweGE4MDAsIHNpemUgMzIsIGVuYWJsZWQKdWhjaTFAcGNpMDowOjI2OjE6 CWNsYXNzPTB4MGMwMzAwIGNhcmQ9MHg4Mjc3MTA0MyBjaGlwPTB4MjkzODgwODYgcmV2PTB4MDIg aGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2Ug ICAgID0gJzgyODAxSUIvSVIvSUggKElDSDkgRmFtaWx5KSBVU0IgVW5pdmVyc2FsIEhvc3QgQ29u dHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNC CiAgICBiYXIgICBbMjBdID0gdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhhODgwLCBz aXplIDMyLCBlbmFibGVkCnVoY2kyQHBjaTA6MDoyNjoyOgljbGFzcz0weDBjMDMwMCBjYXJkPTB4 ODI3NzEwNDMgY2hpcD0weDI5Mzk4MDg2IHJldj0weDAyIGhkcj0weDAwCiAgICB2ZW5kb3IgICAg ID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICc4MjgwMUlCL0lSL0lIIChJ Q0g5IEZhbWlseSkgVVNCIFVuaXZlcnNhbCBIb3N0IENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAg ID0gc2VyaWFsIGJ1cwogICAgc3ViY2xhc3MgICA9IFVTQgogICAgYmFyICAgWzIwXSA9IHR5cGUg SS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4YWMwMCwgc2l6ZSAzMiwgZW5hYmxlZAplaGNpMEBw Y2kwOjA6MjY6NzoJY2xhc3M9MHgwYzAzMjAgY2FyZD0weDgyNzcxMDQzIGNoaXA9MHgyOTNjODA4 NiByZXY9MHgwMiBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicK ICAgIGRldmljZSAgICAgPSAnODI4MDFJQi9JUi9JSCAoSUNIOSBGYW1pbHkpIFVTQjIgRW5oYW5j ZWQgSG9zdCBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNs YXNzICAgPSBVU0IKICAgIGJhciAgIFsxMF0gPSB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2Ug MHhmZTdmZmMwMCwgc2l6ZSAxMDI0LCBlbmFibGVkCnBjaWIyQHBjaTA6MDoyODowOgljbGFzcz0w eDA2MDQwMCBjYXJkPTB4ODI3NzEwNDMgY2hpcD0weDI5NDA4MDg2IHJldj0weDAyIGhkcj0weDAx CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICc4 MjgwMUlCL0lSL0lIIChJQ0g5IEZhbWlseSkgUENJZSBSb290IFBvcnQgMScKICAgIGNsYXNzICAg ICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCnBjaWIzQHBjaTA6MDoyODoyOglj bGFzcz0weDA2MDQwMCBjYXJkPTB4ODI3NzEwNDMgY2hpcD0weDI5NDQ4MDg2IHJldj0weDAyIGhk cj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAg ICA9ICc4MjgwMUlCL0lSL0lIIChJQ0g5IEZhbWlseSkgUENJZSBSb290IFBvcnQgMycKICAgIGNs YXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCnBjaWI0QHBjaTA6MDoy ODo0OgljbGFzcz0weDA2MDQwMCBjYXJkPTB4ODI3NzEwNDMgY2hpcD0weDI5NDg4MDg2IHJldj0w eDAyIGhkcj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2 aWNlICAgICA9ICc4MjgwMUlCL0lSL0lIIChJQ0g5IEZhbWlseSkgUENJZSBSb290IFBvcnQgNScK ICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCnVoY2kzQHBj aTA6MDoyOTowOgljbGFzcz0weDBjMDMwMCBjYXJkPTB4ODI3NzEwNDMgY2hpcD0weDI5MzQ4MDg2 IHJldj0weDAyIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwog ICAgZGV2aWNlICAgICA9ICc4MjgwMUlCL0lSL0lIIChJQ0g5IEZhbWlseSkgVVNCIFVuaXZlcnNh bCBIb3N0IENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3ViY2xh c3MgICA9IFVTQgogICAgYmFyICAgWzIwXSA9IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNl IDB4YTA4MCwgc2l6ZSAzMiwgZW5hYmxlZAp1aGNpNEBwY2kwOjA6Mjk6MToJY2xhc3M9MHgwYzAz MDAgY2FyZD0weDgyNzcxMDQzIGNoaXA9MHgyOTM1ODA4NiByZXY9MHgwMiBoZHI9MHgwMAogICAg dmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnODI4MDFJ Qi9JUi9JSCAoSUNIOSBGYW1pbHkpIFVTQiBVbml2ZXJzYWwgSG9zdCBDb250cm9sbGVyJwogICAg Y2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBVU0IKICAgIGJhciAgIFsy MF0gPSB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGE0MDAsIHNpemUgMzIsIGVuYWJs ZWQKdWhjaTVAcGNpMDowOjI5OjI6CWNsYXNzPTB4MGMwMzAwIGNhcmQ9MHg4Mjc3MTA0MyBjaGlw PTB4MjkzNjgwODYgcmV2PTB4MDIgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29y cG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJzgyODAxSUIvSVIvSUggKElDSDkgRmFtaWx5KSBV U0IgVW5pdmVyc2FsIEhvc3QgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVz CiAgICBzdWJjbGFzcyAgID0gVVNCCiAgICBiYXIgICBbMjBdID0gdHlwZSBJL08gUG9ydCwgcmFu Z2UgMzIsIGJhc2UgMHhhNDgwLCBzaXplIDMyLCBlbmFibGVkCmVoY2kxQHBjaTA6MDoyOTo3Oglj bGFzcz0weDBjMDMyMCBjYXJkPTB4ODI3NzEwNDMgY2hpcD0weDI5M2E4MDg2IHJldj0weDAyIGhk cj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAg ICA9ICc4MjgwMUlCL0lSL0lIIChJQ0g5IEZhbWlseSkgVVNCMiBFbmhhbmNlZCBIb3N0IENvbnRy b2xsZXInCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3ViY2xhc3MgICA9IFVTQgog ICAgYmFyICAgWzEwXSA9IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZlN2ZmODAwLCBz aXplIDEwMjQsIGVuYWJsZWQKcGNpYjVAcGNpMDowOjMwOjA6CWNsYXNzPTB4MDYwNDAxIGNhcmQ9 MHg4Mjc3MTA0MyBjaGlwPTB4MjQ0ZTgwODYgcmV2PTB4OTIgaGRyPTB4MDEKICAgIHZlbmRvciAg ICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJzgyODAxIEZhbWlseSAo SUNIMi8zLzQvNS82LzcvOC85LDYzeHhFU0IpIEh1YiBJbnRlcmZhY2UgdG8gUENJIEJyaWRnZScK ICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCmlzYWIwQHBj aTA6MDozMTowOgljbGFzcz0weDA2MDEwMCBjYXJkPTB4ODI3NzEwNDMgY2hpcD0weDI5MTY4MDg2 IHJldj0weDAyIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwog ICAgZGV2aWNlICAgICA9ICc4MjgwMUlSIChJQ0g5UikgTFBDIEludGVyZmFjZSBDb250cm9sbGVy JwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IFBDSS1JU0EKYXRhcGNp MUBwY2kwOjA6MzE6MjoJY2xhc3M9MHgwMTA2MDEgY2FyZD0weDgyNzcxMDQzIGNoaXA9MHgyOTIy ODA4NiByZXY9MHgwMiBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlv bicKICAgIGRldmljZSAgICAgPSAnODI4MDFJQi9JUi9JSCAoSUNIOSBGYW1pbHkpIDYgcG9ydCBT QVRBIEFIQ0kgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBtYXNzIHN0b3JhZ2UKICAgIHN1 YmNsYXNzICAgPSBTQVRBCiAgICBiYXIgICBbMTBdID0gdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIs IGJhc2UgMHg5YzAwLCBzaXplICA4LCBlbmFibGVkCiAgICBiYXIgICBbMTRdID0gdHlwZSBJL08g UG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg5ODgwLCBzaXplICA0LCBlbmFibGVkCiAgICBiYXIgICBb MThdID0gdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg5ODAwLCBzaXplICA4LCBlbmFi bGVkCiAgICBiYXIgICBbMWNdID0gdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg5NDgw LCBzaXplICA0LCBlbmFibGVkCiAgICBiYXIgICBbMjBdID0gdHlwZSBJL08gUG9ydCwgcmFuZ2Ug MzIsIGJhc2UgMHg5NDAwLCBzaXplIDMyLCBlbmFibGVkCiAgICBiYXIgICBbMjRdID0gdHlwZSBN ZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmU3ZmU4MDAsIHNpemUgMjA0OCwgZW5hYmxlZApub25l MEBwY2kwOjA6MzE6MzoJY2xhc3M9MHgwYzA1MDAgY2FyZD0weDgyNzcxMDQzIGNoaXA9MHgyOTMw ODA4NiByZXY9MHgwMiBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlv bicKICAgIGRldmljZSAgICAgPSAnODI4MDFJQi9JUi9JSCAoSUNIOSBGYW1pbHkpIFNNQnVzIENv bnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3ViY2xhc3MgICA9IFNN QnVzCiAgICBiYXIgICBbMTBdID0gdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmU3ZmY0 MDAsIHNpemUgMjU2LCBlbmFibGVkCiAgICBiYXIgICBbMjBdID0gdHlwZSBJL08gUG9ydCwgcmFu Z2UgMzIsIGJhc2UgMHg0MDAsIHNpemUgMzIsIGVuYWJsZWQKdmdhcGNpMEBwY2kwOjE6MDowOglj bGFzcz0weDAzMDAwMCBjYXJkPTB4MjcwMDE2ODIgY2hpcD0weDk0NjAxMDAyIHJldj0weDAwIGhk cj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jLiAvIEFkdmFuY2Vk IE1pY3JvIERldmljZXMsIEluYy4nCiAgICBjbGFzcyAgICAgID0gZGlzcGxheQogICAgc3ViY2xh c3MgICA9IFZHQQogICAgYmFyICAgWzEwXSA9IHR5cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFu Z2UgNjQsIGJhc2UgMHhkMDAwMDAwMCwgc2l6ZSAyNjg0MzU0NTYsIGVuYWJsZWQKICAgIGJhciAg IFsxOF0gPSB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmZThlMDAwMCwgc2l6ZSA2NTUz NiwgZW5hYmxlZAogICAgYmFyICAgWzIwXSA9IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNl IDB4YjAwMCwgc2l6ZSAyNTYsIGVuYWJsZWQKbm9uZTFAcGNpMDoxOjA6MToJY2xhc3M9MHgwNDAz MDAgY2FyZD0weGFhMzAxNjgyIGNoaXA9MHhhYTMwMTAwMiByZXY9MHgwMCBoZHI9MHgwMAogICAg dmVuZG9yICAgICA9ICdBVEkgVGVjaG5vbG9naWVzIEluYy4gLyBBZHZhbmNlZCBNaWNybyBEZXZp Y2VzLCBJbmMuJwogICAgY2xhc3MgICAgICA9IG11bHRpbWVkaWEKICAgIHN1YmNsYXNzICAgPSBI REEKICAgIGJhciAgIFsxMF0gPSB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmZThmYzAw MCwgc2l6ZSAxNjM4NCwgZW5hYmxlZAptc2tjMEBwY2kwOjM6MDowOgljbGFzcz0weDAyMDAwMCBj YXJkPTB4ODFmODEwNDMgY2hpcD0weDQzNjQxMWFiIHJldj0weDEyIGhkcj0weDAwCiAgICB2ZW5k b3IgICAgID0gJ01hcnZlbGwgU2VtaWNvbmR1Y3RvciAoV2FzOiBHYWxpbGVvIFRlY2hub2xvZ3kg THRkKScKICAgIGRldmljZSAgICAgPSAnWXVrb24gUENJLUUgR2lnYWJpdCBFdGhlcm5ldCBDb250 cm9sbGVyICg4OEU4MDU2KScKICAgIGNsYXNzICAgICAgPSBuZXR3b3JrCiAgICBzdWJjbGFzcyAg ID0gZXRoZXJuZXQKICAgIGJhciAgIFsxMF0gPSB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2Ug MHhmZWFmYzAwMCwgc2l6ZSAxNjM4NCwgZW5hYmxlZAogICAgYmFyICAgWzE4XSA9IHR5cGUgSS9P IFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZDgwMCwgc2l6ZSAyNTYsIGVuYWJsZWQKYXRhcGNpMEBw Y2kwOjI6MDowOgljbGFzcz0weDAxMDE4NSBjYXJkPTB4ODI0ZjEwNDMgY2hpcD0weDIzNjgxOTdi IHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0pNaWNyb24gVGVjaG5vbG9neSBD b3JwLicKICAgIGRldmljZSAgICAgPSAnSk1CMzY4IElERSBDb250cm9sbGVyJwogICAgY2xhc3Mg ICAgICA9IG1hc3Mgc3RvcmFnZQogICAgc3ViY2xhc3MgICA9IEFUQQogICAgYmFyICAgWzEwXSA9 IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4Y2MwMCwgc2l6ZSAgOCwgZW5hYmxlZAog ICAgYmFyICAgWzE0XSA9IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4Yzg4MCwgc2l6 ZSAgNCwgZW5hYmxlZAogICAgYmFyICAgWzE4XSA9IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBi YXNlIDB4YzgwMCwgc2l6ZSAgOCwgZW5hYmxlZAogICAgYmFyICAgWzFjXSA9IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4YzQ4MCwgc2l6ZSAgNCwgZW5hYmxlZAogICAgYmFyICAgWzIw XSA9IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4YzQwMCwgc2l6ZSAxNiwgZW5hYmxl ZApvc3NfY21pODc4eDBAcGNpMDo1OjI6MDoJY2xhc3M9MHgwNDAxMDAgY2FyZD0weDk3NjE3Mjg0 IGNoaXA9MHg4Nzg4MTNmNiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdDLU1l ZGlhIEVsZWN0cm9uaWNzIEluYy4nCiAgICBkZXZpY2UgICAgID0gJ0MtTWVkaWEgT3h5Z2VuIEhE IChDTUk4Nzg4L1BDSS04Q0gpJwogICAgY2xhc3MgICAgICA9IG11bHRpbWVkaWEKICAgIHN1YmNs YXNzICAgPSBhdWRpbwogICAgYmFyICAgWzEwXSA9IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBi YXNlIDB4ZTgwMCwgc2l6ZSAyNTYsIGVuYWJsZWQKZndvaGNpMEBwY2kwOjU6MzowOgljbGFzcz0w eDBjMDAxMCBjYXJkPTB4ODFmZTEwNDMgY2hpcD0weDMwNDQxMTA2IHJldj0weGMwIGhkcj0weDAw CiAgICB2ZW5kb3IgICAgID0gJ1ZJQSBUZWNobm9sb2dpZXMgSW5jJwogICAgZGV2aWNlICAgICA9 ICdWVDYzMDYgVklBIEZpcmUgSUkgSUVFRS0xMzk0IE9IQ0kgTGluayBMYXllciBDb250cm9sbGVy JwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBGaXJlV2lyZQog ICAgYmFyICAgWzEwXSA9IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZlYmZmODAwLCBz aXplIDIwNDgsIGVuYWJsZWQKICAgIGJhciAgIFsxNF0gPSB0eXBlIEkvTyBQb3J0LCByYW5nZSAz MiwgYmFzZSAweGVjMDAsIHNpemUgMTI4LCBlbmFibGVkCg== --MP_/RRT0e24jNjfVrtBkGC=1hte-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 12:07:23 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2387E1065679; Thu, 11 Feb 2010 12:07:23 +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 ECA2A8FC08; Thu, 11 Feb 2010 12:07:22 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1BC7Khb011703 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 07:07:20 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Ulrich =?ISO-8859-1?Q?Sp=F6rlein?= In-Reply-To: <20100211074933.GJ9748@acme.spoerlein.net> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <1265814670.8609.58.camel@balrog.2hip.net> <20100210180042.GF9748@acme.spoerlein.net> <1265825292.8609.81.camel@balrog.2hip.net> <20100211074933.GJ9748@acme.spoerlein.net> Content-Type: text/plain; charset="ISO-8859-1" Organization: FreeBSD Date: Thu, 11 Feb 2010 06:07:14 -0600 Message-Id: <1265890034.8609.147.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@FreeBSD.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 12:07:23 -0000 On Thu, 2010-02-11 at 08:49 +0100, Ulrich Spörlein wrote: > On Wed, 10.02.2010 at 12:08:12 -0600, Robert Noland wrote: > > On Wed, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote: > > > On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: > > > > I have a strong suspicion that the issue is with bus_dma. If this is a > > > > pci based card, then it is trying to allocate 32MB of contiguous > > > > physical ram when the drm device is opened. This usually succeeds the > > > > first time that the driver opens the device, but later, after memory has > > > > become fragmented, this can become an issue. As I have mentioned, I > > > > have code that reworks this whole process and I'll try and make a patch > > > > available soon, but my I don't have a lot of time now, so it might be > > > > the weekend before I can rebase the code and get a clean patch. > > > > > > No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without > > > the recent Xorg update (haven't done that yet) I usually startx right after > > > boot, and this usually works fine. > > > > > > One time I had massive ZFS/git jobs running headless first and wanted to > > > startx afterwards. X11 took quite some time to come up and although > > > window "switching" was snappy, *moving* windows around was slow as hell, > > > window contents were re-drawing at ~1FPS. > > > > > > This also seems to always happen if I stop X11 and startx it again. > > > So I made a diff from a regular Xorg startup against the slow one: > > > > > > --- Xorg.0.log 2010-02-09 20:59:16.000000000 +0100 > > > +++ Xorg.slow.log 2010-01-31 11:04:08.000000000 +0100 > > > ... > > > @@ -599,49 +599,22 @@ > > > (II) RADEON(0): [drm] added 1 reserved context for kernel > > > (II) RADEON(0): X context handle = 0x1 > > > (II) RADEON(0): [drm] installed DRM signal handler > > > -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 > > > -(II) RADEON(0): [pci] ring handle = 0xed1a5000 > > > -(II) RADEON(0): [pci] Ring mapped at 0x802aa0000 > > > -(II) RADEON(0): [pci] Ring contents 0x00000000 > > > -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 > > > -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 > > > -(II) RADEON(0): [pci] Ring read ptr contents 0x00000000 > > > -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 > > > -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c00000 > > > -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000 > > > -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 > > > -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 > > > -(II) RADEON(0): [drm] register handle = 0xfe8e0000 > > > -(II) RADEON(0): [dri] Visual configs initialized > > > +(EE) RADEON(0): [pci] Out of memory (-12) > > > > Yes, drm failed to allocate the 32MB to back the GART, so drm was > > disabled. Hopefully, the new allocation strategy will resolve this > > since it will just require 32MB of physical ram below 4GB without > > needing it to be contiguous. > > Hmm, given that today, 32MB isn't really that much, wouldn't it make > more sense to have radeon(4) reserve those 32MB on load and never let > go? I have radeon_load=YES set in loader.conf so it has a fair chance to > always get it's 32MB contig. memory during startup. Given ZFS' memory > hunger, there may not be enough free physical RAM below 4GB ... While that would make sense... And it might work more like that once I implement TTM/KMS (actually the whole memory requirements will change as pages will then get mapped in and out of the gart), but currently, the allocation of scatter gather memory to populate the gart is driven by userland. The only memory that is pre-allocated by the driver is the sarea, and the register maps are pre-allocated, but that is just address mapping. For everything else, userland tells us when and how much memory to allocate. On radeon (and Intel for that matter) most if not all cards can reference anything that the cpu can, (up to at least 36 bits, iirc, or maybe 40) so I might drop the 4GB limit. However, since all of this is done in the generic drm code, I don't actually know what card I'm allocating memory for when I do it, so I won't change that part until I need to. I'll try and get a cleaned up patch of the scatter gather rework out this weekend. I've abandoned the use of bus_dma entirely for allocating SG pages and interact with the VM directly, thus avoiding the contiguous requirements of bus_dma. robert. > But it's your call, you obviously know more about this than me anyway :) > > Bye, > Uli -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 12:16:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58F2A106566C for ; Thu, 11 Feb 2010 12:16:21 +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 1EBAD8FC19 for ; Thu, 11 Feb 2010 12:16:20 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1BCGIIU011749 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 07:16:18 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Martin Kristensen In-Reply-To: <20100211114910.392f919e@alpha.miknet.dk> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> <4B72FC0A.1020701@icyb.net.ua> <20100210220508.790ee773@alpha.miknet.dk> <1265839318.8609.104.camel@balrog.2hip.net> <20100210234315.7abde83c@alpha.miknet.dk> <1265854663.8609.117.camel@balrog.2hip.net> <20100211114910.392f919e@alpha.miknet.dk> Content-Type: text/plain Organization: FreeBSD Date: Thu, 11 Feb 2010 06:16:12 -0600 Message-Id: <1265890573.8609.151.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 12:16:21 -0000 On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: > On Wed, 10 Feb 2010 20:17:43 -0600 > Robert Noland wrote: > > > On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: > > > On Wed, 10 Feb 2010 16:01:58 -0600 > > > Robert Noland wrote: > > > > > > > On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: > > > > > On Wed, 10 Feb 2010 20:33:46 +0200 > > > > > Andriy Gapon wrote: > > > > > > > > > > > on 10/02/2010 20:29 Vitaly Magerya said the following: > > > > > > > Robert Noland wrote: > > > > > > >>> It is not, and yes I use WITHOUT_HAL. Currently disabling > > > > > > >>> DRI helps; should I try rebuilding xorg-server with HAL? > > > > > > >> Yes, you can still disable hal at runtime by setting > > > > > > >> AutoAddDevices "Off" in xorg.conf. > > > > > > > > > > > > > > Seems to work with HAL. > > > > > > > > > > > > I've long thought that xorg server should be linked with > > > > > > libthr regardless of HAL option. Unfortunately, I never came > > > > > > up with patch, nor have anyone else. Xorg server really uses > > > > > > pthreads when doing DRM and HAL brings in libthr dependency > > > > > > only as an accident. > > > > > > > > > > > > > > > > This is my first post to this list, so hello all. > > > > > > > > > > I have been running with NoAccel for a long time, since > > > > > disabling DRI alone would cause a complete deadlock (screen to > > > > > standby, no ssh, no response to keyboard, etc.). > > > > > > > > > > However, I rebuilt xorg-server with HAL support, and now simply > > > > > disabling DRI allows me to start X. > > > > > > > > > > The card is RV790 based. > > > > > > > > Just checked... This card should work with Accel and DRI... At > > > > least on -CURRENT with updated ports. Check UPDATING, and set > > > > WITHOUT_NOUVEAU to get correct version of libdrm. > > > > > > > > robert. > > > > > > > > > > I am on -STABLE built on Jan. 19. I updated mesa today (to > > > libdrm-2.4.17), and rebuilt xorg-server and drivers. I have > > > WITHOUT_NOUVEAU="YES" in /etc/make.conf. pkg_info reports > > > libGL-7.6.1. > > > > Is that 8-STABLE or 7? 8 should work, and I think 7 should as well, > > but just checking. 6 won't work. > > > I am on 8-STABLE. > > > I have tried loading radeon.ko manually before startx. > > > > What are the results? If things are not working, I'll want to see > > your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X > > started if you can get it. > > > > robert. > > > > I have attached the output from pciconf -lvb, sysctl -a |grep ^hw.dri > reports: > > hw.dri.0.name: radeon 0x96 > hw.dri.0.vm: > hw.dri.0.clients: > hw.dri.0.vblank: > hw.dri.0.debug: 0 > > I loaded radeon.ko from within my X session, which was started with DRI > "OFF". Ok, if X doesn't try to open drm, then nothing will show up as being mapped. If you do a "sysctl hw.dri" it will show the mappings, but the above grep is cutting out most of the useful info. > If I run startx with DRI "True" or without an xorg.conf, the > screen goes into standby as if the pc is turned off, the mouse and > keyboard stops responding to keypresses (ie. numlock-led will not > respond to me pressing the key.) and I cannot ssh into the machine. As > far as I can tell it has crashed. > > There is nothing in /var/log/messages, which gives any indication > that something went wrong (If I boot the machine - startx and force a > reboot I get 2 x dmesg plus fsck messages). > > Xorg.0.log contains only messages from the last successful start of > xorg, and is a far as I can tell useless in tracking this down. This sounds suspiciously like a WITNESS issue... I wonder if I have accidentally MFC'd something that isn't safe. You don't get a core dump eventually do you? robert. > > > If it will help, I can switch to -CURRENT to see if that changes > > > anything. > > > > > > Martin > > > > > > PS. Robert, in researching this I got some idea of the effort you > > > put into this, thanks! > > > > Martin > -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 13:52:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 068641065676 for ; Thu, 11 Feb 2010 13:52:10 +0000 (UTC) (envelope-from mik@pc.dk) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by mx1.freebsd.org (Postfix) with ESMTP id 908448FC0A for ; Thu, 11 Feb 2010 13:52:09 +0000 (UTC) Received: from alpha.miknet.dk (0x5738c19d.rdnqu2.dynamic.dsl.tele.dk [87.56.193.157]) by pfepb.post.tele.dk (Postfix) with ESMTP id 3BAFBF84066 for ; Thu, 11 Feb 2010 14:52:08 +0100 (CET) Date: Thu, 11 Feb 2010 14:50:44 +0100 From: Martin Kristensen To: freebsd-stable@freebsd.org Message-ID: <20100211145044.205a3e2b@alpha.miknet.dk> In-Reply-To: <1265890573.8609.151.camel@balrog.2hip.net> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> <4B72FC0A.1020701@icyb.net.ua> <20100210220508.790ee773@alpha.miknet.dk> <1265839318.8609.104.camel@balrog.2hip.net> <20100210234315.7abde83c@alpha.miknet.dk> <1265854663.8609.117.camel@balrog.2hip.net> <20100211114910.392f919e@alpha.miknet.dk> <1265890573.8609.151.camel@balrog.2hip.net> Organization: Private X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 13:52:10 -0000 On Thu, 11 Feb 2010 06:16:12 -0600 Robert Noland wrote: > On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: > > On Wed, 10 Feb 2010 20:17:43 -0600 > > Robert Noland wrote: > > > > > On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: > > > > On Wed, 10 Feb 2010 16:01:58 -0600 > > > > Robert Noland wrote: > > > > > > > > > On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: > > > > > > On Wed, 10 Feb 2010 20:33:46 +0200 > > > > > > Andriy Gapon wrote: > > > > > > > > > > > > > on 10/02/2010 20:29 Vitaly Magerya said the following: > > > > > > > > Robert Noland wrote: > > > > > > > >>> It is not, and yes I use WITHOUT_HAL. Currently > > > > > > > >>> disabling DRI helps; should I try rebuilding > > > > > > > >>> xorg-server with HAL? > > > > > > > >> Yes, you can still disable hal at runtime by setting > > > > > > > >> AutoAddDevices "Off" in xorg.conf. > > > > > > > > > > > > > > > > Seems to work with HAL. > > > > > > > > > > > > > > I've long thought that xorg server should be linked with > > > > > > > libthr regardless of HAL option. Unfortunately, I never > > > > > > > came up with patch, nor have anyone else. Xorg server > > > > > > > really uses pthreads when doing DRM and HAL brings in > > > > > > > libthr dependency only as an accident. > > > > > > > > > > > > > > > > > > > This is my first post to this list, so hello all. > > > > > > > > > > > > I have been running with NoAccel for a long time, since > > > > > > disabling DRI alone would cause a complete deadlock (screen > > > > > > to standby, no ssh, no response to keyboard, etc.). > > > > > > > > > > > > However, I rebuilt xorg-server with HAL support, and now > > > > > > simply disabling DRI allows me to start X. > > > > > > > > > > > > The card is RV790 based. > > > > > > > > > > Just checked... This card should work with Accel and DRI... At > > > > > least on -CURRENT with updated ports. Check UPDATING, and set > > > > > WITHOUT_NOUVEAU to get correct version of libdrm. > > > > > > > > > > robert. > > > > > > > > > > > > > I am on -STABLE built on Jan. 19. I updated mesa today (to > > > > libdrm-2.4.17), and rebuilt xorg-server and drivers. I have > > > > WITHOUT_NOUVEAU="YES" in /etc/make.conf. pkg_info reports > > > > libGL-7.6.1. > > > > > > Is that 8-STABLE or 7? 8 should work, and I think 7 should as > > > well, but just checking. 6 won't work. > > > > > I am on 8-STABLE. > > > > I have tried loading radeon.ko manually before startx. > > > > > > What are the results? If things are not working, I'll want to see > > > your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri with X > > > started if you can get it. > > > > > > robert. > > > > > > > I have attached the output from pciconf -lvb, sysctl -a |grep > > ^hw.dri reports: > > > > hw.dri.0.name: radeon 0x96 > > hw.dri.0.vm: > > hw.dri.0.clients: > > hw.dri.0.vblank: > > hw.dri.0.debug: 0 > > > > I loaded radeon.ko from within my X session, which was started with > > DRI "OFF". > > Ok, if X doesn't try to open drm, then nothing will show up as being > mapped. If you do a "sysctl hw.dri" it will show the mappings, but > the above grep is cutting out most of the useful info. > Sorry, I did not understand what you wanted, here is "sysctl hw.dri": hw.dri.0.name: radeon 0x96 hw.dri.0.vm: slot offset size type flags address mtrr 0 0x00000000fe8e0000 0x00010000 REG 0x82 0xffffff00fe8e0000 no hw.dri.0.clients: a dev pid uid magic ioctls hw.dri.0.vblank: crtc ref count last enabled inmodeset 00 00 00000000 00000000 00 00 01 00 00000000 00000000 00 00 hw.dri.0.debug: 0 > > If I run startx with DRI "True" or without an xorg.conf, the > > screen goes into standby as if the pc is turned off, the mouse and > > keyboard stops responding to keypresses (ie. numlock-led will not > > respond to me pressing the key.) and I cannot ssh into the machine. > > As far as I can tell it has crashed. > > > > There is nothing in /var/log/messages, which gives any indication > > that something went wrong (If I boot the machine - startx and force > > a reboot I get 2 x dmesg plus fsck messages). > > > > Xorg.0.log contains only messages from the last successful start of > > xorg, and is a far as I can tell useless in tracking this down. > > This sounds suspiciously like a WITNESS issue... I wonder if I have > accidentally MFC'd something that isn't safe. You don't get a core > dump eventually do you? > > robert. > I have left it for at least the time it takes to boot my laptop and try to ssh into the machine (5 min.). I have dumpdev defined. I will crash it and leave it for 15 min. to see if something happens. > > > > If it will help, I can switch to -CURRENT to see if that changes > > > > anything. > > > > > > > > Martin > > > > > > > > PS. Robert, in researching this I got some idea of the effort > > > > you put into this, thanks! > > > > > > > Martin > > -- Martin Kristensen From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 13:57:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B03A1065672; Thu, 11 Feb 2010 13:57:23 +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 3AFD48FC0A; Thu, 11 Feb 2010 13:57:23 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E183C46B51; Thu, 11 Feb 2010 08:57:22 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 2A8728A021; Thu, 11 Feb 2010 08:57:22 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 11 Feb 2010 08:13:25 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B72FC55.2090508@icyb.net.ua> <9bbcef731002101038r1ac04141t505216816489376f@mail.gmail.com> In-Reply-To: <9bbcef731002101038r1ac04141t505216816489376f@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002110813.26005.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 11 Feb 2010 08:57:22 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org, Ivan Voras , Andriy Gapon Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 13:57:23 -0000 On Wednesday 10 February 2010 1:38:37 pm Ivan Voras wrote: > On 10 February 2010 19:35, Andriy Gapon wrote: > > on 10/02/2010 20:26 Ivan Voras said the following: > >> On 10 February 2010 19:10, Andriy Gapon wrote: > >>> on 10/02/2010 20:03 Ivan Voras said the following: > >>>> When you say "very unique" is it in the "it is not Linux or Windows" > >>>> sense or do we do something nonstandard? > >>> The former - neither Linux, Windows or OpenSolaris seem to have what we have. > >> > >> I can't find the exact documents but I think both Windows > >> MegaUltimateServer (the highest priced version of Windows Server, > >> whatever it's called today) and Linux (though disabled and marked > >> Experimental) have it, or have some kind of support for large pages > >> that might not be as pervasive (maybe they use it for kernel only?). I > >> have no idea about (Open)Solaris. > > > > I haven't said that those OSes do not use large pages. > > I've said what I've said :-) > > Ok :) > > Is there a difference between "large pages" as they are commonly known > and "superpages" as in FreeBSD ? In other words - are you referencing > some specific mechanism, like automatic promotion / demotion of the > large pages or maybe something else? Yes, the automatic promotion / demotion. That is a far-less common feature. FreeBSD/i386 has used large pages for the kernel text as far back as at least 4.x, but that is not the same as superpages. Linux does not have automatic promotion / demotion to my knowledge. I do not know about other OS's. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 15:00:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5E2E1065696; Thu, 11 Feb 2010 15:00:17 +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 A00FC8FC12; Thu, 11 Feb 2010 15:00:15 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA25561; Thu, 11 Feb 2010 17:00:13 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B741B7D.1030306@icyb.net.ua> Date: Thu, 11 Feb 2010 17:00:13 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: alc@freebsd.org References: <4B72D94A.8030509@icyb.net.ua> <4B72E93C.80102@icyb.net.ua> <9bbcef731002101003r203f5189xf139700a0d48afa0@mail.gmail.com> <4B72F67F.4000209@icyb.net.ua> <9bbcef731002101026k5007075cqf97fc80404ac3fa7@mail.gmail.com> <4B72FC55.2090508@icyb.net.ua> <9bbcef731002101038r1ac04141t505216816489376f@mail.gmail.com> <20100210184623.GA78851@icarus.home.lan> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Ivan Voras , Jeremy Chadwick Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 15:00:17 -0000 on 11/02/2010 06:37 Alan Cox said the following: > Here is what I know. Several of us, myself included, have been able to > reproduce either lockups or machine check exceptions when BOTH the machine > check driver and superpages are enabled on AMD family 10h processors. There > have been no reports of this problem on either Intel or earlier AMD > processors. Moreover, there is no evidence of instability in AMD family 10h > processors until the machine check driver is enabled. By default, FreeBSD > 8.0 enables superpages but disables the machine check driver. So, running > natively, i.e., without virtualization, you shouldn't experience a problem, > unless you explicitly enable the machine check driver. However, running on > top of a hypervisor, like vSphere 4, you might face a problem because the > hypervisor might enable machine check exceptions, regardless of what the > FreeBSD guest does. I really don't know whether vSphere 4 enables machine > check exception or not. If it does, then either you disable the use of > superpages in the FreeBSD guest, or you find a way to disable the machine > check driver in the hypervisor. I'd like to mention another possibility, just in case: machine check might be enabled/done by firmware (e.g. BIOS). This typically could be the case for high-end-ish/server systems. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 16:09:43 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AAA41065672 for ; Thu, 11 Feb 2010 16:09:43 +0000 (UTC) (envelope-from ru@freebsd.org) Received: from mail.vega.ru (mail.vega.ru [90.156.167.5]) by mx1.freebsd.org (Postfix) with ESMTP id E9C048FC1F for ; Thu, 11 Feb 2010 16:09:42 +0000 (UTC) Received: from [10.100.124.99] (helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nfbbn-00094T-KK; Thu, 11 Feb 2010 19:09:39 +0300 Date: Thu, 11 Feb 2010 19:09:38 +0300 From: Ruslan Ermilov To: Dan Nelson , stable@freebsd.org Message-ID: <20100211160938.GA53792@edoofus.dev.vega.ru> References: <20100210085814.GE9748@acme.spoerlein.net> <20100210104904.GA85373@edoofus.dev.vega.ru> <20100210180535.GG9748@acme.spoerlein.net> <20100210210007.GB9318@dan.emsphone.com> <20100211074051.GI9748@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100211074051.GI9748@acme.spoerlein.net> Cc: Subject: Re: numeric sort(1) is broken on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 16:09:43 -0000 On Thu, Feb 11, 2010 at 08:40:51AM +0100, Ulrich Spörlein wrote: > On Wed, 10.02.2010 at 15:00:07 -0600, Dan Nelson wrote: > > In the last episode (Feb 10), Ulrich Spörlein said: > > > On Wed, 10.02.2010 at 13:49:05 +0300, Ruslan Ermilov wrote: > > > > On Wed, Feb 10, 2010 at 09:58:14AM +0100, Ulrich Spörlein wrote: > > > > > not sure if this is a pilot error, but it seems to me that gnu sort -n > > > > > is broken on at least -STABLE (couldn't test -CURRENT yet). > > > > > > > > > > It somehow does not manifest when using a simple list and sorting on a > > > > > specific column, but it always happens to me when using it in > > > > > combination with find(1). > > > > > > > > > > % truncate -s10m a; truncate -s5m b; truncate -s800k c > > > > > % find a b c -ls|sort -nk7,7 > > > > > 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a > > > > > 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b > > > > > 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c > > > > > > > > I bet you're using some non-C locale for LC_NUMERIC. What does "locale" > > > > output tell you? > > > > > > Yes and no. LC_NUMERIC is still at C, LC_CTYPE is set to UTF-8, but as > > > there are no non-ASCII symbols in that output it shouldn't matter, right? > > > For me, 819200 is smaller than 10485760 in pretty much all locales. Why > > > the hell is a numeric gnusort locale dependant? Why is -g working anyway? > > > > Try adding a 'b' to your sort flags. I bet the leading spaces in front of > > your numbers are being treated as part of the sort key. Maybe de_DE.UTF-8 > > and C have different ideas of what is whitespace? > > Indeed, 'b' is working too. So I've stocked up on the number of > workarounds for this problem. What amazes me, is that no one seems to be > as shocked as I to find out something basic like sorting on a number is > not DTRT. It is a long standing issue with Russian locales as well, but there the problem manifests itself only with LC_NUMERIC, not LC_CTYPE. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 16:43:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C5861065694; Thu, 11 Feb 2010 16:43:52 +0000 (UTC) (envelope-from mik@pc.dk) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by mx1.freebsd.org (Postfix) with ESMTP id B6CB58FC0A; Thu, 11 Feb 2010 16:43:51 +0000 (UTC) Received: from alpha.miknet.dk (0x5738c19d.rdnqu2.dynamic.dsl.tele.dk [87.56.193.157]) by pfepa.post.tele.dk (Postfix) with ESMTP id 46B26A50054; Thu, 11 Feb 2010 17:43:05 +0100 (CET) Date: Thu, 11 Feb 2010 17:41:24 +0100 From: Martin Kristensen To: Robert Noland Message-ID: <20100211174124.7573bb91@alpha.miknet.dk> In-Reply-To: <20100211145044.205a3e2b@alpha.miknet.dk> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> <4B72FC0A.1020701@icyb.net.ua> <20100210220508.790ee773@alpha.miknet.dk> <1265839318.8609.104.camel@balrog.2hip.net> <20100210234315.7abde83c@alpha.miknet.dk> <1265854663.8609.117.camel@balrog.2hip.net> <20100211114910.392f919e@alpha.miknet.dk> <1265890573.8609.151.camel@balrog.2hip.net> <20100211145044.205a3e2b@alpha.miknet.dk> Organization: Private X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 16:43:52 -0000 On Thu, 11 Feb 2010 14:50:44 +0100 Martin Kristensen wrote: > On Thu, 11 Feb 2010 06:16:12 -0600 > Robert Noland wrote: > > > On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: > > > On Wed, 10 Feb 2010 20:17:43 -0600 > > > Robert Noland wrote: > > > > > > > On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: > > > > > On Wed, 10 Feb 2010 16:01:58 -0600 > > > > > Robert Noland wrote: > > > > > > > > > > > On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: > > > > > > > On Wed, 10 Feb 2010 20:33:46 +0200 > > > > > > > Andriy Gapon wrote: > > > > > > > > > > > > > > > on 10/02/2010 20:29 Vitaly Magerya said the following: > > > > > > > > > Robert Noland wrote: > > > > > > > > >>> It is not, and yes I use WITHOUT_HAL. Currently > > > > > > > > >>> disabling DRI helps; should I try rebuilding > > > > > > > > >>> xorg-server with HAL? > > > > > > > > >> Yes, you can still disable hal at runtime by setting > > > > > > > > >> AutoAddDevices "Off" in xorg.conf. > > > > > > > > > > > > > > > > > > Seems to work with HAL. > > > > > > > > > > > > > > > > I've long thought that xorg server should be linked with > > > > > > > > libthr regardless of HAL option. Unfortunately, I never > > > > > > > > came up with patch, nor have anyone else. Xorg server > > > > > > > > really uses pthreads when doing DRM and HAL brings in > > > > > > > > libthr dependency only as an accident. > > > > > > > > > > > > > > > > > > > > > > This is my first post to this list, so hello all. > > > > > > > > > > > > > > I have been running with NoAccel for a long time, since > > > > > > > disabling DRI alone would cause a complete deadlock > > > > > > > (screen to standby, no ssh, no response to keyboard, > > > > > > > etc.). > > > > > > > > > > > > > > However, I rebuilt xorg-server with HAL support, and now > > > > > > > simply disabling DRI allows me to start X. > > > > > > > > > > > > > > The card is RV790 based. > > > > > > > > > > > > Just checked... This card should work with Accel and DRI... > > > > > > At least on -CURRENT with updated ports. Check UPDATING, > > > > > > and set WITHOUT_NOUVEAU to get correct version of libdrm. > > > > > > > > > > > > robert. > > > > > > > > > > > > > > > > I am on -STABLE built on Jan. 19. I updated mesa today (to > > > > > libdrm-2.4.17), and rebuilt xorg-server and drivers. I have > > > > > WITHOUT_NOUVEAU="YES" in /etc/make.conf. pkg_info reports > > > > > libGL-7.6.1. > > > > > > > > Is that 8-STABLE or 7? 8 should work, and I think 7 should as > > > > well, but just checking. 6 won't work. > > > > > > > I am on 8-STABLE. > > > > > I have tried loading radeon.ko manually before startx. > > > > > > > > What are the results? If things are not working, I'll want to > > > > see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri > > > > with X started if you can get it. > > > > > > > > robert. > > > > > > > > > > I have attached the output from pciconf -lvb, sysctl -a |grep > > > ^hw.dri reports: > > > > > > hw.dri.0.name: radeon 0x96 > > > hw.dri.0.vm: > > > hw.dri.0.clients: > > > hw.dri.0.vblank: > > > hw.dri.0.debug: 0 > > > > > > I loaded radeon.ko from within my X session, which was started > > > with DRI "OFF". > > > > Ok, if X doesn't try to open drm, then nothing will show up as being > > mapped. If you do a "sysctl hw.dri" it will show the mappings, but > > the above grep is cutting out most of the useful info. > > > Sorry, I did not understand what you wanted, here is "sysctl hw.dri": > hw.dri.0.name: radeon 0x96 > hw.dri.0.vm: > slot offset size type flags address > mtrr 0 0x00000000fe8e0000 0x00010000 REG 0x82 0xffffff00fe8e0000 no > > hw.dri.0.clients: > a dev pid uid magic ioctls > > hw.dri.0.vblank: > crtc ref count last enabled inmodeset > 00 00 00000000 00000000 00 00 > 01 00 00000000 00000000 00 00 > hw.dri.0.debug: 0 > > > If I run startx with DRI "True" or without an xorg.conf, the > > > screen goes into standby as if the pc is turned off, the mouse and > > > keyboard stops responding to keypresses (ie. numlock-led will not > > > respond to me pressing the key.) and I cannot ssh into the > > > machine. As far as I can tell it has crashed. > > > > > > There is nothing in /var/log/messages, which gives any indication > > > that something went wrong (If I boot the machine - startx and > > > force a reboot I get 2 x dmesg plus fsck messages). > > > > > > Xorg.0.log contains only messages from the last successful start > > > of xorg, and is a far as I can tell useless in tracking this down. > > > > This sounds suspiciously like a WITNESS issue... I wonder if I have > > accidentally MFC'd something that isn't safe. You don't get a core > > dump eventually do you? > > > > robert. > > > I have left it for at least the time it takes to boot my laptop and > try to ssh into the machine (5 min.). I have dumpdev defined. > > I will crash it and leave it for 15 min. to see if something happens. > Alas, I have crashed it a couple of times and left it for ~30 min. There was no change, and I got no core dump. > > > > > If it will help, I can switch to -CURRENT to see if that > > > > > changes anything. > > > > > > > > > > Martin > > > > > > > > > > PS. Robert, in researching this I got some idea of the effort > > > > > you put into this, thanks! > > > > > > > > > > Martin > > > > > > -- Martin Kristensen From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 17:02:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 392BF1065746 for ; Thu, 11 Feb 2010 17:02:50 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (router.rabson.org [80.177.232.241]) by mx1.freebsd.org (Postfix) with ESMTP id 9BDE48FC1E for ; Thu, 11 Feb 2010 17:02:49 +0000 (UTC) Received: from macpro.dyn.rabson.org (macpro.dyn.rabson.org [192.168.42.241]) by itchy.rabson.org (Postfix) with ESMTP id 357715C33; Thu, 11 Feb 2010 16:47:19 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Doug Rabson In-Reply-To: <4B6D3A18.2030304@eng.auth.gr> Date: Thu, 11 Feb 2010 16:46:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0DDBB542-5BCF-485B-ACF9-0EE977E74A92@rabson.org> References: <4B6BE7A2.6000402@eng.auth.gr> <4B6D3A18.2030304@eng.auth.gr> To: George Mamalakis X-Mailer: Apple Mail (2.1077) Cc: Rick Macklem , freebsd-stable , freebsd-current@freebsd.org Subject: Re: Kerberized NFSv3 incorrect behavior X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 17:02:50 -0000 On 6 Feb 2010, at 09:44, George Mamalakis wrote: > Rick Macklem wrote: >>=20 >>=20 >> On Fri, 5 Feb 2010, George Mamalakis wrote: >>=20 >>> Dear all, >>>=20 >>> I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My = configuration is based on = http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup. My = goal is to share filesystems securely through kerberos authentication. = Everything works fine, until I try to kdestroy my tickets or kinit to = some other user, where the system insists to think that I am the user = that initially obtained their ticket. To be more extensive, my story is = as follows: >>>=20 >> [good stuff snipped] >>>=20 >>>=20 >>> and both client and server have the correct entries about each other = (and themselves) in their /etc/hosts, so heimdal works just fine. >>>=20 >>> Both client and server have their respective keytabs stored in = /etc/krb5.keytab, and I use two users in my example (that both exist in = both systems with the same uid,gid): mamalos and testakis. >>>=20 >>=20 >> Unless you have applied the experimental patch, a keytab entry is >> meaningless in the client. Without that, it was assumed that "root" >> would never "kinit" as anyone. Basically, it was assumed that "root" >> would only do the mount and a user, like "mamalos" or "testakis" >> would be logged in and kinit'd as that user. >>=20 >> The short answer is that any principal with TGT in the credentials >> cache for uid=3D=3DN will be used to authenticate that user. Once >> authenticated, that "handle" for the user can be used until it >> expires (up to the server, but usually set to when the TGT that >> it found in the credential cache is due to expire). >>=20 >>> So, when I mount the exported filesystem on the client giving: >>>=20 >>> # mount -o nvfsv3,sec=3Dkrb5 server.example.com:/exports /mnt >>> # mount >>> /dev/da0s1a on / (ufs, local, soft-updates) >>> devfs on /dev (devfs, local, multilabel) >>> server.example.com:/exports on /mnt (nfs) >>>=20 >>> and try to access the share: >>> # ls /mnt >>> ls: mnt: Permission denied >>>=20 >>> I get the error I am expecting, since root does not have any = kerberos tickets assigned, yet. Let's see what happens when I kinit as = mamalos: >>=20 >> Yep, as expected. >>> # klist >>> Credentials cache: FILE:/tmp/krb5cc_0 >>> Principal: mamalos@EXAMPLE.COM >>>=20 >>> Issued Expires Principal >>> Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/EXAPMLE.COM@EXAMPLE.COM >>> # ls -la /mnt/ >>> total 8 >>> drwxr-xr-x 4 root wheel - 512 4 Feb 19:03 ./ >>> drwxr-xr-x 21 root wheel - 512 3 Feb 11:27 ../ >>> drwx------ 2 mamalos wheel - 512 5 Feb 11:11 mamalos/ >>> drwx------ 2 testakis wheel - 512 4 Feb 19:06 testakis/ >>> # touch /mnt/mamalos/myfile >>> # ls -la /mnt/mamalos/myfile >>> rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:22 /mnt/mamalos/myfile >>>=20 >>> Which is the exact behavior that is expected. Now when I kdestroy: >>> # kdestroy >>> # klist >>> klist: No ticket file: /tmp/krb5cc_0 >>> # touch /mnt/mamalos/myfilethatshouldnotbe >>> # ls -la /mnt/mamalos/myfilethatshouldnotbe >>> -rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:24 = /mnt/mamalos/myfilethatshouldnotbe >>>=20 >>=20 >> Yes, this is a "bug/limitation" in the current implementation. I = believe >> that "kdestroy" should do some sort of system call to inform the NFS >> client that "credentials for uid=3D=3DN" should be invalidated. This = is not >> implemented in FreeBSD8 (or Linux for that matter, last I checked). >> I don't know if dfr@ was planning on doing this and whether or not he >> thinks it is appropriate to do so? >>=20 >> Without that implemented, the "handle" continues to work until the >> server expires it, normally when the TGT for "mamalos" would have >> expired if you hadn't kdestroy'd it. >>=20 >>> And I can do everything in that share as if I were still mamalos, = even though I kdestroyed my kerberos ticket. The same thing will happen = even if I kinit to testakis after that. klist shows testakis' ticket = this time, but I am not allowed to access (rwx) tetakis' files/folders, = and I still have full control over mamalos' files and folders. >>>=20 >>> In order to be able to do something as testakis, I have to unmount = the share and remount it while having testakis' ticket (or having no = ticket at all, and giving kinit testakis after mounting the share). >>>=20 >>=20 >> Actually, logging in as "testakis" should allow that user to access = the >> mount as "testakis" once kinit'd as "testakis". The trick is that the >> credential cache entry needs to be in /tmp/krb5cc_N (where 'N' is the >> uid assigned to "testakis"). Same would apply to "mamalos" if that >> user were logged in with a non-0 uid. >>=20 >>> I am not an NFS expert, but I suppose that this behavior is not the = one to be expected, except if I am missing some fundamental information = about kerberized NFS that explains it. Even so, it would be quite unwise = to behave so, since even if the users kdestroys their tickets, they have = still all permissions as when they obtained their ticket. >>>=20 >>=20 >> Yes, as noted above, I believe that "kdestroy" should get rid of the >> Kerberized NFS "handles" for the corresponding "uid". It's on my >> "to discuss with dfr and maybe do" list, but unfortunately not near >> the top of it. (I'd also like to come up with a good way to do >> initiator credentials from a keytab entry. The experimental patch >> is considered unacceptable for FreeBSD-current etc.) >>=20 >> Hope that clarifies things, rick >>=20 >> _______________________________________________ >> 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 > Rick, >=20 > thank you for all your answers. I am planning on setting up the = computer labs of my department using kerberized nfsv3 (since v4 seems to = be "more" experimental) with a FreeBSD nfs server and Linux nfs clients. = I was wondering "how stable" such an implementation would be; meaning = that I wouldn't want to end up with an unstsable setup when receiving = requests from 50-60 simultaneous clients, because that would be my = everyday scenario. >=20 > Thanks again for all your explanations (you covered me fully) and for = your understanding of my remarks. I think all that is needed is for kdestroy to make a syscall on the = client to flush cached credentials - the server clean up automatically = after the cred expires. As long as the client deletes its cached cred = (and the associated keying materials), there should be no security = issues. I believe Solaris does it this way. =20 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 17:06:59 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AC02106566B for ; Thu, 11 Feb 2010 17:06:59 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f191.google.com (mail-yx0-f191.google.com [209.85.210.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1DF818FC16 for ; Thu, 11 Feb 2010 17:06:58 +0000 (UTC) Received: by yxe29 with SMTP id 29so1241559yxe.14 for ; Thu, 11 Feb 2010 09:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=BobVeSscA4vZO5i3zd8AMQilW/vxCG3dbDu5wOXVvvg=; b=J4km3selN6ro1leex5kGGpr01Dk4y6LbonuWnFigMayLGlCyazATNBaTSTfippLQaZ mmwSdY51KC3DXZNfCacnqfYoikEA45N5LtfWFHJ3GVrGKmlTQMzGEKJa9gY39Qf+gfTB 7sHzTW9X+ia/eCX1uPj6pJH5gBdsWnyb99LYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=NOeQAyvHaZhOXbU/wXQeXc3GpNH2V00H4eNWzA0gHNEP++CHIgoCyGK/2owU8av3sM PJzwJ3cvMfI+ptirWW1ddSHPSb2ke2vXzkyQu4J0+KrdgZ5eDUuPEqyys4gZMqHlwY5I EQP7f8LLUedYk+h8VZiX+KDMTHYpCpB9hN2WA= Received: by 10.150.176.6 with SMTP id y6mr572609ybe.280.1265908017423; Thu, 11 Feb 2010 09:06:57 -0800 (PST) Received: from ppp-21.247.dialinfree.com (ppp-21.247.dialinfree.com [209.172.21.247]) by mx.google.com with ESMTPS id 6sm976929ywc.8.2010.02.11.09.06.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Feb 2010 09:06:53 -0800 (PST) Sender: "J. Hellenthal" Date: Thu, 11 Feb 2010 12:05:45 -0500 From: jhell To: David Wolfskill In-Reply-To: <20100209224149.GR391@bunrab.catwhisker.org> Message-ID: References: <20100209224149.GR391@bunrab.catwhisker.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@freebsd.org Subject: Re: 7.3-P r203700: what can I do about "psm0: the aux device is gone!" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 17:06:59 -0000 On Tue, 9 Feb 2010 17:41, david@ wrote: > I normally run X11 (via xdm) on my laptop. > > Today, running FreeBSD 7.3-PRERELEASE as of r203700, the mouse stopped > moving. > > Logging in from a pty & checking the last bit of /var/log/messages > showed: > > Feb 9 14:30:27 localhost kernel: kbdc: TEST_AUX_PORT status:0000 > Feb 9 14:30:27 localhost kernel: kbdc: RESET_AUX return code:00fa > Feb 9 14:30:27 localhost kernel: kbdc: RESET_AUX status:ffffffff > Feb 9 14:30:27 localhost kernel: kbdc: DIAGNOSE status:0055 > Feb 9 14:30:27 localhost kernel: kbdc: TEST_KBD_PORT status:0000 > Feb 9 14:30:27 localhost kernel: psm0: failed to reset the aux device. > Feb 9 14:30:27 localhost kernel: psm0: the aux device has gone! (reinitialize). > > > uname output: > > FreeBSD localhost 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #56 r203700: Tue Feb 9 05:31:36 PST 2010 root@g1-136.catwhisker.org:/common/S2/obj/usr/src/sys/CANARY i386 > > So far, the least disruptive form of evasive action I've found is a > reboot, which is quite a bit more disruptive than I'd prefer. > > Help? > > Thanks! > > Peace, > david > High David, I'm assuming that you've checked to make sure that moused is running after psm has disappeared ?. As a somewhat workaround until the cause of this problem can be determined you could setup a cronjob as root to check for moused and if not found restart it. Add moused_port="/dev/ums?" to /etc/rc.conf and replace ? with corresponding device number. Add the following to /etc/crontab pgrep moused ||service moused restart Of course this does not detect which moused is running and for what device so some adjustment might be needed there if you have more then one moused running at a time usually. Good Luck. -- jhell From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 17:11:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F18A31065696 for ; Thu, 11 Feb 2010 17:11:50 +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 9DA058FC1F for ; Thu, 11 Feb 2010 17:11:50 +0000 (UTC) Received: from [192.168.1.4] (adsl-19-244-133.bna.bellsouth.net [68.19.244.133]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1BHBYTm013400 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 12:11:43 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Martin Kristensen In-Reply-To: <20100211174124.7573bb91@alpha.miknet.dk> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <4B72D57D.6080002@icyb.net.ua> <4B72D854.5080902@gmail.com> <1265818363.8609.70.camel@balrog.2hip.net> <4B72FB00.3000105@gmail.com> <4B72FC0A.1020701@icyb.net.ua> <20100210220508.790ee773@alpha.miknet.dk> <1265839318.8609.104.camel@balrog.2hip.net> <20100210234315.7abde83c@alpha.miknet.dk> <1265854663.8609.117.camel@balrog.2hip.net> <20100211114910.392f919e@alpha.miknet.dk> <1265890573.8609.151.camel@balrog.2hip.net> <20100211145044.205a3e2b@alpha.miknet.dk> <20100211174124.7573bb91@alpha.miknet.dk> Content-Type: text/plain Organization: FreeBSD Date: Thu, 11 Feb 2010 11:11:28 -0600 Message-Id: <1265908288.8609.163.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 17:11:51 -0000 On Thu, 2010-02-11 at 17:41 +0100, Martin Kristensen wrote: > On Thu, 11 Feb 2010 14:50:44 +0100 > Martin Kristensen wrote: > > > On Thu, 11 Feb 2010 06:16:12 -0600 > > Robert Noland wrote: > > > > > On Thu, 2010-02-11 at 11:49 +0100, Martin Kristensen wrote: > > > > On Wed, 10 Feb 2010 20:17:43 -0600 > > > > Robert Noland wrote: > > > > > > > > > On Wed, 2010-02-10 at 23:43 +0100, Martin Kristensen wrote: > > > > > > On Wed, 10 Feb 2010 16:01:58 -0600 > > > > > > Robert Noland wrote: > > > > > > > > > > > > > On Wed, 2010-02-10 at 22:05 +0100, Martin Kristensen wrote: > > > > > > > > On Wed, 10 Feb 2010 20:33:46 +0200 > > > > > > > > Andriy Gapon wrote: > > > > > > > > > > > > > > > > > on 10/02/2010 20:29 Vitaly Magerya said the following: > > > > > > > > > > Robert Noland wrote: > > > > > > > > > >>> It is not, and yes I use WITHOUT_HAL. Currently > > > > > > > > > >>> disabling DRI helps; should I try rebuilding > > > > > > > > > >>> xorg-server with HAL? > > > > > > > > > >> Yes, you can still disable hal at runtime by setting > > > > > > > > > >> AutoAddDevices "Off" in xorg.conf. > > > > > > > > > > > > > > > > > > > > Seems to work with HAL. > > > > > > > > > > > > > > > > > > I've long thought that xorg server should be linked with > > > > > > > > > libthr regardless of HAL option. Unfortunately, I never > > > > > > > > > came up with patch, nor have anyone else. Xorg server > > > > > > > > > really uses pthreads when doing DRM and HAL brings in > > > > > > > > > libthr dependency only as an accident. > > > > > > > > > > > > > > > > > > > > > > > > > This is my first post to this list, so hello all. > > > > > > > > > > > > > > > > I have been running with NoAccel for a long time, since > > > > > > > > disabling DRI alone would cause a complete deadlock > > > > > > > > (screen to standby, no ssh, no response to keyboard, > > > > > > > > etc.). > > > > > > > > > > > > > > > > However, I rebuilt xorg-server with HAL support, and now > > > > > > > > simply disabling DRI allows me to start X. > > > > > > > > > > > > > > > > The card is RV790 based. > > > > > > > > > > > > > > Just checked... This card should work with Accel and DRI... > > > > > > > At least on -CURRENT with updated ports. Check UPDATING, > > > > > > > and set WITHOUT_NOUVEAU to get correct version of libdrm. > > > > > > > > > > > > > > robert. > > > > > > > > > > > > > > > > > > > I am on -STABLE built on Jan. 19. I updated mesa today (to > > > > > > libdrm-2.4.17), and rebuilt xorg-server and drivers. I have > > > > > > WITHOUT_NOUVEAU="YES" in /etc/make.conf. pkg_info reports > > > > > > libGL-7.6.1. > > > > > > > > > > Is that 8-STABLE or 7? 8 should work, and I think 7 should as > > > > > well, but just checking. 6 won't work. > > > > > > > > > I am on 8-STABLE. > > > > > > I have tried loading radeon.ko manually before startx. > > > > > > > > > > What are the results? If things are not working, I'll want to > > > > > see your xorg.conf, xorg.log, pciconf -lvb and a sysctl hw.dri > > > > > with X started if you can get it. > > > > > > > > > > robert. > > > > > > > > > > > > > I have attached the output from pciconf -lvb, sysctl -a |grep > > > > ^hw.dri reports: > > > > > > > > hw.dri.0.name: radeon 0x96 > > > > hw.dri.0.vm: > > > > hw.dri.0.clients: > > > > hw.dri.0.vblank: > > > > hw.dri.0.debug: 0 > > > > > > > > I loaded radeon.ko from within my X session, which was started > > > > with DRI "OFF". > > > > > > Ok, if X doesn't try to open drm, then nothing will show up as being > > > mapped. If you do a "sysctl hw.dri" it will show the mappings, but > > > the above grep is cutting out most of the useful info. > > > > > Sorry, I did not understand what you wanted, here is "sysctl hw.dri": > > hw.dri.0.name: radeon 0x96 > > hw.dri.0.vm: > > slot offset size type flags address > > mtrr 0 0x00000000fe8e0000 0x00010000 REG 0x82 0xffffff00fe8e0000 no > > > > hw.dri.0.clients: > > a dev pid uid magic ioctls > > > > hw.dri.0.vblank: > > crtc ref count last enabled inmodeset > > 00 00 00000000 00000000 00 00 > > 01 00 00000000 00000000 00 00 > > hw.dri.0.debug: 0 > > > > If I run startx with DRI "True" or without an xorg.conf, the > > > > screen goes into standby as if the pc is turned off, the mouse and > > > > keyboard stops responding to keypresses (ie. numlock-led will not > > > > respond to me pressing the key.) and I cannot ssh into the > > > > machine. As far as I can tell it has crashed. > > > > > > > > There is nothing in /var/log/messages, which gives any indication > > > > that something went wrong (If I boot the machine - startx and > > > > force a reboot I get 2 x dmesg plus fsck messages). > > > > > > > > Xorg.0.log contains only messages from the last successful start > > > > of xorg, and is a far as I can tell useless in tracking this down. > > > > > > This sounds suspiciously like a WITNESS issue... I wonder if I have > > > accidentally MFC'd something that isn't safe. You don't get a core > > > dump eventually do you? > > > > > > robert. > > > > > I have left it for at least the time it takes to boot my laptop and > > try to ssh into the machine (5 min.). I have dumpdev defined. > > > > I will crash it and leave it for 15 min. to see if something happens. > > > Alas, I have crashed it a couple of times and left it for ~30 min. There > was no change, and I got no core dump. Hrm, ok... I'll try to dig into it this weekend... robert. > > > > > > If it will help, I can switch to -CURRENT to see if that > > > > > > changes anything. > > > > > > > > > > > > Martin > > > > > > > > > > > > PS. Robert, in researching this I got some idea of the effort > > > > > > you put into this, thanks! > > > > > > > > > > > > > Martin > > > > > > > > > > > > > -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 17:16:23 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42AA7106568D for ; Thu, 11 Feb 2010 17:16:23 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 0554A8FC0C for ; Thu, 11 Feb 2010 17:16:22 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o1BHG4L9023278; Thu, 11 Feb 2010 09:16:04 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o1BHG4YL023277; Thu, 11 Feb 2010 09:16:04 -0800 (PST) (envelope-from david) Date: Thu, 11 Feb 2010 09:16:04 -0800 From: David Wolfskill To: jhell Message-ID: <20100211171604.GX391@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , jhell , stable@freebsd.org References: <20100209224149.GR391@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bU/r/G0m9ZRUgpzh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org Subject: Re: 7.3-P r203700: what can I do about "psm0: the aux device is gone!" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 17:16:23 -0000 --bU/r/G0m9ZRUgpzh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 11, 2010 at 12:05:45PM -0500, jhell wrote: > ...=20 > >Feb 9 14:30:27 localhost kernel: psm0: failed to reset the aux device. > >Feb 9 14:30:27 localhost kernel: psm0: the aux device has gone!=20 > >(reinitialize). > ... > >So far, the least disruptive form of evasive action I've found is a > >reboot, which is quite a bit more disruptive than I'd prefer. > > > >Help? > ... > I'm assuming that you've checked to make sure that moused is running afte= r=20 > psm has disappeared ?. I have verifies that it is not, in fact, running: it exits when its device disappears. > As a somewhat workaround until the cause of this problem can be determine= d=20 > you could setup a cronjob as root to check for moused and if not found=20 > restart it. Except that it won't start without a (detectable) device. > Add moused_port=3D"/dev/ums?" to /etc/rc.conf and replace ? with=20 > corresponding device number. No USB rodents on my laptop. :-} > Add the following to /etc/crontab > pgrep moused ||service moused restart >=20 > Of course this does not detect which moused is running and for what devic= e=20 > so some adjustment might be needed there if you have more then one moused= =20 > running at a time usually. The touchpad/trackpoint show up as a single /dev/psm0, as far as I can tell: d254(7.3-P)[1] ls -lT /dev/psm* crw-rw-rw- 1 root wheel 0, 56 Feb 11 08:03:06 2010 /dev/psm0 d254(7.3-P)[2] grep -C 5 psm /var/run/dmesg.boot=20 pcm0: clone manager: deadline=3D750ms flags=3D0x8000001e pcm0: sndbuf_setmap 7db40000, 4000; 0xc527d000 -> 7db40000 pcm0: sndbuf_setmap 7db44000, 4000; 0xc5281000 -> 7db44000 pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0065 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 speaker0: port 0x61,0x63,0x65,0x67 on acpi0 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on= acpi0 fdc0: ic_type 90 part_id 80 fdc0: [FILTER] sio0: irq maps: 0x201 0x211 0x201 0x201 d254(7.3-P)[3]=20 > Good Luck. > ... Thanks. :-} Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --bU/r/G0m9ZRUgpzh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkt0O1QACgkQmprOCmdXAD2s4gCggUjyUqCjY/o5+XUegsVDTLJN DxsAmwYQDSFyPiOXP/x63sCTwi8JvACG =hm0n -----END PGP SIGNATURE----- --bU/r/G0m9ZRUgpzh-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 17:19:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA996106566B for ; Thu, 11 Feb 2010 17:19:17 +0000 (UTC) (envelope-from hk@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5159E8FC13 for ; Thu, 11 Feb 2010 17:19:16 +0000 (UTC) Received: from alogis.com (localhost [127.0.0.1]) by alogis.com (8.13.4/8.13.1) with ESMTP id o1BHJFt9023750; Thu, 11 Feb 2010 18:19:15 +0100 (CET) (envelope-from hk@alogis.com) Received: (from hk@localhost) by alogis.com (8.13.4/8.13.1/Submit) id o1BHJFgQ023749; Thu, 11 Feb 2010 18:19:15 +0100 (CET) (envelope-from hk) Date: Thu, 11 Feb 2010 18:19:15 +0100 From: Holger Kipp To: freebsd-stable@freebsd.org Message-ID: <20100211171915.GA23559@intserv.int1.b.intern> References: <20100209182005.GA58395@intserv.int1.b.intern> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100209182005.GA58395@intserv.int1.b.intern> User-Agent: Mutt/1.4.2.1i Subject: Problem with USB wireless keyboard/mouse (7-STABLE / GENERIC) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 17:19:17 -0000 Some additional information Same problem now with latest 7-STABLE (two days ago) compiled with GENERIC kernel settings. instead of Unknown USB device I now get the dreaded SHORT_XFER-Error. Apart from that still same behaviour. Anything else I can do? On Tue, Feb 09, 2010 at 07:20:05PM +0100, Holger Kipp wrote: > My son bought a wireless USB deskset (keyboard and mouse) from TRUST. > > Of course it does not work with freebsd 7.1 (I am currently updating > to 7-STABLE just in case). Anyway, here the problem with TRUST Wireless Deskset: > > Feb 8 22:00:32 TheSimpsons root: Unknown USB device: vendor 0x04fc product 0x05d8 bus uhub3 > Feb 8 22:00:37 TheSimpsons kernel: uhub3: port 2, set config at addr 2 failed > Feb 8 22:00:37 TheSimpsons kernel: uhub3: device problem (TIMEOUT), disabling port 2 > > any ideas? There is nothing else showing up. Interestingly, the keyboard > is working within BIOS without problems. Same problem with and without ACPI > and switching on legacy mode in BIOS does not help either. > > Keyboard is the german version, Item number 16595. > > If I can provide anything else, please let me know. > > > Best Regards, > Holger From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 17:25:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5867106566B for ; Thu, 11 Feb 2010 17:25:52 +0000 (UTC) (envelope-from alexshub@mail.ru) Received: from fallback2.mail.ru (fallback2.mail.ru [94.100.176.87]) by mx1.freebsd.org (Postfix) with ESMTP id 2D3B48FC1F for ; Thu, 11 Feb 2010 17:25:51 +0000 (UTC) Received: from mx76.mail.ru (mx76.mail.ru [94.100.176.91]) by fallback2.mail.ru (mPOP.Fallback_MX) with ESMTP id 8E54114B6EFA for ; Thu, 11 Feb 2010 19:35:47 +0300 (MSK) Received: from [212.119.190.162] (port=38035 helo=[127.0.0.1]) by mx76.mail.ru with psmtp id 1Nfc0p-000AiE-00; Thu, 11 Feb 2010 19:35:31 +0300 Message-ID: <4B7431D2.2090404@mail.ru> Date: Thu, 11 Feb 2010 19:35:30 +0300 From: Alex Shubnikov Organization: Public Adress User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?UTF-8?B?R2Vycml0IEvDvGhu?= References: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-stable@freebsd.org Subject: Re: zpool vdev vs. glabel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 17:25:52 -0000 Use gpart and add created partition to your raidz- for example [code] backupstorage# gpart create -s GPT ad0 backupstorage# gpart add -b 34 -s 1953525101 -i 1 -t freebsd-zfs -l disk0 ad0 backupstorage# gpart show => 34 1953525101 da0 GPT (932G) 34 1953525101 1 freebsd-zfs (932G) backupstorage# gpart show -l => 34 1953525101 da0 GPT (932G) 34 1953525101 1 disk0 (932G) backupstorage# ls /dev/gpt disk0 backupstorage# zpool status -v pool: storage state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 gpt/disk4 ONLINE 0 0 0 gpt/disk5 ONLINE 0 0 0 gpt/disk6 ONLINE 0 0 0 gpt/disk7 ONLINE 0 0 0 [code] Try to remove and insert disks- all it should happy =) PS: sorry for my english =) Gerrit Kühn пишет: > Hi, > > I have created a raidz2 with disk I labeled with glabel before. Right > after creation this pool looked fine, using devices label/tank[1-6]. > > I did some tests with replacing/swapping disks and so on. After doing a > > zpool offline tank label/tank6 > remove disk > camcontrol rescan all > insert disk > camcontrol rescan all > zpool online tank label/tank6 > > I got the disk back, but not under the requested label, but under the da > device name: > > pool: tank > state: ONLINE > scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:56:37 > 2010 config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > label/tank1 ONLINE 0 0 0 8.50K resilvered > label/tank2 ONLINE 0 0 0 7.50K resilvered > label/tank3 ONLINE 0 0 0 8.50K resilvered > label/tank4 ONLINE 0 0 0 7.50K resilvered > label/tank5 ONLINE 0 0 0 9K resilvered > da6 ONLINE 0 0 0 13.5K resilvered > > errors: No known data errors > > > > Why does this happen? Is there any way to get zfs to use the label again? > After the device is in use, the label in /dev/label disappears. When > taking the device offline again, the label is there, but cannot be used: > > pigpen# zpool offline tank da6 > pigpen# zpool status > pool: system > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are > unaffected. action: Determine if the device needs to be replaced, and > clear the errors using 'zpool clear' or replace the device with 'zpool > replace'. see: http://www.sun.com/msg/ZFS-8000-9P > scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:49:14 > 2010 config: > > NAME STATE READ WRITE CKSUM > system ONLINE 0 0 0 > mirror ONLINE 0 0 0 > label/system1 ONLINE 3 617 0 126K resilvered > label/system2 ONLINE 0 0 0 41K resilvered > > errors: No known data errors > > pool: tank > state: DEGRADED > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are > unaffected. action: Determine if the device needs to be replaced, and > clear the errors using 'zpool clear' or replace the device with 'zpool > replace'. see: http://www.sun.com/msg/ZFS-8000-9P > scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:56:37 > 2010 config: > > NAME STATE READ WRITE CKSUM > tank DEGRADED 0 0 0 > raidz2 DEGRADED 0 0 0 > label/tank1 ONLINE 0 0 0 8.50K resilvered > label/tank2 ONLINE 0 0 0 7.50K resilvered > label/tank3 ONLINE 0 0 0 8.50K resilvered > label/tank4 ONLINE 0 0 0 7.50K resilvered > label/tank5 ONLINE 0 0 0 9K resilvered > da6 OFFLINE 0 38 0 13.5K resilvered > > errors: No known data errors > pigpen# ll /dev/label/ > total 0 > crw-r----- 1 root operator 0, 104 Feb 9 14:04 lisacrypt1 > crw-r----- 1 root operator 0, 112 Feb 9 14:04 lisacrypt2 > crw-r----- 1 root operator 0, 113 Feb 9 14:04 lisacrypt3 > crw-r----- 1 root operator 0, 134 Feb 9 14:48 system1 > crw-r----- 1 root operator 0, 115 Feb 9 14:04 system2 > crw-r----- 1 root operator 0, 116 Feb 9 14:04 tank1 > crw-r----- 1 root operator 0, 117 Feb 9 14:04 tank2 > crw-r----- 1 root operator 0, 118 Feb 9 14:04 tank3 > crw-r----- 1 root operator 0, 101 Feb 9 14:04 tank4 > crw-r----- 1 root operator 0, 102 Feb 9 14:04 tank5 > crw-r----- 1 root operator 0, 103 Feb 9 15:02 tank6 > > pigpen# zpool online tank label/tank6 > cannot online label/tank6: no such device in pool > > In a different thread I found the hint to use zpool replace to get to the > usage of labels, but this seems not possible, either: > > pigpen# zpool replace tank label/tank6 > invalid vdev specification > use '-f' to override the following errors: > /dev/label/tank6 is part of active pool 'tank' > > pigpen# zpool replace -f tank label/tank6 > invalid vdev specification > the following errors must be manually repaired: > /dev/label/tank6 is part of active pool 'tank' > > pigpen# zpool replace -f tank da6 label/tank6 > invalid vdev specification > the following errors must be manually repaired: > /dev/label/tank6 is part of active pool 'tank' > > > I'm running out of ideas here... > > > > cu > Gerrit > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 18:06:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89E961065672 for ; Thu, 11 Feb 2010 18:06:22 +0000 (UTC) (envelope-from my.nwsgrp@gmail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id 0E63F8FC1B for ; Thu, 11 Feb 2010 18:06:21 +0000 (UTC) Received: by bwz3 with SMTP id 3so1253069bwz.13 for ; Thu, 11 Feb 2010 10:06:20 -0800 (PST) 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=tEqaa5MWwnU2pEd6nDhCBvrRu2bhThZ0VGZFsXdNNGE=; b=I0xLJpT+7OnkoPeqdZTjsxYMOA9lLsxY2mAODiHOr0r37JZj6BizRAjKYCi9DJWK3V WL6JIqRfSORAXLs64IHmmE0BWN6UdX9IKkSwkd/kyNMzF3XVmz1syu/AUf0pR1yk2ir3 4RSHlgik0D5NAFjHbSfqELYZYlcaN3XtlGnsQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KanF36JJ2qeJrdkCv3HMyyNL2ZR3/5Y8saA/BpQBZ1WwjI0g5c7Rf+oxCZjnxWKgp+ Y5q8uO56VETr3iJztkiKkxb/gsw/d2/hUW8MGRargVVHvvuBSmgjDNKG4Xf155ByYpg7 3LkZuwcj7LcgGXj9M48NEGRHNQfSR5668fZSc= MIME-Version: 1.0 Received: by 10.204.10.9 with SMTP id n9mr99893bkn.41.1265908384169; Thu, 11 Feb 2010 09:13:04 -0800 (PST) Date: Thu, 11 Feb 2010 20:13:04 +0300 Message-ID: <626ad50e1002110913w668f0884q22dd73b8a140e6c8@mail.gmail.com> From: GLADtr GLADtr To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ping: sendto: Can't assign requested address X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 18:06:22 -0000 Hello my friends! Help me please with its problem. I`m don`t what it is problem... *mx# uname -a* FreeBSD mx.taricat.ru 8.0-STABLE FreeBSD 8.0-STABLE #1: Mon Jan 25 09:28:38 UTC 2010 root@mx.taricat.ru:/usr/obj/usr/src/sys/GENERIC i386 mx# *mx# ping 127.0.0.1* PING 127.0.0.1 (127.0.0.1): 56 data bytes ping: sendto: Can't assign requested address ping: sendto: Can't assign requested address ^C --- 127.0.0.1 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss *mx# ping localhost* PING localhost (127.0.0.1): 56 data bytes ping: sendto: Can't assign requested address ping: sendto: Can't assign requested address ^C --- localhost ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss *mx# ping `hostname`* ping: cannot resolve mx.taricat.ru: Host name lookup failure *mx# ping google.com* PING google.com (74.125.87.103): 56 data bytes 64 bytes from 74.125.87.103: icmp_seq=0 ttl=56 time=188.367 ms 64 bytes from 74.125.87.103: icmp_seq=1 ttl=56 time=180.537 ms ^C --- google.com ping statistics --- 3 packets transmitted, 2 packets received, 33.3% packet loss round-trip min/avg/max/stddev = 180.537/184.452/188.367/3.915 ms *mx# ping 10.10.0.113* PING 10.10.0.113 (10.10.0.113): 56 data bytes ^C --- 10.10.0.113 ping statistics --- 193 packets transmitted, 0 packets received, 100.0% packet loss mx# *mx# netstat -rn* Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.10.0.126 UGS 2 97 xl0 10.10.0.112/28 link#1 U 2 465 xl0 10.10.0.114 link#1 UHS 0 0 lo0 Protocol Family 28: Destination Gateway Flags Netif Expire (28) 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 (28) 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 UH lo0 (28) 0000 0000 0000 fe80 0003 0000 0000 0000 0000 0000 0000 0000 0000 link#3 U lo0 (28) 0000 0000 0000 fe80 0003 0000 0000 0000 0000 0000 0001 0000 0000 link#3 UHS lo0 (28) 0000 0000 0000 ff01 0003 0000 0000 0000 0000 0000 0000 0000 0000 (28) 0000 0000 0000 fe80 0003 0000 0000 0000 0000 0000 0001 0000 0000 U lo0 (28) 0000 0000 0000 ff02 0003 0000 0000 0000 0000 0000 0000 0000 0000 (28) 0000 0000 0000 fe80 0003 0000 0000 0000 0000 0000 0001 0000 0000 U lo0 mx# *mx# less /etc/rc.conf* hostname="mx.taricat.ru" #ifconfig_xl0="inet 91.198.171.167 netmask 91.198.171.128" #defaultrouter="91.198.171.129" #ifconfig_ste0="inet 10.10.11.100 netmask 255.255.255.0" #pf_enable=YES #pf_rules="/etc/pf/conf" #named_enable=YES ifconfig_xl0="DHCP" sshd_enable=YES #pflog_enable=YES #clear_tmp_enable=YES #smartd_enabled=YES #samba_enable=YES #nmbd_enable=YES #smbd_enable=YES #samba_config="/usr/local/etc/smb.conf" #zfs_enable="YES" /etc/rc.conf (END) From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 18:07:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EF581065693 for ; Thu, 11 Feb 2010 18:07:09 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2148FC23 for ; Thu, 11 Feb 2010 18:07:08 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KXO00A0BVNGKU50@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Thu, 11 Feb 2010 19:06:52 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KXO00ANPVNGJOA1@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Thu, 11 Feb 2010 19:06:52 +0100 (CET) Date: Thu, 11 Feb 2010 19:06:52 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 18:07:09 -0000 Hi, One of my machines, the fileserver-with-zfs-to-be[1] has trouble keeping correct time. Or rather, ntpd is struggling. In /var/lkog/messages I see this: Feb 7 12:05:54 kg-f2 ntpd[909]: ntpd 4.2.4p5-a (1) Feb 7 12:11:16 kg-f2 ntpd[910]: time reset +1.020413 s Feb 7 12:11:16 kg-f2 ntpd[910]: kernel time sync status change 2001 Feb 7 12:26:26 kg-f2 ntpd[910]: time reset +2.277793 s Feb 7 12:41:29 kg-f2 ntpd[910]: time reset +2.260229 s Feb 7 12:57:02 kg-f2 ntpd[910]: time reset +2.332972 s Feb 7 13:21:24 kg-f2 ntpd[910]: time reset +3.659869 s Feb 7 13:37:01 kg-f2 ntpd[910]: time reset +2.343230 s Feb 7 13:52:24 kg-f2 ntpd[910]: time reset +2.310659 s Feb 7 14:07:29 kg-f2 ntpd[910]: time reset +2.265705 s Feb 7 14:23:03 kg-f2 ntpd[910]: time reset +2.335868 s Feb 7 14:39:06 kg-f2 ntpd[910]: time reset +2.411116 s Feb 7 14:54:32 kg-f2 ntpd[910]: time reset +2.318222 s Feb 7 15:09:55 kg-f2 ntpd[910]: time reset +2.308120 s Feb 7 15:25:49 kg-f2 ntpd[910]: time reset +2.388391 s Feb 7 15:40:54 kg-f2 ntpd[910]: time reset +2.265464 s Feb 7 15:55:57 kg-f2 ntpd[910]: time reset +2.257952 s Feb 7 16:11:45 kg-f2 ntpd[910]: time reset +2.373325 s and this goes on an on, forever. At any give time, no matter how long the machine has been up, ntpq ca report this: root@kg-f2# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== kg-omni1.kg4.no 129.240.64.3 3 u 13 64 37 0.162 703.094 444.681 Note: all machines on my LAN use my firewall as the ntp server. The ntp server runs FreeBSD, none of the other machines have any trouble keeping time. My workstation for example: tingo@kg-v2$ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *kg-omni1.kg4.no 129.240.64.3 3 u 44 64 377 0.138 4.018 0.338 (my workstatuion also runs FreeBSD 8.0-stable / amd64) The machine runs FreeBSD 8.0-stable / amd64: root@kg-f2# uname -a FreeBSD kg-f2.kg4.no 8.0-STABLE FreeBSD 8.0-STABLE #2: Sun Jan 31 18:39:17 CET 2010 root@kg-f2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 So, how can I get the machine to keep time / get ntpd synchronised? References: 1) hw info: http://sites.google.com/site/tingox/ga-ma74gm-s2h 2) FreeBSD info: http://sites.google.com/site/tingox/ga-ma74gm-s2h_freebsd -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 18:13:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 322481065679; Thu, 11 Feb 2010 18:13:59 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mx1.freebsd.org (Postfix) with ESMTP id E19498FC08; Thu, 11 Feb 2010 18:13:58 +0000 (UTC) Received: by pzk39 with SMTP id 39so1792550pzk.15 for ; Thu, 11 Feb 2010 10:13:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tCuSMuEenGP4x8rPYtsz1iYb4QT2suWSUVTxtIOCkP0=; b=XTtGm1uwVKy7LMDs084Y8qiSK6tP1pFLvMD42xrXoX2GLKHBpCCrIXvFwLcEcpU0qr YtIo8Bgr1vfO4GjFxZ/9WiXpo+sS4Llp2rZ6QRUnHZR2wzq/D7dzpWc9cVh1V5Yo1wQw kNtbLerU5EHj+YJfsbTpNNN5GJPz921YF/MxI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=L+9R1dNGYDTI7/t3B8Kb5XRCZu4c4Z9SfHRdeL6NtAy1a3MWLYkW13eo19VyBSZiFk +gUMU7GEujtozGFCr7Ggs3MQnnkTsKAThAFJVl9xe01udLHAOsP/1D+SnoN7oODgKaVJ 945hjrL4ILKl7I0MHo1FJQwqPKReecOcOL2ck= MIME-Version: 1.0 Received: by 10.143.21.14 with SMTP id y14mr154051wfi.67.1265912036403; Thu, 11 Feb 2010 10:13:56 -0800 (PST) In-Reply-To: <201002110813.26005.jhb@freebsd.org> References: <4B72FC55.2090508@icyb.net.ua> <9bbcef731002101038r1ac04141t505216816489376f@mail.gmail.com> <201002110813.26005.jhb@freebsd.org> Date: Thu, 11 Feb 2010 12:13:56 -0600 Message-ID: From: Alan Cox To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, Ivan Voras , Andriy Gapon Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 18:13:59 -0000 On Thu, Feb 11, 2010 at 7:13 AM, John Baldwin wrote: > On Wednesday 10 February 2010 1:38:37 pm Ivan Voras wrote: > > On 10 February 2010 19:35, Andriy Gapon wrote: > > > on 10/02/2010 20:26 Ivan Voras said the following: > > >> On 10 February 2010 19:10, Andriy Gapon wrote: > > >>> on 10/02/2010 20:03 Ivan Voras said the following: > > >>>> When you say "very unique" is it in the "it is not Linux or Windows" > > >>>> sense or do we do something nonstandard? > > >>> The former - neither Linux, Windows or OpenSolaris seem to have what > we > have. > > >> > > >> I can't find the exact documents but I think both Windows > > >> MegaUltimateServer (the highest priced version of Windows Server, > > >> whatever it's called today) and Linux (though disabled and marked > > >> Experimental) have it, or have some kind of support for large pages > > >> that might not be as pervasive (maybe they use it for kernel only?). I > > >> have no idea about (Open)Solaris. > > > > > > I haven't said that those OSes do not use large pages. > > > I've said what I've said :-) > > > > Ok :) > > > > Is there a difference between "large pages" as they are commonly known > > and "superpages" as in FreeBSD ? In other words - are you referencing > > some specific mechanism, like automatic promotion / demotion of the > > large pages or maybe something else? > > Yes, the automatic promotion / demotion. That is a far-less common > feature. > FreeBSD/i386 has used large pages for the kernel text as far back as at > least > 4.x, but that is not the same as superpages. Linux does not have automatic > promotion / demotion to my knowledge. I do not know about other OS's. > > A comparison of current large page support among Unix-like and Windows operating systems has two dimensions: (1) whether or not the creation of large pages for applications is automatic and (2) whether or not the machine administrator has to statically partition the machine's physical memory between large and small pages at boot time. For FreeBSD, large pages are created automatically and there is not a static partitioning of physical memory. In contrast, Linux does not create large pages automatically and does require a static partitioning. Specifically, Linux requires the administrator to explicitly and statically partition the machine's physical memory at boot time into two parts, one that is dedicated to large pages and another for general use. To utilize large pages an application has to explicitly request memory from the dedicated large pages pool. However, to make this somewhat easier, but not automatic, there do exist re-implementations of malloc that you can explicitly link with your application. In Solaris, the application has to explicitly request the use of large pages, either via explicit kernel calls in the program or from the command line with support from a library. However, there is not a static partitioning of physical memory. So, for example, when you run the Sun jdk on Solaris, it explicitly requests large pages for much of its data, and this works without administrator having to configure the machine for large page usage. To the best of my knowledge, Windows is just like Solaris. Alan From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 18:18:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D02A5106566C for ; Thu, 11 Feb 2010 18:18:00 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id B9DE98FC1D for ; Thu, 11 Feb 2010 18:18:00 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp028.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KXO00HJ0W5OL990@asmtp028.mac.com> for freebsd-stable@freebsd.org; Thu, 11 Feb 2010 10:17:49 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002110146 From: Chuck Swiger In-reply-to: <626ad50e1002110913w668f0884q22dd73b8a140e6c8@mail.gmail.com> Date: Thu, 11 Feb 2010 10:17:48 -0800 Message-id: <23B2639F-4DA1-44BD-8C28-EAE41FA2C012@mac.com> References: <626ad50e1002110913w668f0884q22dd73b8a140e6c8@mail.gmail.com> To: GLADtr GLADtr X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org Subject: Re: ping: sendto: Can't assign requested address X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 18:18:00 -0000 Hi-- On Feb 11, 2010, at 9:13 AM, GLADtr GLADtr wrote: > Hello my friends! Help me please with its problem. I`m don`t what it is > problem... Do you have a lo0 interface? Is it up and using IP 127.0.0.1? # ifconfig lo0 lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 18:26:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A176106566C for ; Thu, 11 Feb 2010 18:26:08 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id 7380F8FC14 for ; Thu, 11 Feb 2010 18:26:08 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp025.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KXO00BCHWJBUQ00@asmtp025.mac.com> for freebsd-stable@freebsd.org; Thu, 11 Feb 2010 10:26:00 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002110148 From: Chuck Swiger In-reply-to: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> Date: Thu, 11 Feb 2010 10:25:59 -0800 Message-id: References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> To: Torfinn Ingolfsen X-Mailer: Apple Mail (2.1077) Cc: freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 18:26:08 -0000 Hi-- On Feb 11, 2010, at 10:06 AM, Torfinn Ingolfsen wrote: [ ... ] > Feb 7 16:11:45 kg-f2 ntpd[910]: time reset +2.373325 s > > and this goes on an on, forever. At any give time, no matter how long the machine has been up, ntpq ca report this: > root@kg-f2# ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > kg-omni1.kg4.no 129.240.64.3 3 u 13 64 37 0.162 703.094 444.681 The rate at which this machine is losing time is probably exceeding the ~50 seconds per day that NTPd is willing to correct without extreme measures (ie, it has to step time rather than drift-correct). You might help it maintain a more sane idea of time by using at least 4 timeservers. You might take a look at 'vmstat -i' and look out for an interrupt storm, but it's possible your hardware's clock is simply busted. Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 18:30:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6441D106566C; Thu, 11 Feb 2010 18:30: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 35DEB8FC1A; Thu, 11 Feb 2010 18:30:52 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D777646B09; Thu, 11 Feb 2010 13:30:51 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 371E48A01F; Thu, 11 Feb 2010 13:30:51 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 11 Feb 2010 12:55:46 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <20100210174338.GC39752@hades.panopticon> In-Reply-To: <20100210174338.GC39752@hades.panopticon> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002111255.46256.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 11 Feb 2010 13:30:51 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, Dmitry Marakasov Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 18:30:52 -0000 On Wednesday 10 February 2010 12:43:38 pm Dmitry Marakasov wrote: > Hi! > > I think I've reported that before, the I thought it's been fixed, > however I still get data corruptions when writing on NFS volumes. > Now I wonder - is nobody really using NFS, or do I have that much > of uncommon setup, or this is some kind of local problem? > > Client: 8.0-RELEASE i386 > Server: 8.0-RELEASE amd64 > > mount options: > nfs rw,nosuid,noexec,nfsv3,intr,soft,tcp,bg,nolockd > > Server has ZFS, but the same thing happens when sharing UFS placed on > md(4). > > I've prepared a special 1GB file to determine the details of corruption: > it's filled with 32-bit numbers each equal to it's own offset in the > file. That is, like that: > > 00000000 00 00 00 00 04 00 00 00 08 00 00 00 0c 00 00 00 |................| > 00000010 10 00 00 00 14 00 00 00 18 00 00 00 1c 00 00 00 |................| > 00000020 20 00 00 00 24 00 00 00 28 00 00 00 2c 00 00 00 | ...$...(...,...| > 00000030 30 00 00 00 34 00 00 00 38 00 00 00 3c 00 00 00 |0...4...8...<...| > > I've copied that file over NFS from client to server around 50 > times, and got 3 corruptions on 8th, 28th and 36th copies. > > Case1: single currupted block 3779CF88-3779FFFF (12408 bytes). > Data in block is shifted 68 bytes up, loosing first 68 bytes are > filling last 68 bytes with garbage. Interestingly, among that garbage > is my hostname. Is it the hostname of the server or the client? > Case2: single currupted block 2615CFA0-2615FFFF (12384 bytes). > Data is shifted by 44 bytes in the same way. > > Case3: single currepted block 3AA947A8-3AA97FFF (14424 bytes). > Data is shifted by 36 bytes in the same way. > > Any ideas? > > PS. Diffs of corrupted blocks in a text format are here: > http://people.freebsd.org/~amdmi3/diff.1.txt > http://people.freebsd.org/~amdmi3/diff.2.txt > http://people.freebsd.org/~amdmi3/diff.3.txt Can you reproduce this using a non-FreeBSD server with a FreeBSD client or a non-FreeBSD client with a FreeBSD server? That would narrow down the breakage to either the client or the server. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 18:38:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D452106566B; Thu, 11 Feb 2010 18:38:53 +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 285DC8FC18; Thu, 11 Feb 2010 18:38:52 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id CA2102C2C9B; Thu, 11 Feb 2010 12:37:37 -0600 (CST) 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 4feCQqlyYBZH; Thu, 11 Feb 2010 12:37:30 -0600 (CST) 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 BD42D2C2D5C; Thu, 11 Feb 2010 12:37:28 -0600 (CST) Message-ID: <4B744EB2.3070108@cs.rice.edu> Date: Thu, 11 Feb 2010 12:38:42 -0600 From: Alan Cox User-Agent: Thunderbird 2.0.0.23 (X11/20100102) MIME-Version: 1.0 To: Andriy Gapon References: <4B72D94A.8030509@icyb.net.ua> <4B72E93C.80102@icyb.net.ua> <9bbcef731002101003r203f5189xf139700a0d48afa0@mail.gmail.com> <4B72F67F.4000209@icyb.net.ua> <9bbcef731002101026k5007075cqf97fc80404ac3fa7@mail.gmail.com> <4B72FC55.2090508@icyb.net.ua> <9bbcef731002101038r1ac04141t505216816489376f@mail.gmail.com> <20100210184623.GA78851@icarus.home.lan> <4B741B7D.1030306@icyb.net.ua> In-Reply-To: <4B741B7D.1030306@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-stable@freebsd.org, Ivan Voras , Jeremy Chadwick Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 18:38:53 -0000 The next public revision guide from AMD will contain an errata (383) that documents the bug. However, it doesn't really tell us anything that we didn't already know. Alan From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 18:41:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF98A1065670; Thu, 11 Feb 2010 18:41:25 +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 EA4E18FC08; Thu, 11 Feb 2010 18:41:24 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA28838; Thu, 11 Feb 2010 20:41:03 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B744F3E.60908@icyb.net.ua> Date: Thu, 11 Feb 2010 20:41:02 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Alan Cox References: <4B72D94A.8030509@icyb.net.ua> <4B72E93C.80102@icyb.net.ua> <9bbcef731002101003r203f5189xf139700a0d48afa0@mail.gmail.com> <4B72F67F.4000209@icyb.net.ua> <9bbcef731002101026k5007075cqf97fc80404ac3fa7@mail.gmail.com> <4B72FC55.2090508@icyb.net.ua> <9bbcef731002101038r1ac04141t505216816489376f@mail.gmail.com> <20100210184623.GA78851@icarus.home.lan> <4B741B7D.1030306@icyb.net.ua> <4B744EB2.3070108@cs.rice.edu> In-Reply-To: <4B744EB2.3070108@cs.rice.edu> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 18:41:26 -0000 on 11/02/2010 20:38 Alan Cox said the following: > The next public revision guide from AMD will contain an errata (383) > that documents the bug. However, it doesn't really tell us anything > that we didn't already know. Pity. I sort of hoped for more, like a workaround, some magic MSR. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 18:45:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4771106566C for ; Thu, 11 Feb 2010 18:45:07 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3136D8FC0C for ; Thu, 11 Feb 2010 18:45:06 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o1BIj5Hb064934 for ; Thu, 11 Feb 2010 20:45:05 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B74502C.3080906@eng.auth.gr> Date: Thu, 11 Feb 2010 20:45:00 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 18:45:07 -0000 Dear all, I am facing many instabilities in FBSD8 with openldap-client and sasl authentication (GSSAPI in particular). I have setup an openldap 2.4.1 server with gssapi support (through cyrus-sasl-2.1.23) on a fbsd8-stable amd64 latest sources, in a esxi host. In the same host I have setup two fbsd8-stable i386 clients; one has latest sources, the other one is installed via the iso-image of January's fbsd snapshot; on both systems openldap client and sasl is installed (all ldap/cyrus versions on all hosts mentioned in this email are the same). My laptop has fbsd8-i386 stable (sources 25 January 2010), and on my laptop I have setup an fbsd8-stable i386 (snapshot iso image) on a virtualbox client. Lastly, on the esxi host I have setup another fbsd8-stable amd64 system, to act as an ldap client (latest sources). To summarize, and put a label-number on each host, we have: 1 - esxi: fbsd8(latest) amd64 openldap server 2 - esxi: fbsd8(latest) i386 openldap client 3 - esxi: fbsd8(snapshot) i386 openldap client 4 - esxi: fbsd8(latest) amd64 openldap client 5 - laptop: fbsd8(jan 25) i386 openldap client 6 - laptop/vbox: fbsd8(snapshot) i386 openldap client The openldap server is installed in a jail, and the client is tested in the same jail. Kerberos works on all machines (same /etc/krb5.conf), and ldap as well. In all machines, line 96 of /usr/bin/krb5-config is changed to read: lib_flags="$lib_flags -lgssapi -lgssapi_spnego -lgssapi_krb5 -lheimntlm" instead of: lib_flags="$lib_flags -lgssapi -lheimntlm" which was the default, since without these lines I couldn't get gssapi authentication to work for cyrus (and spnego). This change was made after recommendations given from this very mailing list, and I was very happy to see that the ldap server worked as I expected. On all system, cat /usr/local/etc/openldap/ldap.conf: BASE dc=ee,dc=auth,dc=gr URI ldap://ldap.ee.auth.gr SASL_MECH GSSAPI without kiniting in any client I get the following outcomes when I give ldapwhoami (with no arguments): 1: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) which is expected. 2: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) which is not rational at all 3: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) 4: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) which is the same as 1 (as expected) 5: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) 6: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) if I kinit to mamalos, ldapwhoami returns: 1: SASL/GSSAPI authentication started SASL username: mamalos@EE.AUTH.GR SASL SSF: 56 SASL data security layer installed. dn:uid=mamalos,ou=people,dc=ee,dc=auth,dc=gr which is super! 2: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) which is dramatic. 3: SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) 4: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2529638919 for mech unknown) which is very strange, since mech-code seems unnaturally large. 5: SASL/GSSAPI authentication started SASL username: mamalos@EE.AUTH.GR SASL SSF: 56 SASL data security layer installed. dn:uid=mamalos,ou=people,dc=ee,dc=auth,dc=gr which is super, but without kinit the same command segfaulted on this machine 6: SASL/GSSAPI authentication started SASL username: mamalos@EE.AUTH.GR SASL SSF: 56 SASL data security layer installed. dn:uid=mamalos,ou=people,dc=ee,dc=auth,dc=gr which is the exact same behavior as 5 above. All this means that there is no single pattern!!!!!!! If I gdb ldapwhoami in the clients that segfault, I get: 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"...(no debugging symbols found)... (gdb) run -d0 Starting program: /usr/local/bin/ldapwhoami -d0 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...SASL/GSSAPI authentication started Program received signal SIGSEGV, Segmentation fault. 0x2831e187 in free () from /lib/libc.so.7 (gdb) where #0 0x2831e187 in free () from /lib/libc.so.7 #1 0x2850fb82 in gss_release_buffer () from /usr/lib/libgssapi.so.10 #2 0x2850f552 in gss_release_name () from /usr/lib/libgssapi.so.10 #3 0x2850bea9 in gss_init_sec_context () from /usr/lib/libgssapi.so.10 #4 0x283f9abf in gssapi_client_mech_step () from /usr/local/lib/sasl2/libgssapiv2.so.2 #5 0x280e84b1 in sasl_client_step () from /usr/local/lib/libsasl2.so.2 #6 0x28443100 in ?? () #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0xbfbfe968 in ?? () #10 0xbfbfe954 in ?? () #11 0xbfbfe964 in ?? () #12 0x28445860 in ?? () #13 0x280e83fe in sasl_client_step () from /usr/local/lib/libsasl2.so.2 #14 0xbfbfe8a8 in ?? () #15 0x280e9135 in sasl_client_start () from /usr/local/lib/libsasl2.so.2 #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0xbfbfe968 in ?? () #19 0xbfbfe954 in ?? () #20 0xbfbfe964 in ?? () #21 0xd7a3b2da in ?? () #22 0x283abad8 in ?? () from /lib/libc.so.7 #23 0x00000000 in ?? () #24 0x283ab730 in __stderrp () from /lib/libc.so.7 #25 0xbfbfe878 in ?? () #26 0x2838c764 in vfprintf () from /lib/libc.so.7 Previous frame inner to this frame (corrupt stack?) I built openldap and cyrus-sasl on this machine from sources (not ports), and (after a long time of trying to find out how to run configure successfully in both installations) the outcome was exactly the same (meaning segfaults). So, one of my admins wrote a c program that overrides gss_release_buffer returning always 0 (what is expected after normal operation) and compiled it as a library. The program code is nothing more than just: int gss_release_buffer(void *a, void *b) { return 0; } we ld_preloaded the library, and when we ran ldapwhoami the outcome was: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2529638919 for mech unknown) When we ran it with no kerberos tickets, we got: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) The exact same errors as the aforementioned client 4 (esxi, amd64)!!!!!!!!!!!!! What on earth is happening?!?!!?!?! Now one can easily see that there is a definite problem regarding memory freeing, and after overcoming that the mech-code 2529638919 implies that some segment in memory is overwritten by some "random" value, so mech-code returns the number 2529638919 instead of a number of marginality 1. What is more definite, is that openldap doesn't work out-of-the-box if gssapi support is required, and behaves randomly in different architectures/virtualHosts/platforms. The problem may have been something related to line 96 in /usr/bin/krb5-config... I don't know. What is sure, is that I am having second thoughts on using fbsd as my openldap/heimdal server for my setup, which would be quite disappointing for me, since I am using fbsd for the last many-many years, on all my laptops and servers. The only "good part" is that the only machine that works seamlessly (until now, at least) is the heimdal/ldap server. Thank you all in advance and I hope that we will find an answer to all this. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 18:55:17 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 996AF106566C for ; Thu, 11 Feb 2010 18:55:17 +0000 (UTC) (envelope-from kazuaki@aliceblue.jp) Received: from p0248fb.kngwff01.ap.so-net.ne.jp (p024afb.tokyff01.ap.so-net.ne.jp [121.2.74.251]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6AF8FC0C for ; Thu, 11 Feb 2010 18:55:16 +0000 (UTC) Received: from undine.aliceblue.jp (unknown [192.168.11.22]) by pd5f7be.tokyff01.ap.so-net.ne.jp (Postfix) with ESMTP id 894F646726 for ; Fri, 12 Feb 2010 03:42:19 +0900 (JST) Message-ID: <4B74502D.5050509@aliceblue.jp> Date: Fri, 12 Feb 2010 03:45:01 +0900 From: Kazuaki ODA User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100211 Thunderbird/3.0.1 MIME-Version: 1.0 To: stable@freebsd.org References: <20100210085814.GE9748@acme.spoerlein.net> In-Reply-To: <20100210085814.GE9748@acme.spoerlein.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: numeric sort(1) is broken on -STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 18:55:17 -0000 On 2010/02/10 17:58, Ulrich Spörlein wrote: > Hi guys, > > not sure if this is a pilot error, but it seems to me that gnu sort -n > is broken on at least -STABLE (couldn't test -CURRENT yet). > > It somehow does not manifest when using a simple list and sorting on a > specific column, but it always happens to me when using it in > combination with find(1). > > % truncate -s10m a; truncate -s5m b; truncate -s800k c > % find a b c -ls|sort -nk7,7 > 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a > 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b > 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c > % find a b c -ls|sort -gk7,7 > 12 64 -rw-r--r-- 1 uqs wheel 819200 Feb 10 09:13 c > 10 64 -rw-r--r-- 1 uqs wheel 5242880 Feb 10 09:13 b > 8 64 -rw-r--r-- 1 uqs wheel 10485760 Feb 10 09:13 a Hi, here is a patch I've submitted about 4 years ago... http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/93566 -- Kazuaki ODA From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 19:01:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B359106568D for ; Thu, 11 Feb 2010 19:01:45 +0000 (UTC) (envelope-from my.nwsgrp@gmail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id A45658FC08 for ; Thu, 11 Feb 2010 19:01:44 +0000 (UTC) Received: by bwz3 with SMTP id 3so1312714bwz.13 for ; Thu, 11 Feb 2010 11:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=CFPlw0cy2c5RVcgqbm/ZZVZB+F/cc1GlIpHqkP6G48o=; b=fQSKN3s1mqaShWHoNh8zo4SZbEBl6biaUPHH8l26h0/Kd8pbvm6dznuKyiXWU1oHr2 iUDLWNE9a58OW9S9i4uwF4QQvwefQJZkydWT/mD8QwAEJTh6oMPQFNDMojo5M7+YZcJT 0+D+cE8oHn5Fl/gszk7tw5LL2v5vBvbO1qQAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=w9ZHjiEMRGB6rl5U92kv56wT1StunR52nCih1L3TaVSp9VAKuxLDEeutc1+rCL13GR UdIlRt8+Z+qrzxthEnkUt5tC09WrHNaHCJuZ/EFNOCjxU4wp4KwM+Dyo9wBpRE0yiCyt NwUUDdvDKBAkb/KjJhqdfI/yOrFcyidu/TANo= MIME-Version: 1.0 Received: by 10.204.3.207 with SMTP id 15mr156135bko.91.1265913341007; Thu, 11 Feb 2010 10:35:41 -0800 (PST) In-Reply-To: <626ad50e1002110913w668f0884q22dd73b8a140e6c8@mail.gmail.com> References: <626ad50e1002110913w668f0884q22dd73b8a140e6c8@mail.gmail.com> Date: Thu, 11 Feb 2010 21:35:40 +0300 Message-ID: <626ad50e1002111035g3f1b0845t3ca41ab0eae4b6de@mail.gmail.com> From: GLADtr GLADtr To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ping: sendto: Can't assign requested address X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 19:01:45 -0000 I can add output by strace for ping localhost if it is necessary 2010/2/11 GLADtr GLADtr > Hello my friends! Help me please with its problem. I`m don`t what it is > problem... > > *mx# uname -a* > FreeBSD mx.taricat.ru 8.0-STABLE FreeBSD 8.0-STABLE #1: Mon Jan 25 > 09:28:38 UTC 2010 root@mx.taricat.ru:/usr/obj/usr/src/sys/GENERIC > i386 > mx# > > *mx# ping 127.0.0.1* > PING 127.0.0.1 (127.0.0.1): 56 data bytes > ping: sendto: Can't assign requested address > ping: sendto: Can't assign requested address > ^C > --- 127.0.0.1 ping statistics --- > 2 packets transmitted, 0 packets received, 100.0% packet loss > > *mx# ping localhost* > PING localhost (127.0.0.1): 56 data bytes > ping: sendto: Can't assign requested address > ping: sendto: Can't assign requested address > ^C > --- localhost ping statistics --- > 2 packets transmitted, 0 packets received, 100.0% packet loss > > *mx# ping `hostname`* > ping: cannot resolve mx.taricat.ru: Host name lookup failure > > *mx# ping google.com* > PING google.com (74.125.87.103): 56 data bytes > 64 bytes from 74.125.87.103: icmp_seq=0 ttl=56 time=188.367 ms > 64 bytes from 74.125.87.103: icmp_seq=1 ttl=56 time=180.537 ms > ^C > --- google.com ping statistics --- > 3 packets transmitted, 2 packets received, 33.3% packet loss > round-trip min/avg/max/stddev = 180.537/184.452/188.367/3.915 ms > > *mx# ping 10.10.0.113* > PING 10.10.0.113 (10.10.0.113): 56 data bytes > > ^C > --- 10.10.0.113 ping statistics --- > 193 packets transmitted, 0 packets received, 100.0% packet loss > mx# > > *mx# netstat -rn* > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 10.10.0.126 UGS 2 97 xl0 > 10.10.0.112/28 link#1 U 2 465 xl0 > 10.10.0.114 link#1 UHS 0 0 lo0 > > Protocol Family 28: > Destination Gateway Flags Netif Expire > (28) 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 (28) > 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 UH > lo0 > (28) 0000 0000 0000 fe80 0003 0000 0000 0000 0000 0000 0000 0000 0000 > link#3 U lo0 > (28) 0000 0000 0000 fe80 0003 0000 0000 0000 0000 0000 0001 0000 0000 > link#3 UHS lo0 > (28) 0000 0000 0000 ff01 0003 0000 0000 0000 0000 0000 0000 0000 0000 (28) > 0000 0000 0000 fe80 0003 0000 0000 0000 0000 0000 0001 0000 0000 U > lo0 > (28) 0000 0000 0000 ff02 0003 0000 0000 0000 0000 0000 0000 0000 0000 (28) > 0000 0000 0000 fe80 0003 0000 0000 0000 0000 0000 0001 0000 0000 U > lo0 > mx# > > *mx# less /etc/rc.conf* > hostname="mx.taricat.ru" > #ifconfig_xl0="inet 91.198.171.167 netmask 91.198.171.128" > #defaultrouter="91.198.171.129" > #ifconfig_ste0="inet 10.10.11.100 netmask 255.255.255.0" > #pf_enable=YES > #pf_rules="/etc/pf/conf" > #named_enable=YES > ifconfig_xl0="DHCP" > sshd_enable=YES > #pflog_enable=YES > #clear_tmp_enable=YES > #smartd_enabled=YES > #samba_enable=YES > #nmbd_enable=YES > #smbd_enable=YES > #samba_config="/usr/local/etc/smb.conf" > #zfs_enable="YES" > /etc/rc.conf (END) > > > From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 19:19:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44108106566C for ; Thu, 11 Feb 2010 19:19:53 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 2B6538FC21 for ; Thu, 11 Feb 2010 19:19:52 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta05.emeryville.ca.mail.comcast.net with comcast id gheE1d0031eYJf8A5jKtVh; Thu, 11 Feb 2010 19:19:53 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta19.emeryville.ca.mail.comcast.net with comcast id gjKs1d00E3S48mS01jKtqg; Thu, 11 Feb 2010 19:19:53 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B8C9A1E3033; Thu, 11 Feb 2010 11:19:51 -0800 (PST) Date: Thu, 11 Feb 2010 11:19:51 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100211191951.GA13854@icarus.home.lan> References: <626ad50e1002110913w668f0884q22dd73b8a140e6c8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <626ad50e1002110913w668f0884q22dd73b8a140e6c8@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ping: sendto: Can't assign requested address X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 19:19:53 -0000 On Thu, Feb 11, 2010 at 08:13:04PM +0300, GLADtr GLADtr wrote: > Hello my friends! Help me please with its problem. I`m don`t what it is > problem... > > *mx# uname -a* > FreeBSD mx.taricat.ru 8.0-STABLE FreeBSD 8.0-STABLE #1: Mon Jan 25 09:28:38 > UTC 2010 root@mx.taricat.ru:/usr/obj/usr/src/sys/GENERIC i386 > mx# > > *mx# ping 127.0.0.1* > PING 127.0.0.1 (127.0.0.1): 56 data bytes > ping: sendto: Can't assign requested address > ping: sendto: Can't assign requested address > ^C > --- 127.0.0.1 ping statistics --- > 2 packets transmitted, 0 packets received, 100.0% packet loss > > *mx# ping localhost* > PING localhost (127.0.0.1): 56 data bytes > ping: sendto: Can't assign requested address > ping: sendto: Can't assign requested address > ^C > --- localhost ping statistics --- > 2 packets transmitted, 0 packets received, 100.0% packet loss > > *mx# ping `hostname`* > ping: cannot resolve mx.taricat.ru: Host name lookup failure > > *mx# ping google.com* > PING google.com (74.125.87.103): 56 data bytes > 64 bytes from 74.125.87.103: icmp_seq=0 ttl=56 time=188.367 ms > 64 bytes from 74.125.87.103: icmp_seq=1 ttl=56 time=180.537 ms > ^C > --- google.com ping statistics --- > 3 packets transmitted, 2 packets received, 33.3% packet loss > round-trip min/avg/max/stddev = 180.537/184.452/188.367/3.915 ms > > *mx# ping 10.10.0.113* > PING 10.10.0.113 (10.10.0.113): 56 data bytes > > ^C > --- 10.10.0.113 ping statistics --- > 193 packets transmitted, 0 packets received, 100.0% packet loss > mx# > > *mx# netstat -rn* > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 10.10.0.126 UGS 2 97 xl0 > 10.10.0.112/28 link#1 U 2 465 xl0 > 10.10.0.114 link#1 UHS 0 0 lo0 > > Protocol Family 28: > Destination Gateway Flags Netif Expire > (28) 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 (28) > 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 UH > lo0 > (28) 0000 0000 0000 fe80 0003 0000 0000 0000 0000 0000 0000 0000 0000 > link#3 U lo0 > (28) 0000 0000 0000 fe80 0003 0000 0000 0000 0000 0000 0001 0000 0000 > link#3 UHS lo0 > (28) 0000 0000 0000 ff01 0003 0000 0000 0000 0000 0000 0000 0000 0000 (28) > 0000 0000 0000 fe80 0003 0000 0000 0000 0000 0000 0001 0000 0000 U > lo0 > (28) 0000 0000 0000 ff02 0003 0000 0000 0000 0000 0000 0000 0000 0000 (28) > 0000 0000 0000 fe80 0003 0000 0000 0000 0000 0000 0001 0000 0000 U > lo0 > mx# > > *mx# less /etc/rc.conf* > hostname="mx.taricat.ru" > #ifconfig_xl0="inet 91.198.171.167 netmask 91.198.171.128" > #defaultrouter="91.198.171.129" > #ifconfig_ste0="inet 10.10.11.100 netmask 255.255.255.0" > #pf_enable=YES > #pf_rules="/etc/pf/conf" > #named_enable=YES > ifconfig_xl0="DHCP" > sshd_enable=YES > #pflog_enable=YES > #clear_tmp_enable=YES > #smartd_enabled=YES > #samba_enable=YES > #nmbd_enable=YES > #smbd_enable=YES > #samba_config="/usr/local/etc/smb.conf" > #zfs_enable="YES" > /etc/rc.conf (END) Your routing table *does not* match what you have in rc.conf. In fact, your IPs are no where near what's in rc.conf. Did you modify rc.conf and not reboot the box? Here's an example machine which works with dual interfaces. I've included relevant rc.conf pieces as well as the routing table. $ ifconfig -a em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:bd:46:7c inet 72.20.98.122 netmask 0xffffffc0 broadcast 72.20.98.127 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:bd:46:7d inet 10.72.0.122 netmask 0xffffff00 broadcast 10.72.0.255 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 $ netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 72.20.98.65 UGS 2 41750 em0 10.72.0.0/24 link#2 U 1 14265 em1 10.72.0.122 link#2 UHS 0 0 lo0 72.20.98.64/26 link#1 U 0 102 em0 72.20.98.122 link#1 UHS 0 0 lo0 127.0.0.1 link#3 UH 0 0 lo0 $ head -4 /etc/rc.conf hostname="ra.parodius.com" ifconfig_em0="inet 72.20.98.122 netmask 255.255.255.192" ifconfig_em1="inet 10.72.0.122 netmask 255.255.255.0" defaultrouter="72.20.98.65" -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 19:25:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD7011065672 for ; Thu, 11 Feb 2010 19:25:16 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id A4CFB8FC13 for ; Thu, 11 Feb 2010 19:25:16 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta06.emeryville.ca.mail.comcast.net with comcast id gdSU1d0021Y3wxoA6jRHgv; Thu, 11 Feb 2010 19:25:17 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id gjRG1d0073S48mS8bjRGCi; Thu, 11 Feb 2010 19:25:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1F4971E3033; Thu, 11 Feb 2010 11:25:15 -0800 (PST) Date: Thu, 11 Feb 2010 11:25:15 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100211192515.GB13854@icarus.home.lan> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 19:25:16 -0000 On Thu, Feb 11, 2010 at 07:06:52PM +0100, Torfinn Ingolfsen wrote: > Hi, > > One of my machines, the fileserver-with-zfs-to-be[1] has trouble > keeping correct time. Or rather, ntpd is struggling. > In /var/lkog/messages I see this: > Feb 7 12:05:54 kg-f2 ntpd[909]: ntpd 4.2.4p5-a (1) > Feb 7 12:11:16 kg-f2 ntpd[910]: time reset +1.020413 s > Feb 7 12:11:16 kg-f2 ntpd[910]: kernel time sync status change 2001 > Feb 7 12:26:26 kg-f2 ntpd[910]: time reset +2.277793 s > Feb 7 12:41:29 kg-f2 ntpd[910]: time reset +2.260229 s > Feb 7 12:57:02 kg-f2 ntpd[910]: time reset +2.332972 s > Feb 7 13:21:24 kg-f2 ntpd[910]: time reset +3.659869 s > Feb 7 13:37:01 kg-f2 ntpd[910]: time reset +2.343230 s > Feb 7 13:52:24 kg-f2 ntpd[910]: time reset +2.310659 s > Feb 7 14:07:29 kg-f2 ntpd[910]: time reset +2.265705 s > Feb 7 14:23:03 kg-f2 ntpd[910]: time reset +2.335868 s > Feb 7 14:39:06 kg-f2 ntpd[910]: time reset +2.411116 s > Feb 7 14:54:32 kg-f2 ntpd[910]: time reset +2.318222 s > Feb 7 15:09:55 kg-f2 ntpd[910]: time reset +2.308120 s > Feb 7 15:25:49 kg-f2 ntpd[910]: time reset +2.388391 s > Feb 7 15:40:54 kg-f2 ntpd[910]: time reset +2.265464 s > Feb 7 15:55:57 kg-f2 ntpd[910]: time reset +2.257952 s > Feb 7 16:11:45 kg-f2 ntpd[910]: time reset +2.373325 s > > and this goes on an on, forever. At any give time, no matter how long the machine has been up, ntpq ca report this: > root@kg-f2# ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > kg-omni1.kg4.no 129.240.64.3 3 u 13 64 37 0.162 703.094 444.681 > > Note: all machines on my LAN use my firewall as the ntp server. > The ntp server runs FreeBSD, none of the other machines have any trouble keeping time. > My workstation for example: > tingo@kg-v2$ ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > *kg-omni1.kg4.no 129.240.64.3 3 u 44 64 377 0.138 4.018 0.338 > (my workstatuion also runs FreeBSD 8.0-stable / amd64) > > The machine runs FreeBSD 8.0-stable / amd64: > root@kg-f2# uname -a > FreeBSD kg-f2.kg4.no 8.0-STABLE FreeBSD 8.0-STABLE #2: Sun Jan 31 18:39:17 CET 2010 root@kg-f2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 > > So, how can I get the machine to keep time / get ntpd synchronised? > > References: > 1) hw info: http://sites.google.com/site/tingox/ga-ma74gm-s2h > 2) FreeBSD info: http://sites.google.com/site/tingox/ga-ma74gm-s2h_freebsd Your machine has a rapidly drifting clock, usually an indicator of a hardware problem (crystal gone bad is a common one -- seen this at work quite a few times), or possibly a bad time counter source chosen by the kernel. Can you please provide the output of: sysctl kern.timecounter Finally, was this OS installation used on different hardware in the past? Meaning: was the hard disk previously installed on another machine? Why I'm asking: /var/db/ntpd.drift could be from an old computer (the previous hardware), and the clock drift rate would be different than that of your newer[1] hardware. If that's the case, please stop ntpd, rm /var/db/ntpd.drift, and restart ntpd. Be aware it will take up to 72 hours for the clock drift to be calculated correctly. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 19:49:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CA061065672; Thu, 11 Feb 2010 19:49:44 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id ABA6C8FC13; Thu, 11 Feb 2010 19:49:43 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id ACF49A56C95; Fri, 12 Feb 2010 03:49:42 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id njV4tgkEgGvz; Fri, 12 Feb 2010 03:49:37 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id DBBFBA56C6F; Fri, 12 Feb 2010 03:49:35 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=WA88Um94ALJ0+s/H39CtDaPyiPFyz5tF+36H2cf/BA63XXkoKJQPj7aizxEurVGKJ Lpn9j7ULD92ghnVDXCNIg== Message-ID: <4B745F4B.3090201@delphij.net> Date: Thu, 11 Feb 2010 11:49:31 -0800 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100207 Thunderbird/3.0.1 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Jeremy Chadwick References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> In-Reply-To: <20100211192515.GB13854@icarus.home.lan> X-Enigmail-Version: 1.0 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, jkim@FreeBSD.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 19:49:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 2010/02/11 11:25, Jeremy Chadwick wrote: > On Thu, Feb 11, 2010 at 07:06:52PM +0100, Torfinn Ingolfsen wrote: >> Hi, >> >> One of my machines, the fileserver-with-zfs-to-be[1] has trouble >> keeping correct time. Or rather, ntpd is struggling. >> In /var/lkog/messages I see this: >> Feb 7 12:05:54 kg-f2 ntpd[909]: ntpd 4.2.4p5-a (1) >> Feb 7 12:11:16 kg-f2 ntpd[910]: time reset +1.020413 s >> Feb 7 12:11:16 kg-f2 ntpd[910]: kernel time sync status change 2001 >> Feb 7 12:26:26 kg-f2 ntpd[910]: time reset +2.277793 s >> Feb 7 12:41:29 kg-f2 ntpd[910]: time reset +2.260229 s >> Feb 7 12:57:02 kg-f2 ntpd[910]: time reset +2.332972 s >> Feb 7 13:21:24 kg-f2 ntpd[910]: time reset +3.659869 s >> Feb 7 13:37:01 kg-f2 ntpd[910]: time reset +2.343230 s >> Feb 7 13:52:24 kg-f2 ntpd[910]: time reset +2.310659 s >> Feb 7 14:07:29 kg-f2 ntpd[910]: time reset +2.265705 s >> Feb 7 14:23:03 kg-f2 ntpd[910]: time reset +2.335868 s >> Feb 7 14:39:06 kg-f2 ntpd[910]: time reset +2.411116 s >> Feb 7 14:54:32 kg-f2 ntpd[910]: time reset +2.318222 s >> Feb 7 15:09:55 kg-f2 ntpd[910]: time reset +2.308120 s >> Feb 7 15:25:49 kg-f2 ntpd[910]: time reset +2.388391 s >> Feb 7 15:40:54 kg-f2 ntpd[910]: time reset +2.265464 s >> Feb 7 15:55:57 kg-f2 ntpd[910]: time reset +2.257952 s >> Feb 7 16:11:45 kg-f2 ntpd[910]: time reset +2.373325 s >> >> and this goes on an on, forever. At any give time, no matter how long the machine has been up, ntpq ca report this: >> root@kg-f2# ntpq -p >> remote refid st t when poll reach delay offset jitter >> ============================================================================== >> kg-omni1.kg4.no 129.240.64.3 3 u 13 64 37 0.162 703.094 444.681 >> >> Note: all machines on my LAN use my firewall as the ntp server. >> The ntp server runs FreeBSD, none of the other machines have any trouble keeping time. >> My workstation for example: >> tingo@kg-v2$ ntpq -p >> remote refid st t when poll reach delay offset jitter >> ============================================================================== >> *kg-omni1.kg4.no 129.240.64.3 3 u 44 64 377 0.138 4.018 0.338 >> (my workstatuion also runs FreeBSD 8.0-stable / amd64) >> >> The machine runs FreeBSD 8.0-stable / amd64: >> root@kg-f2# uname -a >> FreeBSD kg-f2.kg4.no 8.0-STABLE FreeBSD 8.0-STABLE #2: Sun Jan 31 18:39:17 CET 2010 root@kg-f2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 >> >> So, how can I get the machine to keep time / get ntpd synchronised? >> >> References: >> 1) hw info: http://sites.google.com/site/tingox/ga-ma74gm-s2h >> 2) FreeBSD info: http://sites.google.com/site/tingox/ga-ma74gm-s2h_freebsd > > Your machine has a rapidly drifting clock, usually an indicator of a > hardware problem (crystal gone bad is a common one -- seen this at work > quite a few times), or possibly a bad time counter source chosen by the > kernel. Can you please provide the output of: > > sysctl kern.timecounter > > Finally, was this OS installation used on different hardware in the > past? Meaning: was the hard disk previously installed on another > machine? Why I'm asking: /var/db/ntpd.drift could be from an old > computer (the previous hardware), and the clock drift rate would be > different than that of your newer[1] hardware. If that's the case, > please stop ntpd, rm /var/db/ntpd.drift, and restart ntpd. Be aware it > will take up to 72 hours for the clock drift to be calculated correctly. I think this looks like the same problem I had with another AMD system, which may be related to some HPET stuff (I no longer have access to that system, though :( Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLdF9LAAoJEATO+BI/yjfBqacH/jreDlSiX9YCZqOSo22Dx0oW KGxuqUk6ViBTBEMOHJzpqNn37u/cbBQ7qlXaDfhg1LY825lCvx782mFGPH3J67qT IQZyLeWKGn/2BW/mhyQ9qOkEZKfifuwGmvvhxOwmnPyG2o1opFYiNxtLcJj0hPbs qqhf7wE2YzY4Khx7bTVsbclUz6kaXnusUF09Kg2F4LJ7WUilkAvFYwuG/J4sx7UN qKbw/F2bS1suyAt3cOmcb73rHN8MAbIyzjv0HOc4LUMnS6btFPUe5pqa7ghRNf7o 4wIoeGXQ6zupkjpHULIjU9hfu8uwKnTiDJ2xfJ6HjLvawsvOu/VUYvgqQM6cMd8= =Wy4x -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 21:27:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A6DA1065676 for ; Thu, 11 Feb 2010 21:27:42 +0000 (UTC) (envelope-from wotan@frii.com) Received: from smtp01.frii.com (smtp01.frii.com [216.17.135.167]) by mx1.freebsd.org (Postfix) with ESMTP id 444CD8FC0C for ; Thu, 11 Feb 2010 21:27:42 +0000 (UTC) Received: from [192.168.1.107] (c-76-25-160-90.hsd1.co.comcast.net [76.25.160.90]) by smtp01.frii.com (FRII) with ESMTP id ECBE8EA6F7 for ; Thu, 11 Feb 2010 13:55:43 -0700 (MST) Message-ID: <4B747009.9000706@frii.com> Date: Thu, 11 Feb 2010 14:00:57 -0700 From: Sean McCullough User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Hello and a small problem with 8.0-RELEASE (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 21:27:42 -0000 Hello, freebsd-stable folks! I sincerely hope I am in the correct place to inquire about a small problem I am having implementing FreeBSD 8.0-RELEASE on my AMD Athlon-64 machine. This machine runs FreeBSD 7.2 (amd64 version) without the slightest problem; but when I attempt to load 8.0 onto the machine, I can't even get sysinstall to put the kernel on to boot it. Attempting to compile and install the 8.0 kernel from source code results in a kernel which locks up at boot time after emitting a message stating "attempting to mount volumes"; a reboot of this system results in a bootloader prompt and an error message stating that no bootable kernel can be found. Any ideas? Thank You! Garrett Cooper of the freebsd-bugs list recommended I ask the above questions here: > Hi Sean, > Could you try the stable@ mailing list please? > Thanks! > -Garrett > Any ideas as to how to get the 8.0-RELEASE running on my amd64 machine would be appreciated greatly. If I need to ask elsewhere, please recommend accordingly. Thank You again, Sean McCullough From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 21:50:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0310106566C for ; Thu, 11 Feb 2010 21:50:02 +0000 (UTC) (envelope-from stadtkind2@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 0E43D8FC0C for ; Thu, 11 Feb 2010 21:50:01 +0000 (UTC) Received: (qmail invoked by alias); 11 Feb 2010 21:49:59 -0000 Received: from f053125129.adsl.alicedsl.de (EHLO localhost) [78.53.125.129] by mail.gmx.net (mp064) with SMTP; 11 Feb 2010 22:49:59 +0100 X-Authenticated: #42330871 X-Provags-ID: V01U2FsdGVkX18BfFl6UqIBXAjauOkxtZqcN53yZoU+JadJwoMq9S iryTtwW6ZFQCN3 To: freebsd-stable@freebsd.org From: Stefan Krueger In-Reply-To: <4B745F4B.3090201@delphij.net> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <4B745F4B.3090201@delphij.net> Date: Thu, 11 Feb 2010 22:49:59 +0100 User-Agent: slrn/0.9.9p1 (Linux) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <1265924999.12453@localhost> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58999999999999997 Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 21:50:02 -0000 >>> Hi, >>> >>> One of my machines, the fileserver-with-zfs-to-be[1] has trouble >>> keeping correct time. Or rather, ntpd is struggling. >>> In /var/lkog/messages I see this: >>> Feb 7 12:05:54 kg-f2 ntpd[909]: ntpd 4.2.4p5-a (1) >>> Feb 7 12:11:16 kg-f2 ntpd[910]: time reset +1.020413 s >>> Feb 7 12:11:16 kg-f2 ntpd[910]: kernel time sync status change 2001 >>> Feb 7 12:26:26 kg-f2 ntpd[910]: time reset +2.277793 s >>> Feb 7 12:41:29 kg-f2 ntpd[910]: time reset +2.260229 s >>> Feb 7 12:57:02 kg-f2 ntpd[910]: time reset +2.332972 s >>> Feb 7 13:21:24 kg-f2 ntpd[910]: time reset +3.659869 s >>> Feb 7 13:37:01 kg-f2 ntpd[910]: time reset +2.343230 s >>> Feb 7 13:52:24 kg-f2 ntpd[910]: time reset +2.310659 s >>> Feb 7 14:07:29 kg-f2 ntpd[910]: time reset +2.265705 s >>> Feb 7 14:23:03 kg-f2 ntpd[910]: time reset +2.335868 s >>> Feb 7 14:39:06 kg-f2 ntpd[910]: time reset +2.411116 s >>> Feb 7 14:54:32 kg-f2 ntpd[910]: time reset +2.318222 s >>> Feb 7 15:09:55 kg-f2 ntpd[910]: time reset +2.308120 s >>> Feb 7 15:25:49 kg-f2 ntpd[910]: time reset +2.388391 s >>> Feb 7 15:40:54 kg-f2 ntpd[910]: time reset +2.265464 s >>> Feb 7 15:55:57 kg-f2 ntpd[910]: time reset +2.257952 s >>> Feb 7 16:11:45 kg-f2 ntpd[910]: time reset +2.373325 s >>> >>> [snip] > > I think this looks like the same problem I had with another AMD system, > which may be related to some HPET stuff (I no longer have access to that > system, though :( I have the some problem on my machine (also AMD, running 8.0 + patches), after a while ntpd gives up sync'ing and then the time is off by minutes (roughly 80sec after.. say 10 hours) :( I switched to opentnpd (you can find it in ports) and the clock stays in sync now, so you might want to consider that, too PS: I had a spare disk so I tried Linux on the same machine, and ntpd is running fine for 2 days without any problems; so I guess it's not a hw fault HTH From owner-freebsd-stable@FreeBSD.ORG Thu Feb 11 22:01:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EE271065670 for ; Thu, 11 Feb 2010 22:01:11 +0000 (UTC) (envelope-from mloftis@wgops.com) Received: from juggler.wgops.com (juggler.wgops.com [204.11.247.41]) by mx1.freebsd.org (Postfix) with ESMTP id EE90A8FC17 for ; Thu, 11 Feb 2010 22:01:10 +0000 (UTC) Received: by juggler.wgops.com (Postfix, from userid 65534) id 504CAA811C; Thu, 11 Feb 2010 15:01:10 -0700 (MST) X-Spam-ASN: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on juggler.wgops.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 Received: from [192.168.1.44] (host-72-174-39-176.msl-mt.client.bresnan.net [72.174.39.176]) by juggler.wgops.com (Postfix) with ESMTPSA id 12D4FA811C for ; Thu, 11 Feb 2010 15:01:08 -0700 (MST) Date: Thu, 11 Feb 2010 15:01:26 -0700 From: Michael Loftis To: freebsd-stable@freebsd.org Message-ID: <9B1EC2BAEED06C693D8CF86F@[192.168.1.44]> In-Reply-To: <1265924999.12453@localhost> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <4B745F4B.3090201@delphij.net> <1265924999.12453@localhost> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: clamav-milter 0.95.3 at juggler X-Virus-Status: Clean Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 22:01:11 -0000 --On Thursday, February 11, 2010 10:49 PM +0100 Stefan Krueger wrote: > > PS: I had a spare disk so I tried Linux on the same machine, and > ntpd is running fine for 2 days without any problems; so I guess it's > not a hw fault It is a HW fault. FreeBSD and Linux are just picking different time sources, Linux is guessing right, FreeBSD is guessing wrong. AMD actually has pretty widely known issues with this. I've had problems mostly in Solaris/OpenSolaris though, a few with FreeBSD, and only rarely with Linux. I don't know the details, just that at least the Opteron HPET apparently isn't reliable. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 03:26:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BD811065670; Fri, 12 Feb 2010 03:26:05 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-pz0-f189.google.com (mail-pz0-f189.google.com [209.85.222.189]) by mx1.freebsd.org (Postfix) with ESMTP id 3727C8FC0A; Fri, 12 Feb 2010 03:26:05 +0000 (UTC) Received: by pzk27 with SMTP id 27so717506pzk.27 for ; Thu, 11 Feb 2010 19:26:04 -0800 (PST) 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=FGM/yCqP/8Ri/VSBZGSbvcJj7wAYQTwnr2x26PAW7eE=; b=XxLmEMbpb4PZjOQrqoj6Xdk2VWQVV3WjkVmCxU1FnWiFrekQ2XMeOeBomFXBE7sqIL gMQ3QD+J9Ktd+kWPH1LGUjusSosH06haGdCK4THixX3gD/8P2sWkDlPm9T2+2kIYw2d1 4SCLkgbr35IOyNPXZtq7pYU9ESPFsURYg46K4= 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=f5SzV1D4+q+3VavBTeVOW5GdRJn1NT/bA+08KCcYOVR+6/aphWhnpV81vI5apZl5kn CtdQKGNcAgYMOeBkOGESd9asv2TP8GEhGvd52j8rYpO9nRYoApDqDuzXXCoHvqVPNkLI 1HPmuuJ/FJH3KBgWF5E1lUddi8Edg0dyTWiK8= MIME-Version: 1.0 Received: by 10.143.153.14 with SMTP id f14mr512742wfo.255.1265945164407; Thu, 11 Feb 2010 19:26:04 -0800 (PST) In-Reply-To: <147432021002052044h591c4050ka7f39b4ec739f2a@mail.gmail.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <2a41acea1002021443t1c298528i2df3cf40269c733@mail.gmail.com> <2a41acea1002021447t1067ee42gc59b25216270459b@mail.gmail.com> <201002050351.12270.max@love2party.net> <147432021002052044h591c4050ka7f39b4ec739f2a@mail.gmail.com> Date: Thu, 11 Feb 2010 19:26:04 -0800 Message-ID: <147432021002111926x6844a1b7t4e8951223adbdc00@mail.gmail.com> From: Nick Rogers To: Max Laier Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, jfv@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel Subject: Re: em(4) + ALTQ broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 03:26:05 -0000 Anyone else get a chance to review this? On Fri, Feb 5, 2010 at 8:44 PM, Nick Rogers wrote: > I applied drbr_altq.diff to the e1000 driver (sys/dev/e1000) from HEAD on > top of 8.0-RELEASE kernel sources. It appears to have fixed the immediate > problem where queues simply don't work on em interfaces. Thanks a bunch. > > I suppose further review and testing by others would be greatly appreciated > from my point of view. I am trying to decide on a relatively stable 8.0 > kernel with working em(4) + ALTQ to put into production on 100 or so > installations. Are you guys more comfortable with the HEAD sys/dev/e1000 + > this patch on top of 8.0-RELEASE, or e1000 from 7.2 on top of 8.0-RELEASE? > So far I am having good luck with the later. Thanks again for your > contributions! > > > On Thu, Feb 4, 2010 at 6:51 PM, Max Laier wrote: > >> Okay ... attached is a patch to fix this for em(4) (and lay the groundwork >> to >> fix it for other drbr_* consumer as well). I have tested it in >> VirtualBox, >> but don't have real hardware to check for non-ALTQ performance or other >> regressions. >> >> Test, comments and review appreciated. >> >> -- >> Max >> > > From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 03:58:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A7691065672 for ; Fri, 12 Feb 2010 03:58:12 +0000 (UTC) (envelope-from wotan@frii.com) Received: from smtp01.frii.com (smtp01.frii.com [216.17.135.167]) by mx1.freebsd.org (Postfix) with ESMTP id 21E078FC15 for ; Fri, 12 Feb 2010 03:58:12 +0000 (UTC) Received: from [192.168.1.107] (c-76-25-160-90.hsd1.co.comcast.net [76.25.160.90]) by smtp01.frii.com (FRII) with ESMTP id AE42AEA51C; Thu, 11 Feb 2010 20:58:11 -0700 (MST) Message-ID: <4B74D306.7050009@frii.com> Date: Thu, 11 Feb 2010 21:03:18 -0700 From: Sean McCullough User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: nickolasbug@gmail.com, freebsd-stable@freebsd.org References: <4B747009.9000706@frii.com> <368117f31002111534q6d461a12kc00e5b07482acf6c@mail.gmail.com> In-Reply-To: <368117f31002111534q6d461a12kc00e5b07482acf6c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Hello and a small problem with 8.0-RELEASE (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 03:58:12 -0000 Hello, nicholasbug! On 2/11/2010 4:34 PM, nickolasbug@gmail.com wrote: > 2010/2/11 Sean McCullough : > >> Any ideas as to how to get the 8.0-RELEASE running on my amd64 machine >> would be appreciated greatly. If I need to ask elsewhere, please >> recommend accordingly. >> >> > Try binary update (use freebsd-update). > > Thank you for the suggestion. Unfortunately, the machine in question has no access to highspeed internet service and has dialup only. I need to be able to install the new OS from CD/DVD successfully. No disrespect intended, but I'd like to be able to live to see the solution implemented. :-) thank you again -- Sean From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 05:09:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C65A106566B for ; Fri, 12 Feb 2010 05:09:37 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 279448FC12 for ; Fri, 12 Feb 2010 05:09:36 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id o1C59acX024032; Thu, 11 Feb 2010 22:09:36 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id o1C59a69024029; Thu, 11 Feb 2010 22:09:36 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 11 Feb 2010 22:09:36 -0700 (MST) From: Warren Block To: Sean McCullough In-Reply-To: <4B74D306.7050009@frii.com> Message-ID: References: <4B747009.9000706@frii.com> <368117f31002111534q6d461a12kc00e5b07482acf6c@mail.gmail.com> <4B74D306.7050009@frii.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (wonkity.com [127.0.0.1]); Thu, 11 Feb 2010 22:09:36 -0700 (MST) Cc: freebsd-stable@freebsd.org Subject: Re: Hello and a small problem with 8.0-RELEASE (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 05:09:37 -0000 On Thu, 11 Feb 2010, Sean McCullough wrote: >> > Thank you for the suggestion. Unfortunately, the machine in question has > no access to highspeed internet service and has dialup only. I need to > be able to install the new OS from CD/DVD successfully. Posting the make and model of the machine or at least the motherboard might be helpful. CPU and RAM, too. Are you certain the CPU is amd64? -Warren Block * Rapid City, South Dakota USA From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 06:27:29 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46A7A106566C for ; Fri, 12 Feb 2010 06:27:29 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id DEE6E8FC0C for ; Fri, 12 Feb 2010 06:27:28 +0000 (UTC) Received: (qmail 20068 invoked by uid 0); 12 Feb 2010 06:27:27 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Feb 2010 06:27:27 -0000 Date: Fri, 12 Feb 2010 01:27:26 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@charles-sprickmans-imac.local To: stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: ZFS on root, serial console install X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 06:27:29 -0000 Any hints on that one? I finally got around to getting dhcp/tftp/nfs setup on an internal network to perform normal installs (and with some pxelinux hackery, the ability to boot a DOS disk or memtest86 disk images). Sysinstall in general is kind of an unweildy beast over serial, but one thing I was not able to accomplish was to get a shell (no extra virtual consoles on serial) or attempt any mounting of fixit media. From my last install that put ZFS on root, I had to do quite a bit of tapdancing since I had no DVD or bootable USB media - lots of switching from the install disk to fixit, which brought me to many chicken and egg moments. I did it though... But remotely, I'm not seeing a good way to do this. If mfsroot were larger and had more tools, then I'd be in business. This is probably the direction I need to get shoved in. I've looked at some other options with pxelinux and perhaps booting the mini ISO, but I'm not sure that gets me anywhere. Any tips? This isn't a make or break situation, I live 15 minutes from the colo... It's more of a quest. :) Thanks, Charles From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 06:48:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 278C9106566B for ; Fri, 12 Feb 2010 06:48:43 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f191.google.com (mail-yx0-f191.google.com [209.85.210.191]) by mx1.freebsd.org (Postfix) with ESMTP id CDD498FC12 for ; Fri, 12 Feb 2010 06:48:42 +0000 (UTC) Received: by yxe29 with SMTP id 29so1877900yxe.14 for ; Thu, 11 Feb 2010 22:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=AqL7BvEHHiq1IAJcQ351NQYVBKXX0HJGAkSyFdkegLE=; b=si19Wk7wykKbIX2XPmm+RFO5l6+4tbeUH2EmnHlxgaCkIMQQGBJDZC7orGDPGlzXPz 67FuLTEyxwzzvhJam+4XA7fJq2VqtmnukDl5xg+A9BLsTkZrdI7Wb0TQfYuaB6SFyLol eG94LP3nF7pnzeTePyOm1P6COVjpo4g0Wi3ow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=DsUaHZbQilE+Xn5VcS7ajdM/Xbi7jpm02WG1YPvdmumfIU+cgXnQfWt4ajUwwui8kd RtpTPCbj4Q0ZA1PmpD3Mt0zquIsGeqNw8zpJeJaLt4TBBlHmZmZDIBHmz/1HbJMEXlPv +wO74VFFUfwU9yAMM9eFCCcoFCdHmMq2hsipI= Received: by 10.101.179.27 with SMTP id g27mr1387961anp.118.1265957321855; Thu, 11 Feb 2010 22:48:41 -0800 (PST) Received: from centel.dataix.local (ppp-21.55.dialinfree.com [209.172.21.55]) by mx.google.com with ESMTPS id 22sm1258080ywh.45.2010.02.11.22.48.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Feb 2010 22:48:40 -0800 (PST) Sender: "J. Hellenthal" Date: Fri, 12 Feb 2010 01:48:25 -0500 From: jhell To: George Mamalakis In-Reply-To: <4B74502C.3080906@eng.auth.gr> Message-ID: References: <4B74502C.3080906@eng.auth.gr> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 06:48:43 -0000 On Thu, 11 Feb 2010 13:45, mamalos@ wrote: > Dear all, > > I am facing many instabilities in FBSD8 with openldap-client and sasl > authentication (GSSAPI in particular). I have setup an openldap 2.4.1 server > with gssapi support (through cyrus-sasl-2.1.23) on a fbsd8-stable amd64 > latest sources, in a esxi host. In the same host I have setup two > fbsd8-stable i386 clients; one has latest sources, the other one is installed > via the iso-image of January's fbsd snapshot; on both systems openldap > client and sasl is installed (all ldap/cyrus versions on all hosts mentioned > in this email are the same). My laptop has fbsd8-i386 stable (sources 25 > January 2010), and on my laptop I have setup an fbsd8-stable i386 (snapshot > iso image) on a virtualbox client. Lastly, on the esxi host I have setup > another fbsd8-stable amd64 system, to act as an ldap client (latest sources). > > To summarize, and put a label-number on each host, we have: > > 1 - esxi: fbsd8(latest) amd64 openldap server > 2 - esxi: fbsd8(latest) i386 openldap client > 3 - esxi: fbsd8(snapshot) i386 openldap client > 4 - esxi: fbsd8(latest) amd64 openldap client > 5 - laptop: fbsd8(jan 25) i386 openldap client > 6 - laptop/vbox: fbsd8(snapshot) i386 openldap client > > The openldap server is installed in a jail, and the client is tested in the > same jail. > > Kerberos works on all machines (same /etc/krb5.conf), and ldap as well. > > In all machines, line 96 of /usr/bin/krb5-config is changed to read: > > lib_flags="$lib_flags -lgssapi -lgssapi_spnego -lgssapi_krb5 -lheimntlm" > > instead of: > lib_flags="$lib_flags -lgssapi -lheimntlm" > > which was the default, since without these lines I couldn't get gssapi > authentication to work for cyrus (and spnego). This change was made after > recommendations given from this very mailing list, and I was very happy to > see that the ldap server worked as I expected. > > On all system, cat /usr/local/etc/openldap/ldap.conf: > > BASE dc=ee,dc=auth,dc=gr > URI ldap://ldap.ee.auth.gr > SASL_MECH GSSAPI > > > without kiniting in any client I get the following outcomes when I give > ldapwhoami (with no arguments): > > 1: > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous > failure (see text) (unknown mech-code 2 for mech unknown) > > which is expected. > > 2: > SASL/GSSAPI authentication started > Segmentation fault: 11 (core dumped) > > which is not rational at all > > 3: > SASL/GSSAPI authentication started > Segmentation fault: 11 (core dumped) > > 4: > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous > failure (see text) (unknown mech-code 2 for mech unknown) > > which is the same as 1 (as expected) > > 5: > SASL/GSSAPI authentication started > Segmentation fault: 11 (core dumped) > > 6: > SASL/GSSAPI authentication started > Segmentation fault: 11 (core dumped) > > if I kinit to mamalos, ldapwhoami returns: > > 1: > SASL/GSSAPI authentication started > SASL username: mamalos@EE.AUTH.GR > SASL SSF: 56 > SASL data security layer installed. > dn:uid=mamalos,ou=people,dc=ee,dc=auth,dc=gr > > which is super! > > 2: > SASL/GSSAPI authentication started > Segmentation fault: 11 (core dumped) > > which is dramatic. > > 3: > SASL/GSSAPI authentication started > Segmentation fault: 11 (core dumped) > > 4: > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous > failure (see text) (unknown mech-code 2529638919 for mech unknown) > > which is very strange, since mech-code seems unnaturally large. > > 5: > SASL/GSSAPI authentication started > SASL username: mamalos@EE.AUTH.GR > SASL SSF: 56 > SASL data security layer installed. > dn:uid=mamalos,ou=people,dc=ee,dc=auth,dc=gr > > which is super, but without kinit the same command segfaulted on this machine > > 6: > SASL/GSSAPI authentication started > SASL username: mamalos@EE.AUTH.GR > SASL SSF: 56 > SASL data security layer installed. > dn:uid=mamalos,ou=people,dc=ee,dc=auth,dc=gr > > which is the exact same behavior as 5 above. > > All this means that there is no single pattern!!!!!!! > > If I gdb ldapwhoami in the clients that segfault, I get: > > 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"...(no debugging symbols > found)... > (gdb) run -d0 > Starting program: /usr/local/bin/ldapwhoami -d0 > (no debugging symbols found)...(no debugging symbols found)...(no debugging > symbols found)...(no debugging symbols found)...(no debugging symbols > found)...(no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)...(no debugging symbols found)...(no debugging > symbols found)...(no debugging symbols found)...(no debugging symbols > found)...(no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)...(no debugging symbols found)...(no debugging > symbols found)...(no debugging symbols found)...(no debugging symbols > found)...(no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)...(no debugging symbols found)...(no debugging > symbols found)...(no debugging symbols found)...(no debugging symbols > found)...(no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)...SASL/GSSAPI authentication started > > Program received signal SIGSEGV, Segmentation fault. > 0x2831e187 in free () from /lib/libc.so.7 > (gdb) where > #0 0x2831e187 in free () from /lib/libc.so.7 > #1 0x2850fb82 in gss_release_buffer () from /usr/lib/libgssapi.so.10 > #2 0x2850f552 in gss_release_name () from /usr/lib/libgssapi.so.10 > #3 0x2850bea9 in gss_init_sec_context () from /usr/lib/libgssapi.so.10 > #4 0x283f9abf in gssapi_client_mech_step () from > /usr/local/lib/sasl2/libgssapiv2.so.2 > #5 0x280e84b1 in sasl_client_step () from /usr/local/lib/libsasl2.so.2 > #6 0x28443100 in ?? () > #7 0x00000000 in ?? () > #8 0x00000000 in ?? () > #9 0xbfbfe968 in ?? () > #10 0xbfbfe954 in ?? () > #11 0xbfbfe964 in ?? () > #12 0x28445860 in ?? () > #13 0x280e83fe in sasl_client_step () from /usr/local/lib/libsasl2.so.2 > #14 0xbfbfe8a8 in ?? () > #15 0x280e9135 in sasl_client_start () from /usr/local/lib/libsasl2.so.2 > #16 0x00000000 in ?? () > #17 0x00000000 in ?? () > #18 0xbfbfe968 in ?? () > #19 0xbfbfe954 in ?? () > #20 0xbfbfe964 in ?? () > #21 0xd7a3b2da in ?? () > #22 0x283abad8 in ?? () from /lib/libc.so.7 > #23 0x00000000 in ?? () > #24 0x283ab730 in __stderrp () from /lib/libc.so.7 > #25 0xbfbfe878 in ?? () > #26 0x2838c764 in vfprintf () from /lib/libc.so.7 > Previous frame inner to this frame (corrupt stack?) > > I built openldap and cyrus-sasl on this machine from sources (not ports), and > (after a long time of trying to find out how to run configure successfully in > both installations) the outcome was exactly the same (meaning segfaults). So, > one of my admins wrote a c program that overrides gss_release_buffer > returning always 0 (what is expected after normal operation) and compiled it > as a library. The program code is nothing more than just: > > int gss_release_buffer(void *a, void *b) { > return 0; > } > > we ld_preloaded the library, and when we ran ldapwhoami the outcome was: > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous > failure (see text) (unknown mech-code 2529638919 for mech unknown) > > When we ran it with no kerberos tickets, we got: > > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous > failure (see text) (unknown mech-code 2 for mech unknown) > > The exact same errors as the aforementioned client 4 (esxi, > amd64)!!!!!!!!!!!!! > > What on earth is happening?!?!!?!?! > > Now one can easily see that there is a definite problem regarding memory > freeing, and after overcoming that the mech-code 2529638919 implies that some > segment in memory is overwritten by some "random" value, so mech-code returns > the number 2529638919 instead of a number of marginality 1. > > What is more definite, is that openldap doesn't work out-of-the-box if gssapi > support is required, and behaves randomly in different > architectures/virtualHosts/platforms. > > The problem may have been something related to line 96 in > /usr/bin/krb5-config... I don't know. > > What is sure, is that I am having second thoughts on using fbsd as my > openldap/heimdal server for my setup, which would be quite disappointing for > me, since I am using fbsd for the last many-many years, on all my laptops and > servers. The only "good part" is that the only machine that works seamlessly > (until now, at least) is the heimdal/ldap server. > > Thank you all in advance and I hope that we will find an answer to all this. > > This is a lot of information to consume. Lets start with this: All of the machines in question are of some form of FreeBSD 8. You enter gdb and very clearly it starts whining about a segfault & libc.so.7 Did you happen to upgrade these clients & server from FreeBSD 7 ? AFAIK the libc version on FreeBSD 8 was bumped to libc.so.8 If you upgraded and from source did you run make delete-old and make delete-old-libs after your make install and after your mergemaster ? Will wait here for results. Best wishes. -- jhell From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 10:54:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 033B81065692 for ; Fri, 12 Feb 2010 10:54:01 +0000 (UTC) (envelope-from nickolasbug@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 8CCBF8FC1A for ; Fri, 12 Feb 2010 10:54:00 +0000 (UTC) Received: by ewy3 with SMTP id 3so2371683ewy.13 for ; Fri, 12 Feb 2010 02:53:59 -0800 (PST) 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=6EsKnEr70x1/lgFgYz3AdCmuD2Sf5v2H5Z7e3BV/tS4=; b=Lv9barKLYrnL+nPmZo3V2QrztOBFDZ4jIzELNManMNHQiRONrpj6dPMXybUHSFi6fw ViMxhFXkipfqv5eg8qfDXfv46joStiKl7Pslt7eWCIT6vbkMjd/63Q6LnTiJ3DXYTeL/ 5EedNV0j7e/miSVfpJbxtlFyx41R4RzK2kAb4= 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=ejMtWeovXCEapTy4dM2WXCnYIBcaTQ2+EwbLr1lQXAGOosfNN/+V1zD/pSdwcM4VZq 8Ut09stTPPUSUCcHUhRcVt+EZMzHBIdapM0+iREPoML6KLMWWxsxX3A+0Jkg6Zta60AY H9pThAmTv8Py/VY435V0k4OXN/2LaVHmhxO0c= MIME-Version: 1.0 Received: by 10.216.86.148 with SMTP id w20mr686245wee.112.1265972039204; Fri, 12 Feb 2010 02:53:59 -0800 (PST) In-Reply-To: <4B74D306.7050009@frii.com> References: <4B747009.9000706@frii.com> <368117f31002111534q6d461a12kc00e5b07482acf6c@mail.gmail.com> <4B74D306.7050009@frii.com> Date: Fri, 12 Feb 2010 12:53:59 +0200 Message-ID: <368117f31002120253t725ed5d9n2619d686c3303ee8@mail.gmail.com> From: nickolasbug@gmail.com To: Sean McCullough Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Hello and a small problem with 8.0-RELEASE (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 10:54:01 -0000 2010/2/12 Sean McCullough : > Hello, nicholasbug! > > On 2/11/2010 4:34 PM, nickolasbug@gmail.com wrote: >> 2010/2/11 Sean McCullough : >> >>> Any ideas as to how to get the 8.0-RELEASE running on my amd64 machine >>> would be appreciated greatly. If I need to ask elsewhere, please >>> recommend accordingly. >>> >>> >> Try binary update (use freebsd-update). >> >> > Thank you for the suggestion. Unfortunately, the machine in question has > no access to highspeed internet service and has dialup only. I need to > be able to install the new OS from CD/DVD successfully. > > No disrespect intended, but I'd like to be able to live to see the > solution implemented. =A0:-) I've had the same problem, I've reinstall OS from CD. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 12:26:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C7061065679 for ; Fri, 12 Feb 2010 12:26:09 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 191ED8FC15 for ; Fri, 12 Feb 2010 12:26:08 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KXQ00FO7AJ1QH30@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 12 Feb 2010 13:25:49 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KXQ00LEPAJ0TDW0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 12 Feb 2010 13:25:49 +0100 (CET) Date: Fri, 12 Feb 2010 13:25:48 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100212132548.8aed4d16.torfinn.ingolfsen@broadpark.no> In-reply-to: References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 12:26:09 -0000 On Thu, 11 Feb 2010 10:25:59 -0800 Chuck Swiger wrote: > The rate at which this machine is losing time is probably exceeding the ~50 seconds per day that NTPd is willing to correct without extreme measures (ie, it has to step time rather than drift-correct). > You might help it maintain a more sane idea of time by using at least 4 timeservers. Hmm, ok that iis something I can try. > You might take a look at 'vmstat -i' and look out for an interrupt storm, but it's possible your hardware's clock is simply busted. AFAICT, vmstat -i looks ok: root@kg-f2# uptime 1:23PM up 18:31, 3 users, load averages: 0.00, 0.00, 0.00 root@kg-f2# vmstat -i interrupt total rate irq1: atkbd0 36 0 irq6: fdc0 1 0 irq16: siis0 ohci0+ 408 0 irq22: atapci0 856338 12 cpu0: timer 133347678 1999 irq256: re0 234087 3 cpu1: timer 133337654 1999 Total 267776202 4016 -- Regards, Torfinn From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 12:29:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93CBF106568F for ; Fri, 12 Feb 2010 12:29:54 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 50C8D8FC1E for ; Fri, 12 Feb 2010 12:29:54 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KXQ00FVFAPNQH40@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 12 Feb 2010 13:29:47 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KXQ00H24APNHVM2@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 12 Feb 2010 13:29:47 +0100 (CET) Date: Fri, 12 Feb 2010 13:29:47 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100211192515.GB13854@icarus.home.lan> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 12:29:54 -0000 On Thu, 11 Feb 2010 11:25:15 -0800 Jeremy Chadwick wrote: > > Your machine has a rapidly drifting clock, usually an indicator of a > hardware problem (crystal gone bad is a common one -- seen this at work > quite a few times), or possibly a bad time counter source chosen by the > kernel. Can you please provide the output of: > > sysctl kern.timecounter Here it is: root@kg-f2# sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) kern.timecounter.hardware: HPET kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 52444 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-safe.mask: 4294967295 kern.timecounter.tc.ACPI-safe.counter: 3252982815 kern.timecounter.tc.ACPI-safe.frequency: 3579545 kern.timecounter.tc.ACPI-safe.quality: 850 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3443625641 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 900 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 1276479615 kern.timecounter.tc.TSC.frequency: 2819782573 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 > Finally, was this OS installation used on different hardware in the > past? Meaning: was the hard disk previously installed on another > machine? Nope. Brand new hw, hard drive, and FreeBSD 8.0-release install. Then I upgraded to 8.0-stable. > Why I'm asking: /var/db/ntpd.drift could be from an old > computer (the previous hardware), and the clock drift rate would be > different than that of your newer[1] hardware. No, /var/db/ntp.drift is created on this machine. -- Regards, Torfinn From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 12:33:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 653EF1065679 for ; Fri, 12 Feb 2010 12:33:30 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 21D628FC15 for ; Fri, 12 Feb 2010 12:33:29 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KXQ00F46AVTQH60@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 12 Feb 2010 13:33:29 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KXQ00HTOAVSHVM2@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 12 Feb 2010 13:33:29 +0100 (CET) Date: Fri, 12 Feb 2010 13:33:28 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100212133328.46847ac5.torfinn.ingolfsen@broadpark.no> In-reply-to: <1265924999.12453@localhost> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <4B745F4B.3090201@delphij.net> <1265924999.12453@localhost> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 12:33:30 -0000 On Thu, 11 Feb 2010 22:49:59 +0100 Stefan Krueger wrote: > I have the some problem on my machine (also AMD, running 8.0 + > patches), after a while ntpd gives up sync'ing and then the time is off > by minutes (roughly 80sec after.. say 10 hours) :( FWIW, I have several other AMD systems, from both Asus, MSI and Gigabyte. Noene of them have problems with ntp. > I switched to opentnpd (you can find it in ports) and the clock stays > in sync now, so you might want to consider that, too I will if that is the only solution. However, if there is something wrong with my setup / configuration of this machine, I'll rather fix that. -- Regards, Torfinn From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 13:11:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3707B1065679 for ; Fri, 12 Feb 2010 13:11:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 1C8808FC1E for ; Fri, 12 Feb 2010 13:11:18 +0000 (UTC) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta14.emeryville.ca.mail.comcast.net with comcast id h13H1d0021ZMdJ4AE1BKe8; Fri, 12 Feb 2010 13:11:19 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta16.emeryville.ca.mail.comcast.net with comcast id h1DQ1d0033S48mS8c1DQgr; Fri, 12 Feb 2010 13:13:24 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6B07C1E301A; Fri, 12 Feb 2010 05:11:17 -0800 (PST) Date: Fri, 12 Feb 2010 05:11:17 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100212131117.GA51905@icarus.home.lan> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 13:11:19 -0000 On Fri, Feb 12, 2010 at 01:29:47PM +0100, Torfinn Ingolfsen wrote: > On Thu, 11 Feb 2010 11:25:15 -0800 > Jeremy Chadwick wrote: > > > > > Your machine has a rapidly drifting clock, usually an indicator of a > > hardware problem (crystal gone bad is a common one -- seen this at work > > quite a few times), or possibly a bad time counter source chosen by the > > kernel. Can you please provide the output of: > > > > sysctl kern.timecounter > > Here it is: > root@kg-f2# sysctl kern.timecounter > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) > kern.timecounter.hardware: HPET > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.i8254.counter: 52444 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.ACPI-safe.mask: 4294967295 > kern.timecounter.tc.ACPI-safe.counter: 3252982815 > kern.timecounter.tc.ACPI-safe.frequency: 3579545 > kern.timecounter.tc.ACPI-safe.quality: 850 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.HPET.counter: 3443625641 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.quality: 900 > kern.timecounter.tc.TSC.mask: 4294967295 > kern.timecounter.tc.TSC.counter: 1276479615 > kern.timecounter.tc.TSC.frequency: 2819782573 > kern.timecounter.tc.TSC.quality: -100 > kern.timecounter.smp_tsc: 0 > kern.timecounter.invariant_tsc: 1 Please try doing this: - stop ntpd - rm /var/db/ntpd.drift - sysctl kern.timecounter.hardware=ACPI-safe - start ntpd Then see if your clock drifts. If it stops, great -- you can put that sysctl assignment line in /etc/sysctl.conf and consider it a done deal. I highly recommend putting some comments around it though so in the future you don't go "What's this? Silly!" and delete it. ;-) I'll also point out that it's common on FreeBSD[1] to see messages like the following (or at least it was circa 2006 -- I believe ntpd has been updated since then, but I've no indication said quirk was fixed/addressed): Dec 19 00:22:26 icarus ntpd[624]: kernel time sync enabled 2001 Dec 19 01:47:48 icarus ntpd[624]: kernel time sync enabled 6001 Dec 19 02:04:52 icarus ntpd[624]: kernel time sync enabled 2001 You can add the following to your ntp.conf to fix that problem: # maxpoll 9 is used to work around PLL/FLL flipping, which happens at # exactly 1024 seconds (the default maxpoll value). Another FreeBSD # user recommended using 9 instead: # http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031512.html # server some.ntp.server maxpoll 9 I recommend using the "iburst" directive on one (and only one!) server lines in your config, otherwise ntpd will usually 'settle' for about 10-15 minutes before bothering to try and update the clock the first time around. Example config: server clock.develooper.com maxpoll 9 iburst server ntp.nblug.org maxpoll 9 server tick.mtnlion.com maxpoll 9 server dewey.lib.ci.phoenix.az.us maxpoll 9 server ntp-1.cso.uiuc.edu maxpoll 9 server tick.jrc.us maxpoll 9 Finally, you should really consider adding some stratum 2 sources to your list, *in addition* to the stratum 3 server you're already using. ntpd can happily work with multiple servers, and will pick the best one as well as average them out vs. drift. It's pretty smart, honestly. We can talk about stratum 3 vs. 2 vs. 1 and use "ntpdc -c peers" to find out what those NTP servers sync with, if you'd like. [1]: http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031512.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 14:48:56 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7080106566C for ; Fri, 12 Feb 2010 14:48:56 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 9990C8FC1A for ; Fri, 12 Feb 2010 14:48:56 +0000 (UTC) Received: by gxk10 with SMTP id 10so2277804gxk.3 for ; Fri, 12 Feb 2010 06:48:56 -0800 (PST) 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=REe5YVCPYLOHTDeH0GvBeFwgl5zAFdYYNnGHJBbpIFE=; b=kCvxDzD94HhnKSK2AUJUe2GSRqBxlYfnyc96C+Y+KTXgo8d+dDGolP3rp9lsP4sAWL efk8qxJTCwhl5VC8L1uTOpJslHTKi8rmLE+YQVZEKMWmVNwT5Efr6dwDKNXAjnVt6eao nkEdPF3idTImmnz8OFPjKk49WtcAys+ByRjEQ= 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=EkScSLF4027lRlrDGDNfImZQNDqSSiv9IpBxx6eIFZMXg6GdhQSnTKrZiNFvLYGD0O iC1xvtQJiWgfwiG50njLfKESEwpi1MjRz5ZvY1gGUAR+xmpyazYmaluFvMbnv49CPZux n6FOyne6Ydi4ccCk5Wao6cBxi04FJaHWXeMO0= MIME-Version: 1.0 Received: by 10.150.48.10 with SMTP id v10mr2382642ybv.169.1265984515362; Fri, 12 Feb 2010 06:21:55 -0800 (PST) In-Reply-To: References: Date: Fri, 12 Feb 2010 06:21:55 -0800 Message-ID: From: Matt Reimer To: Charles Sprickman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: ZFS on root, serial console install X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 14:48:57 -0000 On Thu, Feb 11, 2010 at 10:27 PM, Charles Sprickman wrote: > Any hints on that one? > > I finally got around to getting dhcp/tftp/nfs setup on an internal network > to perform normal installs (and with some pxelinux hackery, the ability to > boot a DOS disk or memtest86 disk images). > > Sysinstall in general is kind of an unweildy beast over serial, but one > thing I was not able to accomplish was to get a shell (no extra virtual > consoles on serial) or attempt any mounting of fixit media. From my last > install that put ZFS on root, I had to do quite a bit of tapdancing since I > had no DVD or bootable USB media - lots of switching from the install disk > to fixit, which brought me to many chicken and egg moments. I did it > though... > > But remotely, I'm not seeing a good way to do this. If mfsroot were larger > and had more tools, then I'd be in business. This is probably the direction > I need to get shoved in. > > I've looked at some other options with pxelinux and perhaps booting the > mini ISO, but I'm not sure that gets me anywhere. > > Any tips? This isn't a make or break situation, I live 15 minutes from the > colo... It's more of a quest. :) The way I do it is to boot over the network using pxeboot, configure the partitions and ZFS pool and filesystems mounted on /mnt, then install using sysinstall, using the Options dialog to set the install directory to /mnt. I think I created the NFS filesystem using "make installworld DESTDIR=/usr/nfs/freebsd" or something like that; this gives you all the tools you need. Matt From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 16:44:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 845A01065670 for ; Fri, 12 Feb 2010 16:44:54 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 40CA98FC13 for ; Fri, 12 Feb 2010 16:44:54 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KXQ003TVMIT6540@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 12 Feb 2010 17:44:53 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KXQ00DEKMIT8901@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Fri, 12 Feb 2010 17:44:53 +0100 (CET) Date: Fri, 12 Feb 2010 17:44:52 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100212131117.GA51905@icarus.home.lan> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 16:44:54 -0000 On Fri, 12 Feb 2010 05:11:17 -0800 Jeremy Chadwick wrote: > Please try doing this: > > - stop ntpd > - rm /var/db/ntpd.drift > - sysctl kern.timecounter.hardware=ACPI-safe > - start ntpd Thanks, I'm currently testing that. Results in 72 hours (or less) :-) > Then see if your clock drifts. If it stops, great -- you can put that > sysctl assignment line in /etc/sysctl.conf and consider it a done deal. > I highly recommend putting some comments around it though so in the > future you don't go "What's this? Silly!" and delete it. ;-) Yes, I know. Learned the hard way that I need to document things for my own use. :-) > I'll also point out that it's common on FreeBSD[1] to see messages > like the following (or at least it was circa 2006 -- I believe ntpd Yes, those messages are still there. At one time, I thought about fixing that (by using the config you present), but in the end I figured that these messages actually helps me in pinpointing time of crash in the (few) cases wherer one of my machines crashes or panics. So in the end I did nothing about it. > Finally, you should really consider adding some stratum 2 sources to > your list, *in addition* to the stratum 3 server you're already using. Well, the stratum 3 server is my firewall. :) All the machines on my LAN use that one as the ntp server. My firewall is currently using three ntp servers as sources, one is a non-public stratum 2 server (yes, I asked for permission before I started using it), one is the no.poool.ntp.org pool ( stratum 3) and I just found out that the third one has stopped responding. So I removed it. I have added the dk.pool.ntp.org and se.pool.ntp.org pools, we will see how that turns out. > ntpd can happily work with multiple servers, and will pick the best one Yes, I know. It is a few years since I set this up, but at that time I figured that if I use three ntp servers for my firewall, and just used the firewall for all my internal machines, that would be good enough for my uses. Perhaps I need to re-evaluate my needs. -- Regards, Torfinn From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 16:52:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 959391065670 for ; Fri, 12 Feb 2010 16:52:26 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 697438FC08 for ; Fri, 12 Feb 2010 16:52:25 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-123.hsd1.ms.comcast.net [75.65.60.123]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id D963D37B696; Fri, 12 Feb 2010 10:52:24 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 5064C61C43; Fri, 12 Feb 2010 10:52:24 -0600 (CST) Date: Fri, 12 Feb 2010 10:52:24 -0600 From: "Matthew D. Fuller" To: Jeremy Chadwick Message-ID: <20100212165224.GH64395@over-yonder.net> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100212131117.GA51905@icarus.home.lan> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.20-fullermd.4 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 16:52:26 -0000 On Fri, Feb 12, 2010 at 05:11:17AM -0800 I heard the voice of Jeremy Chadwick, and lo! it spake thus: > > I highly recommend putting some comments around it though so in the > future you don't go "What's this? Silly!" and delete it. ;-) But do delete it every once in a while. My experience over the years is that sometimes a given OS build will do way worse than I'm used to, whereas a new build a few months later works just peachy. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 17:26:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BB78106568B; Fri, 12 Feb 2010 17:26:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 391528FC1D; Fri, 12 Feb 2010 17:26:28 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPYddUuDaFvG/2dsb2JhbACbAXTAT4RYBIMT X-IronPort-AV: E=Sophos;i="4.49,462,1262581200"; d="scan'208";a="65407644" Received: from amazon.cs.uoguelph.ca ([131.104.91.198]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 12 Feb 2010 12:26:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 2FFC621017A; Fri, 12 Feb 2010 12:26:28 -0500 (EST) X-Virus-Scanned: amavisd-new at amazon.cs.uoguelph.ca Received: from amazon.cs.uoguelph.ca ([127.0.0.1]) by localhost (amazon.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8H7z1nzp9pQ; Fri, 12 Feb 2010 12:26:27 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 4875A210174; Fri, 12 Feb 2010 12:26:27 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o1CHblx12092; Fri, 12 Feb 2010 12:37:47 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 12 Feb 2010 12:37:47 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: John Baldwin In-Reply-To: <201002111255.46256.jhb@freebsd.org> Message-ID: References: <20100210174338.GC39752@hades.panopticon> <201002111255.46256.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Dmitry Marakasov , freebsd-stable@freebsd.org Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 17:26:29 -0000 On Thu, 11 Feb 2010, John Baldwin wrote: [good stuff snipped] >> >> Case1: single currupted block 3779CF88-3779FFFF (12408 bytes). >> Data in block is shifted 68 bytes up, loosing first 68 bytes are >> filling last 68 bytes with garbage. Interestingly, among that garbage >> is my hostname. > > Is it the hostname of the server or the client? > My guess is that hades.panopticon (or something like that:-) is the client. The garbage is 4 bytes (80 00 80 84) followed by the first part of the RPC header. (Bytes 5-8 vary because they are the xid and then the host name is part of the AUTH_SYS authenticator.) For Case2 and Case3, you see less of it, but it's the same stuff. Why? I have no idea, although it smells like some sort of corruption of the mbuf list. (It would be nice if you could switch to a different net interface/driver. Just a thought, since others don't seem to be seeing this?) As John said, it would be nice to try and narrow it down to client or server side, too. Don't know if this helps or is just noise, rick From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 17:54:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79256106566B; Fri, 12 Feb 2010 17:54:26 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [92.53.116.15]) by mx1.freebsd.org (Postfix) with ESMTP id 2AFCA8FC16; Fri, 12 Feb 2010 17:54:25 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NfziU-0002TW-4q; Fri, 12 Feb 2010 20:54:10 +0300 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id E0ABBB860; Fri, 12 Feb 2010 20:54:22 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id C9D4BB829; Fri, 12 Feb 2010 20:54:22 +0300 (MSK) Date: Fri, 12 Feb 2010 20:54:22 +0300 From: Dmitry Marakasov To: Rick Macklem Message-ID: <20100212175422.GB94665@hades.panopticon> References: <20100210174338.GC39752@hades.panopticon> <201002111255.46256.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 17:54:26 -0000 * Rick Macklem (rmacklem@uoguelph.ca) wrote: > > Is it the hostname of the server or the client? > > My guess is that hades.panopticon (or something like that:-) is the Yes, that is the client. > As John said, it would be nice to try and narrow it down to client or > server side, too. I'm planning a massive testing for this weekend, including removing soft mount option and trying linux client/server. Btw, I forgot to mention that I'm experiencing other NFS problems from time to time, including "death" of a mount (that is, all processes that try to access it freeze; this cures itself in some time with a message "server is alive again"). Also I've seen another strange thing - not only the mount dies but the network is flooded with NFS traffic. Last time I've seen it quite a while ago, so I don't remember the circumstances and direction of the traffic. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 18:00:34 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A634106566C; Fri, 12 Feb 2010 18:00:34 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [92.53.116.15]) by mx1.freebsd.org (Postfix) with ESMTP id 10A838FC14; Fri, 12 Feb 2010 18:00:33 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NfzoR-0003DB-BJ; Fri, 12 Feb 2010 21:00:19 +0300 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 1F0F7B862; Fri, 12 Feb 2010 21:00:32 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 1E313B829; Fri, 12 Feb 2010 21:00:32 +0300 (MSK) Date: Fri, 12 Feb 2010 21:00:32 +0300 From: Dmitry Marakasov To: Oliver Fromme Message-ID: <20100212180032.GC94665@hades.panopticon> References: <201002102046.o1AKkrvj085173@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201002102046.o1AKkrvj085173@lurza.secnetix.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 18:00:34 -0000 * Oliver Fromme (olli@lurza.secnetix.de) wrote: > This is an excerpt from Solaris' mount_nfs(1M) manpage: > > File systems that are mounted read-write or that con- > tain executable files should always be mounted with > the hard option. Applications using soft mounted file > systems may incur unexpected I/O errors, file corrup- > tion, and unexpected program core dumps. The soft > option is not recommended. > > FreeBSD's manual page doesn't contain such a warning, but > maybe it should. (It contains a warning not to use "soft" > with NFSv4, though, for different reasons.) Interesting, I'll try disabling it. However now I really wonder why is such dangerous option available (given it's the cause) at all, especially without a notice. Silent data corruption is possibly the worst thing to happen ever. However, without soft option NFS would be a strange thing to use - network problems is kinda inevitable thing, and having all processes locked in a unkillable state (with hard mounts) when it dies is not fun. Or am I wrong? > Also note that the "nolockd" option means that processes > on different clients won't see each other's locks. That > means that you will get corruption if they rely on > locking. I know - I have no processes that use locks on that filesystems. Also there's only a single client. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 18:21:09 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACDA110656AC; Fri, 12 Feb 2010 18:21:09 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 32A068FC2C; Fri, 12 Feb 2010 18:21:09 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o1CIKowX019228; Fri, 12 Feb 2010 19:21:05 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o1CIKohU019226; Fri, 12 Feb 2010 19:20:50 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <201002121820.o1CIKohU019226@lurza.secnetix.de> To: amdmi3@amdmi3.ru (Dmitry Marakasov) Date: Fri, 12 Feb 2010 19:20:50 +0100 (CET) In-Reply-To: <20100212180032.GC94665@hades.panopticon> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 12 Feb 2010 19:21:05 +0100 (CET) Cc: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 18:21:09 -0000 Dmitry Marakasov wrote: > * Oliver Fromme (olli@lurza.secnetix.de) wrote: > > This is an excerpt from Solaris' mount_nfs(1M) manpage: > > > > File systems that are mounted read-write or that con- > > tain executable files should always be mounted with > > the hard option. Applications using soft mounted file > > systems may incur unexpected I/O errors, file corrup- > > tion, and unexpected program core dumps. The soft > > option is not recommended. > > > > FreeBSD's manual page doesn't contain such a warning, but > > maybe it should. (It contains a warning not to use "soft" > > with NFSv4, though, for different reasons.) > > Interesting, I'll try disabling it. However now I really wonder why > is such dangerous option available (given it's the cause) at all, > especially without a notice. Silent data corruption is possibly the > worst thing to happen ever. I'm sorry for the confusion ... I do not think that it's the cause for your data corruption, in this particular case. I just mentioned the potential problems with "soft" mounts because it could cause additional problems for you. (And it's important to know anyhow.) > However, without soft option NFS would be a strange thing to use - > network problems is kinda inevitable thing, and having all processes > locked in a unkillable state (with hard mounts) when it dies is not > fun. Or am I wrong? Well, this is what happens if the network hangs: 1. With "hard" mounts (the default), processes that access NFS shares are locked for as long as the network is down. 2. With "soft" mounts, binaries can coredump, and many programs won't notice that write access just failed which leads to file corruption. Personally I definitely prefer the first. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 18:31:13 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 315E51065670 for ; Fri, 12 Feb 2010 18:31:13 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id F40A38FC1B for ; Fri, 12 Feb 2010 18:31:12 +0000 (UTC) Received: from reflector.ws.pitbpa0.priv.collaborativefusion.com ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Fri, 12 Feb 2010 13:53:31 -0500 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::321 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@FreeBSD.org X-SMFBL: ZnJlZWJzZC1zdGFibGVARnJlZUJTRC5vcmc= Message-ID: <4B759E70.4030809@comcast.net> Date: Fri, 12 Feb 2010 13:31:12 -0500 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100211 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable , freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ZFS ARC being limited below what is defined in /boot/loader.conf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 18:31:13 -0000 Has anyone had an issue with the ZFS ARC max being limited below what has been defined in /boot/loader.conf? I just upgraded the RAM in a ZFS-equipped system and attempted to devote 4GB to the ARC cache by placing the following in loader.conf: vfs.zfs.arc_max="4096M" However, after rebooting, querying the sysctl gives me this: $ sysctl vfs.zfs.arc_max vfs.zfs.arc_max: 1726489600 or about 1.7GB, an odd number that I can't find any references to. For reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system with 8GB of RAM. The system was previously very stable with 4GB of RAM and a 512MB arc_max. I have not modified vm.kmem_size_max (defaults to ~330GB on amd64) or any other ZFS tunables. I'd also like to avoid syncing up to the current 8-STABLE if at all possible. Thanks, Steve Polyack From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 18:35:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 289821065672 for ; Fri, 12 Feb 2010 18:35:44 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id EE7E98FC0C for ; Fri, 12 Feb 2010 18:35:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 2D0DB50843; Fri, 12 Feb 2010 18:35:43 +0000 (GMT) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjeltA1ix+0e; Fri, 12 Feb 2010 18:35:42 +0000 (GMT) Received: from nyi.unixathome.org (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 7E9E550842; Fri, 12 Feb 2010 18:35:41 +0000 (GMT) Received: from 68.64.144.211 (SquirrelMail authenticated user dan) by nyi.unixathome.org with HTTP; Fri, 12 Feb 2010 13:35:41 -0500 Message-ID: In-Reply-To: <4B7372D7.9060108@incunabulum.net> References: <4B6F9A8D.4050907@langille.org> <4B71490B.6030602@langille.org> <4B71AED5.4030002@wensing.org> <201002091949.o19JntPo009017@apollo.backplane.com> <4B723DF9.3070105@langille.org> <4B730B94.1050205@comcast.net> <4B7372D7.9060108@incunabulum.net> Date: Fri, 12 Feb 2010 13:35:41 -0500 From: "Dan Langille" To: "Bruce Simpson" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-stable@freebsd.org Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 18:35:44 -0000 On Wed, February 10, 2010 10:00 pm, Bruce Simpson wrote: > On 02/10/10 19:40, Steve Polyack wrote: >> >> I haven't had such bad experience as the above, but it is certainly a >> concern. Using ZFS we simply 'offline' the device, pull, replace with >> a new one, glabel, and zfs replace. It seems to work fine as long as >> nothing is accessing the device you are replacing (otherwise you will >> get a kernel panic a few minutes down the line). mav@FreeBSD.org has >> also committed a large patch set to 9-CURRENT which implements >> "proper" SATA/AHCI hot-plug support and error-recovery through CAM. > > I've been running with this patch in 8-STABLE for well over a week now > on my desktop w/o issues; I am using main disk for dev, and eSATA disk > pack for light multimedia use. MFC to 8.x? -- Dan Langille -- http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 18:40:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1600D106566B for ; Fri, 12 Feb 2010 18:40:45 +0000 (UTC) (envelope-from nate@thatsmathematics.com) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id A04028FC16 for ; Fri, 12 Feb 2010 18:40:44 +0000 (UTC) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o1CIK7Y26176; Fri, 12 Feb 2010 10:20:07 -0800 (PST) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o1CIK7U25395; Fri, 12 Feb 2010 10:20:07 -0800 (PST) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Fri, 12 Feb 2010 10:20:06 -0800 (PST) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Dmitry Marakasov In-Reply-To: <20100212180032.GC94665@hades.panopticon> Message-ID: References: <201002102046.o1AKkrvj085173@lurza.secnetix.de> <20100212180032.GC94665@hades.panopticon> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Oliver Fromme , freebsd-stable@freebsd.org Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 18:40:45 -0000 On Fri, 12 Feb 2010, Dmitry Marakasov wrote: > * Oliver Fromme (olli@lurza.secnetix.de) wrote: > >> This is an excerpt from Solaris' mount_nfs(1M) manpage: >> >> File systems that are mounted read-write or that con- >> tain executable files should always be mounted with >> the hard option. Applications using soft mounted file >> systems may incur unexpected I/O errors, file corrup- >> tion, and unexpected program core dumps. The soft >> option is not recommended. >> >> FreeBSD's manual page doesn't contain such a warning, but >> maybe it should. (It contains a warning not to use "soft" >> with NFSv4, though, for different reasons.) > > Interesting, I'll try disabling it. However now I really wonder why > is such dangerous option available (given it's the cause) at all, > especially without a notice. Silent data corruption is possibly the > worst thing to happen ever. Tell me about it. :) But in this case I'm not sure I understand. As I understand it, the difference between soft and hard is that in the case of soft, a timeout will result in the operation failing and returning EIO or the like (hence "unexpected I/O errors"). And if the operation is being done to fault in a mapped page, you'd have to notify the process asynchronously by sending a signal like SIGBUS which it may not be expecting (hence "unexpected core dumps"). But in what scenario would you see file corruption? Unless you have a buggy program that doesn't check return values from system calls or handles signals in a stupid way, I don't see how this can happen, and I'm not sure what the Sun man page is referring to. -- Nate Eldredge nate@thatsmathematics.com From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 18:47:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 449481065693; Fri, 12 Feb 2010 18:47:41 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f194.google.com (mail-iw0-f194.google.com [209.85.223.194]) by mx1.freebsd.org (Postfix) with ESMTP id EFE788FC13; Fri, 12 Feb 2010 18:47:40 +0000 (UTC) Received: by iwn32 with SMTP id 32so4022144iwn.14 for ; Fri, 12 Feb 2010 10:47:40 -0800 (PST) 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=i9qneCSkAuxoeT4+Nrm75Bw61Rquoiz+P0SQk0Vod5g=; b=GOHHrXanLA+zW3zpS45jYOxaL2cgX8IPzgdxVg1ES9Vm4qII1CTo0Lt62gbCDjIq6g W2HqF7Rwa7DQHprNHM1teQ4PsARANMiJDpcDEbPd0FJIDzk+vOe7ygHx0I7Op7/6f0OJ bPw57pWtBVkeh9dopXB+fz0pteV5wGAeSs9JI= 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=q7Z64EmtTJ8gWIRPd4WleukudNG1Tw906O63yjKQ8d8bdXWQIT2nhR5a/w8/fg16uF 0CxlXZ07J9eNq0wvd+7pO1gv9wPY1opynpsFECTPR0Phgo0lpVxaVNgpQA00QsiBa4ue Wrk1zknpowsuM8VdvRd39h35UqlXHPWASiDt8= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.147.149 with SMTP id l21mr314072ibv.0.1266000460156; Fri, 12 Feb 2010 10:47:40 -0800 (PST) In-Reply-To: <4B759E70.4030809@comcast.net> References: <4B759E70.4030809@comcast.net> Date: Fri, 12 Feb 2010 10:47:40 -0800 X-Google-Sender-Auth: 5b14e99a2562fe94 Message-ID: From: Artem Belevich To: Steve Polyack Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-stable Subject: Re: ZFS ARC being limited below what is defined in /boot/loader.conf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 18:47:41 -0000 Check your vm.kmem_size. Default setting is way too low. Set it to at least double of desired arc size. --Artem On Fri, Feb 12, 2010 at 10:31 AM, Steve Polyack wrote: > Has anyone had an issue with the ZFS ARC max being limited below what has > been defined in /boot/loader.conf? =A0I just upgraded the RAM in a > ZFS-equipped system and attempted to devote 4GB to the ARC cache by placi= ng > the following in loader.conf: > =A0vfs.zfs.arc_max=3D"4096M" > > However, after rebooting, querying the sysctl gives me this: > $ sysctl vfs.zfs.arc_max > vfs.zfs.arc_max: 1726489600 > > or about 1.7GB, an odd number that I can't find any references to. =A0For > reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system with = 8GB > of RAM. =A0The system was previously very stable with 4GB of RAM and a 51= 2MB > arc_max. =A0I have not modified vm.kmem_size_max (defaults to ~330GB on a= md64) > or any other ZFS tunables. =A0I'd also like to avoid syncing up to the cu= rrent > 8-STABLE if at all possible. > > Thanks, > Steve Polyack > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 18:57:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EE8E10656EF; Fri, 12 Feb 2010 18:57:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C47388FC15; Fri, 12 Feb 2010 18:57:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJEzdUuDaFvH/2dsb2JhbACbAXS/foRYBIMT X-IronPort-AV: E=Sophos;i="4.49,462,1262581200"; d="scan'208";a="65258207" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 12 Feb 2010 13:57:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 07E3010842BA; Fri, 12 Feb 2010 13:57:50 -0500 (EST) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 244JsO93KH5u; Fri, 12 Feb 2010 13:57:49 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id EBFD6108408E; Fri, 12 Feb 2010 13:57:48 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o1CJ9EA25479; Fri, 12 Feb 2010 14:09:14 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 12 Feb 2010 14:09:14 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: John Baldwin In-Reply-To: <201002111255.46256.jhb@freebsd.org> Message-ID: References: <20100210174338.GC39752@hades.panopticon> <201002111255.46256.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Dmitry Marakasov , freebsd-stable@freebsd.org Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 18:57:52 -0000 On Thu, 11 Feb 2010, John Baldwin wrote: >> >> Case1: single currupted block 3779CF88-3779FFFF (12408 bytes). >> Data in block is shifted 68 bytes up, loosing first 68 bytes are >> filling last 68 bytes with garbage. Interestingly, among that garbage >> is my hostname. > > Is it the hostname of the server or the client? > Oh, I realized the first 4 bytes of the garbage is the record mark that preceeds the RPC header for TCP, so the garbage is the first part of the RPC after the TCP/IP header. > > Can you reproduce this using a non-FreeBSD server with a FreeBSD client or a > non-FreeBSD client with a FreeBSD server? That would narrow down the breakage > to either the client or the server. > If using a non-FreeBSD client/server isn't convenient, another way would be to do a binary packet capture (something like "tcpdump -s 0 -w ") and then looking at it in wireshark for a failed case and see if the data is corrupted on the wire. rick From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 19:01:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AAE8106566B; Fri, 12 Feb 2010 19:01:05 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id D03088FC14; Fri, 12 Feb 2010 19:01:04 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALQ0dUuDaFvJ/2dsb2JhbACbAXS/bYRYBIMT X-IronPort-AV: E=Sophos;i="4.49,462,1262581200"; d="scan'208";a="65258549" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 12 Feb 2010 14:01:04 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id E1BC1FB80B8; Fri, 12 Feb 2010 14:01:03 -0500 (EST) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR4JERQJAoNp; Fri, 12 Feb 2010 14:01:03 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id F27C9FB8085; Fri, 12 Feb 2010 14:01:02 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o1CJCSI26062; Fri, 12 Feb 2010 14:12:28 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 12 Feb 2010 14:12:28 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Dmitry Marakasov In-Reply-To: <20100212175422.GB94665@hades.panopticon> Message-ID: References: <20100210174338.GC39752@hades.panopticon> <201002111255.46256.jhb@freebsd.org> <20100212175422.GB94665@hades.panopticon> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 19:01:05 -0000 On Fri, 12 Feb 2010, Dmitry Marakasov wrote: > > I'm planning a massive testing for this weekend, including removing > soft mount option and trying linux client/server. > > Btw, I forgot to mention that I'm experiencing other NFS problems from > time to time, including "death" of a mount (that is, all processes that > try to access it freeze; this cures itself in some time with a message > "server is alive again"). Also I've seen another strange thing - not > only the mount dies but the network is flooded with NFS traffic. > Last time I've seen it quite a while ago, so I don't remember the > circumstances and direction of the traffic. > There are some patches at: http://people.freebsd.org/~rmacklem that may be relevant if you are using vanilla FreeBSD-8.0. (They're all now in stable/8, but are post-release of 8.0.) rick From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 19:08:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC983106566C; Fri, 12 Feb 2010 19:08:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 86BEE8FC13; Fri, 12 Feb 2010 19:08:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGY2dUuDaFvI/2dsb2JhbACbAXS/b4JIghAEgxM X-IronPort-AV: E=Sophos;i="4.49,462,1262581200"; d="scan'208";a="65421611" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 12 Feb 2010 14:08:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id B4130940025; Fri, 12 Feb 2010 14:08:46 -0500 (EST) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wd+2klbPy29K; Fri, 12 Feb 2010 14:08:45 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id AA20694010A; Fri, 12 Feb 2010 14:08:45 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o1CJKA626707; Fri, 12 Feb 2010 14:20:11 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 12 Feb 2010 14:20:10 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Dmitry Marakasov In-Reply-To: <20100212180032.GC94665@hades.panopticon> Message-ID: References: <201002102046.o1AKkrvj085173@lurza.secnetix.de> <20100212180032.GC94665@hades.panopticon> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, Oliver Fromme Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 19:08:48 -0000 On Fri, 12 Feb 2010, Dmitry Marakasov wrote: > > Interesting, I'll try disabling it. However now I really wonder why > is such dangerous option available (given it's the cause) at all, > especially without a notice. Silent data corruption is possibly the > worst thing to happen ever. > I doubt that the data corruption you are seeing would be because of "soft". "soft" will cause various problems w.r.t. consistency, but in the case of a write through the buffer cache, I think it will leave the buffer dirty and eventually it will get another write attempt. > However, without soft option NFS would be a strange thing to use - > network problems is kinda inevitable thing, and having all processes > locked in a unkillable state (with hard mounts) when it dies is not > fun. Or am I wrong? > Well, using NFS over an unreliable network is going to cause grief sooner or later. The problem is that POSIX apps. don't expect I/O system calls to fail with EIO and generally don't handle that gracefully. For the future, I think "umount -F" (a forced dismount that accepts data loss) is the best compromise, since at least then a sysadmin knows that data corruption could have occurred when they do it and can choose to "wait" until the network is fixed as an alternative to the corruption? rick From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 19:09:01 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C41C1065774; Fri, 12 Feb 2010 19:09:01 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [92.53.116.15]) by mx1.freebsd.org (Postfix) with ESMTP id C801A8FC13; Fri, 12 Feb 2010 19:09:00 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Ng0sf-0002j0-Kl; Fri, 12 Feb 2010 22:08:45 +0300 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id A8898B860; Fri, 12 Feb 2010 22:08:48 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id A413CB829; Fri, 12 Feb 2010 22:08:48 +0300 (MSK) Date: Fri, 12 Feb 2010 22:08:48 +0300 From: Dmitry Marakasov To: Oliver Fromme Message-ID: <20100212190848.GF94665@hades.panopticon> References: <20100212180032.GC94665@hades.panopticon> <201002121820.o1CIKohU019226@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201002121820.o1CIKohU019226@lurza.secnetix.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 19:09:01 -0000 * Oliver Fromme (olli@lurza.secnetix.de) wrote: > I'm sorry for the confusion ... I do not think that it's > the cause for your data corruption, in this particular > case. I just mentioned the potential problems with "soft" > mounts because it could cause additional problems for you. > (And it's important to know anyhow.) Oh, then I really misunderstood. If the curruption implied is like when you copy a file via NFS and the net goes down, and in case of soft mount you have half of a file (read: corruption), while with hard mount the copy process will finish when the net is back up, that's definitely OK and expected. > Well, this is what happens if the network hangs: > > 1. With "hard" mounts (the default), processes that access > NFS shares are locked for as long as the network is down. > > 2. With "soft" mounts, binaries can coredump, and many > programs won't notice that write access just failed which > leads to file corruption. > > Personally I definitely prefer the first. Yeah, but I have mostly desktop<->(NAS w/torrents) setup so I prefer the second. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 19:16:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CF691065693 for ; Fri, 12 Feb 2010 19:16:41 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail3.es.net [IPv6:2001:400:4c01::2]) by mx1.freebsd.org (Postfix) with ESMTP id 610F88FC1A for ; Fri, 12 Feb 2010 19:16:41 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o1CJGb1F025590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Feb 2010 11:16:38 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 653011CC09; Fri, 12 Feb 2010 11:16:37 -0800 (PST) To: Jeremy Chadwick In-reply-to: Your message of "Fri, 12 Feb 2010 05:11:17 PST." <20100212131117.GA51905@icarus.home.lan> Date: Fri, 12 Feb 2010 11:16:37 -0800 From: "Kevin Oberman" Message-Id: <20100212191637.653011CC09@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-02-12_03:2010-02-06, 2010-02-12, 2010-02-12 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002120138 Cc: freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 19:16:41 -0000 > Date: Fri, 12 Feb 2010 05:11:17 -0800 > From: Jeremy Chadwick > Sender: owner-freebsd-stable@freebsd.org > > On Fri, Feb 12, 2010 at 01:29:47PM +0100, Torfinn Ingolfsen wrote: > > On Thu, 11 Feb 2010 11:25:15 -0800 > > Jeremy Chadwick wrote: > > > > > > > > Your machine has a rapidly drifting clock, usually an indicator of a > > > hardware problem (crystal gone bad is a common one -- seen this at work > > > quite a few times), or possibly a bad time counter source chosen by the > > > kernel. Can you please provide the output of: > > > > > > sysctl kern.timecounter > > > > Here it is: > > root@kg-f2# sysctl kern.timecounter > > kern.timecounter.tick: 1 > > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) > > kern.timecounter.hardware: HPET > > kern.timecounter.stepwarnings: 0 > > kern.timecounter.tc.i8254.mask: 65535 > > kern.timecounter.tc.i8254.counter: 52444 > > kern.timecounter.tc.i8254.frequency: 1193182 > > kern.timecounter.tc.i8254.quality: 0 > > kern.timecounter.tc.ACPI-safe.mask: 4294967295 > > kern.timecounter.tc.ACPI-safe.counter: 3252982815 > > kern.timecounter.tc.ACPI-safe.frequency: 3579545 > > kern.timecounter.tc.ACPI-safe.quality: 850 > > kern.timecounter.tc.HPET.mask: 4294967295 > > kern.timecounter.tc.HPET.counter: 3443625641 > > kern.timecounter.tc.HPET.frequency: 14318180 > > kern.timecounter.tc.HPET.quality: 900 > > kern.timecounter.tc.TSC.mask: 4294967295 > > kern.timecounter.tc.TSC.counter: 1276479615 > > kern.timecounter.tc.TSC.frequency: 2819782573 > > kern.timecounter.tc.TSC.quality: -100 > > kern.timecounter.smp_tsc: 0 > > kern.timecounter.invariant_tsc: 1 > > Please try doing this: > > - stop ntpd > - rm /var/db/ntpd.drift > - sysctl kern.timecounter.hardware=ACPI-safe > - start ntpd > > Then see if your clock drifts. If it stops, great -- you can put that > sysctl assignment line in /etc/sysctl.conf and consider it a done deal. > I highly recommend putting some comments around it though so in the > future you don't go "What's this? Silly!" and delete it. ;-) > > I'll also point out that it's common on FreeBSD[1] to see messages > like the following (or at least it was circa 2006 -- I believe ntpd > has been updated since then, but I've no indication said quirk was > fixed/addressed): > > Dec 19 00:22:26 icarus ntpd[624]: kernel time sync enabled 2001 > Dec 19 01:47:48 icarus ntpd[624]: kernel time sync enabled 6001 > Dec 19 02:04:52 icarus ntpd[624]: kernel time sync enabled 2001 > > > You can add the following to your ntp.conf to fix that problem: > > > # maxpoll 9 is used to work around PLL/FLL flipping, which happens at > # exactly 1024 seconds (the default maxpoll value). Another FreeBSD > # user recommended using 9 instead: > # http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031512.html > # > server some.ntp.server maxpoll 9 > > > I recommend using the "iburst" directive on one (and only one!) server > lines in your config, otherwise ntpd will usually 'settle' for about > 10-15 minutes before bothering to try and update the clock the first > time around. Example config: Why "(and only one!)"? I have never seen a problem with 'iburst' on all servers (assuming they are Internet connected". 'iburst' only makes a difference on the initial query and, if the server you have marked as 'iburst' is unreachable, it will really slow down synchronization. I am unaware of any issues with multiple servers being marked 'iburst' and typically configure 7 ntp servers for a system, all tagged as 'iburst'. Never sen any issue with this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 19:27:20 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24B3C106568F; Fri, 12 Feb 2010 19:27:20 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id A0A518FC21; Fri, 12 Feb 2010 19:27:19 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o1CJQpSI022749; Fri, 12 Feb 2010 20:27:07 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o1CJQpZr022747; Fri, 12 Feb 2010 20:26:51 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <201002121926.o1CJQpZr022747@lurza.secnetix.de> To: amdmi3@amdmi3.ru (Dmitry Marakasov) Date: Fri, 12 Feb 2010 20:26:51 +0100 (CET) In-Reply-To: <20100212190848.GF94665@hades.panopticon> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 12 Feb 2010 20:27:17 +0100 (CET) Cc: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 19:27:20 -0000 Dmitry Marakasov wrote: > Oh, then I really misunderstood. If the curruption implied is > like when you copy a file via NFS and the net goes down, and in > case of soft mount you have half of a file (read: corruption), while > with hard mount the copy process will finish when the net is back up, > that's definitely OK and expected. Of course it depends what kinds of programs you run. If you run a database, it can become corrupted to the point that you can't start it anymore, so you have to restore it from the latest backup. Been there, done that. Another example, this happened to a friend of mine: After a network outage his Opera browser didn't work anymore. He had to remove his ~/.opera directory to get it working again (and he lost all his settings). His home directory was "soft"-mounted, but he removed the soft option after that incident. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The last good thing written in C was Franz Schubert's Symphony number 9." -- Erwin Dieterich From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 19:34:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A185106566B; Fri, 12 Feb 2010 19:34:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id CC8B38FC15; Fri, 12 Feb 2010 19:34:49 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG88dUuDaFvI/2dsb2JhbACbAXS/TYRYBIMT X-IronPort-AV: E=Sophos;i="4.49,462,1262581200"; d="scan'208";a="65424566" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 12 Feb 2010 14:34:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 07285940025; Fri, 12 Feb 2010 14:34:49 -0500 (EST) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJLWgfnY1+Aj; Fri, 12 Feb 2010 14:34:46 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id C9F7B9400FD; Fri, 12 Feb 2010 14:34:45 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o1CJkBm29568; Fri, 12 Feb 2010 14:46:11 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 12 Feb 2010 14:46:11 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Dmitry Marakasov In-Reply-To: <20100212190848.GF94665@hades.panopticon> Message-ID: References: <20100212180032.GC94665@hades.panopticon> <201002121820.o1CIKohU019226@lurza.secnetix.de> <20100212190848.GF94665@hades.panopticon> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, Oliver Fromme Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 19:34:50 -0000 On Fri, 12 Feb 2010, Dmitry Marakasov wrote: > * Oliver Fromme (olli@lurza.secnetix.de) wrote: > >> I'm sorry for the confusion ... I do not think that it's >> the cause for your data corruption, in this particular >> case. I just mentioned the potential problems with "soft" >> mounts because it could cause additional problems for you. >> (And it's important to know anyhow.) > > Oh, then I really misunderstood. If the curruption implied is > like when you copy a file via NFS and the net goes down, and in > case of soft mount you have half of a file (read: corruption), while > with hard mount the copy process will finish when the net is back up, > that's definitely OK and expected. > The problem is that it can't distinguish between "slow network/server" and partitioned/failed network. In your case (one client) it may work out ok. (I can't remember how long it takes to timeout and give up for "soft".) For many clients talking to an NFS server, the NFS server's response time can degrade to the point where "soft" mounted clients start timing out and that can get ugly. rick From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 19:36:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77C7A106566C for ; Fri, 12 Feb 2010 19:36:42 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 42CE38FC15 for ; Fri, 12 Feb 2010 19:36:41 +0000 (UTC) Received: from reflector.ws.pitbpa0.priv.collaborativefusion.com ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Fri, 12 Feb 2010 14:58:58 -0500 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::322 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@freebsd.org X-SMFBL: ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc= Message-ID: <4B75ADC7.6000308@comcast.net> Date: Fri, 12 Feb 2010 14:36:39 -0500 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100211 Thunderbird/3.0.1 MIME-Version: 1.0 To: Artem Belevich References: <4B759E70.4030809@comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable Subject: Re: ZFS ARC being limited below what is defined in /boot/loader.conf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 19:36:42 -0000 On 02/12/10 13:47, Artem Belevich wrote: > On Fri, Feb 12, 2010 at 10:31 AM, Steve Polyack wrote: > > >> Has anyone had an issue with the ZFS ARC max being limited below what has >> been defined in /boot/loader.conf? I just upgraded the RAM in a >> ZFS-equipped system and attempted to devote 4GB to the ARC cache by placing >> the following in loader.conf: >> vfs.zfs.arc_max="4096M" >> >> However, after rebooting, querying the sysctl gives me this: >> $ sysctl vfs.zfs.arc_max >> vfs.zfs.arc_max: 1726489600 >> >> or about 1.7GB, an odd number that I can't find any references to. For >> reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system with 8GB >> of RAM. The system was previously very stable with 4GB of RAM and a 512MB >> arc_max. I have not modified vm.kmem_size_max (defaults to ~330GB on amd64) >> or any other ZFS tunables. I'd also like to avoid syncing up to the current >> 8-STABLE if at all possible. >> >> Thanks, >> Steve Polyack >> >> _______________________________________________ >> 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" >> >> > > Check your vm.kmem_size. Default setting is way too low. Set it to at > least double of desired arc size. > > --Artem I mentioned it briefly, but vm.kmem_size_max was left at the default for amd64. At 330GB it is way above and beyond what will ever be allocated to ARC: $ sysctl vm.kmem_size_max vm.kmem_size_max: 329853485875 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 19:38:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AC55106566B for ; Fri, 12 Feb 2010 19:38:57 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 127898FC12 for ; Fri, 12 Feb 2010 19:38:56 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta08.emeryville.ca.mail.comcast.net with comcast id h7Bg1d0091afHeLA87exLa; Fri, 12 Feb 2010 19:38:57 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.emeryville.ca.mail.comcast.net with comcast id h7ew1d00D3S48mS8d7ew02; Fri, 12 Feb 2010 19:38:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 9A4FE1E301A; Fri, 12 Feb 2010 11:38:55 -0800 (PST) Date: Fri, 12 Feb 2010 11:38:55 -0800 From: Jeremy Chadwick To: Kevin Oberman Message-ID: <20100212193855.GA73542@icarus.home.lan> References: <20100212131117.GA51905@icarus.home.lan> <20100212191637.653011CC09@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100212191637.653011CC09@ptavv.es.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 19:38:57 -0000 On Fri, Feb 12, 2010 at 11:16:37AM -0800, Kevin Oberman wrote: > > Date: Fri, 12 Feb 2010 05:11:17 -0800 > > From: Jeremy Chadwick > > Sender: owner-freebsd-stable@freebsd.org > > > > On Fri, Feb 12, 2010 at 01:29:47PM +0100, Torfinn Ingolfsen wrote: > > > On Thu, 11 Feb 2010 11:25:15 -0800 > > > Jeremy Chadwick wrote: > > > > > > > > > > > Your machine has a rapidly drifting clock, usually an indicator of a > > > > hardware problem (crystal gone bad is a common one -- seen this at work > > > > quite a few times), or possibly a bad time counter source chosen by the > > > > kernel. Can you please provide the output of: > > > > > > > > sysctl kern.timecounter > > > > > > Here it is: > > > root@kg-f2# sysctl kern.timecounter > > > kern.timecounter.tick: 1 > > > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) > > > kern.timecounter.hardware: HPET > > > kern.timecounter.stepwarnings: 0 > > > kern.timecounter.tc.i8254.mask: 65535 > > > kern.timecounter.tc.i8254.counter: 52444 > > > kern.timecounter.tc.i8254.frequency: 1193182 > > > kern.timecounter.tc.i8254.quality: 0 > > > kern.timecounter.tc.ACPI-safe.mask: 4294967295 > > > kern.timecounter.tc.ACPI-safe.counter: 3252982815 > > > kern.timecounter.tc.ACPI-safe.frequency: 3579545 > > > kern.timecounter.tc.ACPI-safe.quality: 850 > > > kern.timecounter.tc.HPET.mask: 4294967295 > > > kern.timecounter.tc.HPET.counter: 3443625641 > > > kern.timecounter.tc.HPET.frequency: 14318180 > > > kern.timecounter.tc.HPET.quality: 900 > > > kern.timecounter.tc.TSC.mask: 4294967295 > > > kern.timecounter.tc.TSC.counter: 1276479615 > > > kern.timecounter.tc.TSC.frequency: 2819782573 > > > kern.timecounter.tc.TSC.quality: -100 > > > kern.timecounter.smp_tsc: 0 > > > kern.timecounter.invariant_tsc: 1 > > > > Please try doing this: > > > > - stop ntpd > > - rm /var/db/ntpd.drift > > - sysctl kern.timecounter.hardware=ACPI-safe > > - start ntpd > > > > Then see if your clock drifts. If it stops, great -- you can put that > > sysctl assignment line in /etc/sysctl.conf and consider it a done deal. > > I highly recommend putting some comments around it though so in the > > future you don't go "What's this? Silly!" and delete it. ;-) > > > > I'll also point out that it's common on FreeBSD[1] to see messages > > like the following (or at least it was circa 2006 -- I believe ntpd > > has been updated since then, but I've no indication said quirk was > > fixed/addressed): > > > > Dec 19 00:22:26 icarus ntpd[624]: kernel time sync enabled 2001 > > Dec 19 01:47:48 icarus ntpd[624]: kernel time sync enabled 6001 > > Dec 19 02:04:52 icarus ntpd[624]: kernel time sync enabled 2001 > > > > > > You can add the following to your ntp.conf to fix that problem: > > > > > > # maxpoll 9 is used to work around PLL/FLL flipping, which happens at > > # exactly 1024 seconds (the default maxpoll value). Another FreeBSD > > # user recommended using 9 instead: > > # http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031512.html > > # > > server some.ntp.server maxpoll 9 > > > > > > I recommend using the "iburst" directive on one (and only one!) server > > lines in your config, otherwise ntpd will usually 'settle' for about > > 10-15 minutes before bothering to try and update the clock the first > > time around. Example config: > > Why "(and only one!)"? I have never seen a problem with 'iburst' on all > servers (assuming they are Internet connected". 'iburst' only makes a > difference on the initial query and, if the server you have marked as > 'iburst' is unreachable, it will really slow down synchronization. > > I am unaware of any issues with multiple servers being marked 'iburst' > and typically configure 7 ntp servers for a system, all tagged as > 'iburst'. Never sen any issue with this. iburst sends 8 packets (vs. the default of 1) with an interval delay of 2 seconds (assuming calldelay isn't set). There's some sort of "rule" in the NTP community where more than 20 requests per hour is considered rude or worthy of blocking. This was discussed on the timekeepers list a while back. The original thread (AFAIR) was originally about rules/regulations for vendors (such as router manufacturers who pick defaults, etc.), but I'm willing to bet the concepts apply universally: http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002299.html Relevant discussion pieces below, (*) marked as worth reading, and (!!!) are highly relevant: http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002321.html http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002323.html http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002325.html http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002326.html http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002327.html (*) http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002329.html (*) http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002330.html (*) http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002331.html (!!!) http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002332.html (!!!) http://fortytwo.ch/mailman/pipermail/timekeepers/2006/002335.html (!!!) Using iburst on a LAN (e.g. box1 syncs from box2, and box2 syncs from stratum 1/2/3 servers; box1 uses iburst, while box2 does not) is highly recommended. Also worth noting is that those who provide public NTP servers apparently keep usage stats per client/IP on how many queries they send over a period of time, and *will* blacklist you. How to deal with abusers is an interesting topic to read there. When it comes to NTP: tread lightly. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 19:46:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E725106568B for ; Fri, 12 Feb 2010 19:46:06 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 240318FC1D for ; Fri, 12 Feb 2010 19:46:05 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta01.emeryville.ca.mail.comcast.net with comcast id h2t61d00C0EPchoA17m6XF; Fri, 12 Feb 2010 19:46:06 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta01.emeryville.ca.mail.comcast.net with comcast id h7m51d0093S48mS8M7m6jG; Fri, 12 Feb 2010 19:46:06 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C00D81E301A; Fri, 12 Feb 2010 11:46:04 -0800 (PST) Date: Fri, 12 Feb 2010 11:46:04 -0800 From: Jeremy Chadwick To: Torfinn Ingolfsen Message-ID: <20100212194604.GA73961@icarus.home.lan> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 19:46:06 -0000 On Fri, Feb 12, 2010 at 05:44:52PM +0100, Torfinn Ingolfsen wrote: > On Fri, 12 Feb 2010 05:11:17 -0800 > Jeremy Chadwick wrote: > > > Please try doing this: > > > > - stop ntpd > > - rm /var/db/ntpd.drift > > - sysctl kern.timecounter.hardware=ACPI-safe > > - start ntpd > > Thanks, I'm currently testing that. Results in 72 hours (or less) :-) Something else came to mind: some BIOSes let you disable/enable HPET. Often labelled as "High Performance Event Timer" or "Multimedia Timer", you could disable this option then check kern.timecounter.choice to see if HPET is gone from the list. If it is, FreeBSD will very likely choose ACPI-safe as the default timecounter (again, check kern.timecounter.hardware to see what the kernel chose itself. Remember that your sysctl.conf entry will override this though! :-) ), which -- assuming it works -- should solve your problem. Technical footnote: I wish I understood 1) the difference between ACPI-safe and ACPI-fast, and 2) how the system or OS "ranks" the timecounters (the higher the value in parenthesis, supposedly the more accurate/preferred it is). Xin, do you happen to know how this works? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 19:58:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FBC1106570A for ; Fri, 12 Feb 2010 19:58:21 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6308B8FC0C for ; Fri, 12 Feb 2010 19:58:21 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-123.hsd1.ms.comcast.net [75.65.60.123]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 0C36437B628; Fri, 12 Feb 2010 13:58:20 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 5674161C41; Fri, 12 Feb 2010 13:58:19 -0600 (CST) Date: Fri, 12 Feb 2010 13:58:19 -0600 From: "Matthew D. Fuller" To: Jeremy Chadwick Message-ID: <20100212195819.GI64395@over-yonder.net> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100212194604.GA73961@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100212194604.GA73961@icarus.home.lan> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.20-fullermd.4 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 19:58:21 -0000 On Fri, Feb 12, 2010 at 11:46:04AM -0800 I heard the voice of Jeremy Chadwick, and lo! it spake thus: > > Technical footnote: I wish I understood 1) the difference between > ACPI-safe and ACPI-fast, AIUI, they're nearly the same thing, and it has to do with some testing to determine how it can be reliably accessed. I've had systems that would sometimes come up with -fast, and other times -safe (I think one varied depending on cold vs. warm boot for instance). > and 2) how the system or OS "ranks" the timecounters (the higher the > value in parenthesis, supposedly the more accurate/preferred it is). That's easier; TTBOMK, they're hardcoded in the source based on developer SWAG about their relative expenses and reliabilities and precisions. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 21:10:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 568361065696; Fri, 12 Feb 2010 21:10:54 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f194.google.com (mail-iw0-f194.google.com [209.85.223.194]) by mx1.freebsd.org (Postfix) with ESMTP id 0181C8FC22; Fri, 12 Feb 2010 21:10:53 +0000 (UTC) Received: by iwn32 with SMTP id 32so4194479iwn.14 for ; Fri, 12 Feb 2010 13:10:53 -0800 (PST) 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=FYgMknWhea0eXc2bUza6On4QhmBItJpIcQAK/3J1Y8c=; b=h2HUFalGqkIqzyosiD0qeN6/NCCUEOic11SF9pytboviOUzTUS0OOg9ERupLuASSnx DJWbatkwQYO6WA1l/aJ70vRi8rL562CJSoTi75q0b2lFfU7NpZwdVsd64esEy4eEmm4i /1F7MfUJoS+YVmYt5mFMdC3kygf4nLxfeTifI= 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=D8TxuAEnDV5QD/DaEHYtFfgacLZfhNuj7I1uI11giVyhC+qefghsq+hwQh9Tdol8B5 TnhSYviKCJQymzXI7m6it3ETJCt20GjNWs37aSpCtNxEELH12v53aiRP6hfmazRYqzrX uQyY/wZzsqAVqBt8JL+qTc/F3go6lsUVnNlIE= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.154.77 with SMTP id n13mr1285922ibw.11.1266009051736; Fri, 12 Feb 2010 13:10:51 -0800 (PST) In-Reply-To: <4B75ADC7.6000308@comcast.net> References: <4B759E70.4030809@comcast.net> <4B75ADC7.6000308@comcast.net> Date: Fri, 12 Feb 2010 13:10:51 -0800 X-Google-Sender-Auth: fb3ee935a576a21d Message-ID: From: Artem Belevich To: Steve Polyack Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-stable Subject: Re: ZFS ARC being limited below what is defined in /boot/loader.conf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 21:10:54 -0000 vm.kmem_size_max/vm.kmem_size_min define the range vm.kmem_size can be set = to. vm_kmem_size specifies the actual kmem size. ARC size in turn limited by vm.kmem_size. If you want to bump ARC size, you do need to bump vm.kmem_size. --Artem On Fri, Feb 12, 2010 at 11:36 AM, Steve Polyack wrote: > On 02/12/10 13:47, Artem Belevich wrote: >> >> On Fri, Feb 12, 2010 at 10:31 AM, Steve Polyack >> =A0wrote: >> >> >>> >>> Has anyone had an issue with the ZFS ARC max being limited below what h= as >>> been defined in /boot/loader.conf? =A0I just upgraded the RAM in a >>> ZFS-equipped system and attempted to devote 4GB to the ARC cache by >>> placing >>> the following in loader.conf: >>> =A0vfs.zfs.arc_max=3D"4096M" >>> >>> However, after rebooting, querying the sysctl gives me this: >>> $ sysctl vfs.zfs.arc_max >>> vfs.zfs.arc_max: 1726489600 >>> >>> or about 1.7GB, an odd number that I can't find any references to. =A0F= or >>> reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system wit= h >>> 8GB >>> of RAM. =A0The system was previously very stable with 4GB of RAM and a >>> 512MB >>> arc_max. =A0I have not modified vm.kmem_size_max (defaults to ~330GB on >>> amd64) >>> or any other ZFS tunables. =A0I'd also like to avoid syncing up to the >>> current >>> 8-STABLE if at all possible. >>> >>> Thanks, >>> Steve Polyack >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" >>> >>> >> >> Check your vm.kmem_size. Default setting is way too low. Set it to at >> least double of desired arc size. >> >> --Artem > > I mentioned it briefly, but vm.kmem_size_max was left at the default for > amd64. =A0At 330GB it is way above and beyond what will ever be allocated= to > ARC: > $ sysctl vm.kmem_size_max > vm.kmem_size_max: 329853485875 > > > From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 21:18:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13D9C106566C for ; Fri, 12 Feb 2010 21:18:49 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4838FC18 for ; Fri, 12 Feb 2010 21:18:48 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1CLIkUs020615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Feb 2010 08:18:46 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o1CLIjY7028323; Sat, 13 Feb 2010 08:18:45 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o1CLIjkG028322; Sat, 13 Feb 2010 08:18:45 +1100 (EST) (envelope-from peter) Date: Sat, 13 Feb 2010 08:18:45 +1100 From: Peter Jeremy To: Sean McCullough Message-ID: <20100212211845.GB93045@server.vk2pj.dyndns.org> References: <4B747009.9000706@frii.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GRPZ8SYKNexpdSJ7" Content-Disposition: inline In-Reply-To: <4B747009.9000706@frii.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Hello and a small problem with 8.0-RELEASE (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 21:18:49 -0000 --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-11 14:00:57 -0700, Sean McCullough wrote: > This machine runs FreeBSD 7.2 (amd64 version) without the > slightest problem; but when I attempt to load 8.0 onto the machine, I > can't even get sysinstall to put the kernel on to boot it. How are you doing this? Normally you would only use sysinstall to install a fresh system from CD/DVD. Note that (at least last time I looked) actually copying the kernel to disk is one of the last steps it does and isn't explicitly selected from the menus. > Attempting to > compile and install the 8.0 kernel from source code results in a kernel > which locks up at boot time after emitting a message stating "attempting > to mount volumes"; Is this the exact message or is it "Trying to mount root"...? Can you provide the exact boot messages? Either setup a serial console or use ScrollLock, scroll back, photograph each screen of boot messages, post them somewhere and mail a URL. > a reboot of this system results in a bootloader > prompt and an error message stating that no bootable kernel can be found. Can you provide details of your hardware setup? Motherboard, what the boot disk is (PATA/SATA) and what the physical disk address is (which controller/channel). --=20 Peter Jeremy --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkt1xbUACgkQ/opHv/APuIfRuwCfZ6HDG15yMYJ9E3UQ8IuDBDyF Qz4Anjq9qVFyz8UD00Nt0OHm9mzgSvqG =W/nF -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 21:52:38 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D922106566B for ; Fri, 12 Feb 2010 21:52:38 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9AFA08FC08 for ; Fri, 12 Feb 2010 21:52:37 +0000 (UTC) Received: (from brett@localhost) by lariat.net (8.9.3/8.9.3) id OAA17025 for stable@freebsd.org; Fri, 12 Feb 2010 14:52:35 -0700 (MST) Date: Fri, 12 Feb 2010 14:52:35 -0700 (MST) From: Brett Glass Message-Id: <201002122152.OAA17025@lariat.net> To: stable@freebsd.org Cc: Subject: MFC request for 7.3-RELEASE: ASIX AX88172A USB Ethernet X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 21:52:38 -0000 Please MFC support for ASIX AX88172A USB Ethernet to 7.3-RELEASE; see http://www.freebsd.org/cgi/query-pr.cgi?pr=140923 for information. Note that the AX88172 driver works with the newer AX88172A chip, which has replaced it; the system simply needs to be told that it does. --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 22:23:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 870151065672 for ; Fri, 12 Feb 2010 22:23:21 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from deliver.hol.gr (deliver.hol.gr [62.38.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id F03A78FC0A for ; Fri, 12 Feb 2010 22:23:20 +0000 (UTC) Received: from auth-smtp.hol.gr (takeit01.mail.dc.hol.net [192.168.20.71]) by deliver.hol.gr (8.12.11/8.11.6) with ESMTP id o1CMN6si004548 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified OK); Sat, 13 Feb 2010 00:23:07 +0200 Received: from [192.168.2.2] ([62.38.18.148]) by auth-smtp.hol.gr (8.13.1/8.13.1) with ESMTP id o1CMN4U2013136; Sat, 13 Feb 2010 00:23:05 +0200 Message-ID: <4B75D4C4.10400@eng.auth.gr> Date: Sat, 13 Feb 2010 00:23:00 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: jhell References: <4B74502C.3080906@eng.auth.gr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.94.2/10387/Fri Feb 12 07:28:58 2010 on takeit01.mail.dc.hol.net X-Virus-Status: Clean Cc: freebsd-stable Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 22:23:21 -0000 On 12/2/2010 8:48 πμ, jhell wrote: > > > This is a lot of information to consume. > > Lets start with this: > > All of the machines in question are of some form of FreeBSD 8. > > You enter gdb and very clearly it starts whining about a segfault & > libc.so.7 > > Did you happen to upgrade these clients & server from FreeBSD 7 ? > > AFAIK the libc version on FreeBSD 8 was bumped to libc.so.8 > > If you upgraded and from source did you run make delete-old and make > delete-old-libs after your make install and after your mergemaster ? > > Will wait here for results. > > Best wishes. > jhel, None of my machines is upgraded from fbsd7. As I stated in my previous email, two of them are built from January's snapshot (no updates/upgrades); My gdb example is running on one of these machines. Nevertheless, on all machines that segfault, the outcome of gdb is the same. The rest machines are built either from fbsd8-release and upgraded to the latest stable sources, except from my laptop which was installed from fbsd8-beta1 and has been upgraded frequently since then. Its current binaries are built from January's 25 sources. Either way, since you asked, I always use make delete-old and make delete-old-libs when upgrading. Lastly, to make a long story short, what I want everybody to keep from my latest email is that 32bit and 64bit behave differently. 32bit segfaults, but not always..and it definately behaves differently when built on vmware esxi4 then when built on virtual box. Then again, amd64, on the same esxi host works correctly in only one of the two machines. Lastly, I want someone who knows more about the sources in question than I do, to see what gdb shows, and that after the little hack we made, instead of a segfault we got the same strange behavior as that of the "brokent" amd64 box. Cheers once more. mamalos From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 23:40:31 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC9541065693 for ; Fri, 12 Feb 2010 23:40:31 +0000 (UTC) (envelope-from fbsd.adriaan@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 7B2B18FC1D for ; Fri, 12 Feb 2010 23:40:30 +0000 (UTC) Received: by gxk10 with SMTP id 10so2766769gxk.3 for ; Fri, 12 Feb 2010 15:40:30 -0800 (PST) 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=bXbM1YbT+HdFmk9c3A4HpmbeAh5qgcjxtfzlN4jHVRg=; b=or7V68bBdet8p7S9jJUS5bGbk73jKmnd7OIVQ1iO1PlW8Wid0cIb5EZ2yhcCIzQW5w sqJOcTQ8aquqWBvT1jeVFqe9XwENSOxJgZrR4mYnjO4p7Nieh2RVbZfGCcQKd3mAIimq KfY0gMPsccGHQ7gkC/qliF/wlO+LTCyru3O4E= 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=Qfd0ZDzcBpnYanZMF6tXJXL6lyt5AwccEprGAd03IG4SWtshI9peWzmwn8p8J2ItON 0qFQfnbb4WOhHLs8g9lWNnZMzcAYC9KfrMPvIvtEcavpvL/cTadjKbAJ09TDSfqwvz48 zfzgY11PJ3lV8VeCIh4QERDSgL98sOiECUNlc= MIME-Version: 1.0 Received: by 10.101.138.10 with SMTP id q10mr3108559ann.37.1266016235098; Fri, 12 Feb 2010 15:10:35 -0800 (PST) In-Reply-To: References: Date: Sat, 13 Feb 2010 00:10:35 +0100 Message-ID: <74c3ddc41002121510w3d16168yca644f739bead74b@mail.gmail.com> From: Adriaan To: Charles Sprickman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: ZFS on root, serial console install X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 23:40:32 -0000 On Fri, Feb 12, 2010 at 7:27 AM, Charles Sprickman wrote: > Any hints on that one? > > I finally got around to getting dhcp/tftp/nfs setup on an internal networ= k > to perform normal installs (and with some pxelinux hackery, the ability t= o > boot a DOS disk or memtest86 disk images). > > Sysinstall in general is kind of an unweildy beast over serial, but one > thing I was not able to accomplish was to get a shell (no extra virtual > consoles on serial) or attempt any mounting of fixit media. =A0From my la= st > install that put ZFS on root, I had to do quite a bit of tapdancing since= I > had no DVD or bootable USB media - lots of switching from the install dis= k > to fixit, which brought me to many chicken and egg moments. =A0I did it > though... > > But remotely, I'm not seeing a good way to do this. =A0If mfsroot were la= rger > and had more tools, then I'd be in business. =A0This is probably the dire= ction > I need to get shoved in. > > I've looked at some other options with pxelinux and perhaps booting the m= ini > ISO, but I'm not sure that gets me anywhere. > > Any tips? =A0This isn't a make or break situation, I live 15 minutes from= the > colo... =A0It's more of a quest. :) > I would installl a small UFS FBSD system of 1 or 2 Gig on say ad0s1. That gives you more then the equivalent of a fixit CD. You then use this mini system as base to install the "real one" on the other slice(s) After having finished the install, you use fdisk to change the active slice to the new install and reboot. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 12 23:47:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2515D106568D for ; Fri, 12 Feb 2010 23:47:13 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id C4BF88FC13 for ; Fri, 12 Feb 2010 23:47:12 +0000 (UTC) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id h0Wx1d0020xGWP853BmgP9; Fri, 12 Feb 2010 23:46:40 +0000 Received: from [10.0.0.51] ([71.199.122.142]) by omta12.westchester.pa.mail.comcast.net with comcast id hBnC1d00534Sj4f3YBnCh7; Fri, 12 Feb 2010 23:47:13 +0000 Message-ID: <4B75E88A.1050300@comcast.net> Date: Fri, 12 Feb 2010 18:47:22 -0500 From: Steve Polyack User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Artem Belevich References: <4B759E70.4030809@comcast.net> <4B75ADC7.6000308@comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable Subject: Re: ZFS ARC being limited below what is defined in /boot/loader.conf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 23:47:13 -0000 This was indeed the issue. I read your first response incorrectly. Thanks a bunch! On 2/12/2010 4:10 PM, Artem Belevich wrote: > vm.kmem_size_max/vm.kmem_size_min define the range vm.kmem_size can be set to. > vm_kmem_size specifies the actual kmem size. > > ARC size in turn limited by vm.kmem_size. > > If you want to bump ARC size, you do need to bump vm.kmem_size. > > --Artem > > > > On Fri, Feb 12, 2010 at 11:36 AM, Steve Polyack wrote: > >> On 02/12/10 13:47, Artem Belevich wrote: >> >>> On Fri, Feb 12, 2010 at 10:31 AM, Steve Polyack >>> wrote: >>> >>> >>> >>>> Has anyone had an issue with the ZFS ARC max being limited below what has >>>> been defined in /boot/loader.conf? I just upgraded the RAM in a >>>> ZFS-equipped system and attempted to devote 4GB to the ARC cache by >>>> placing >>>> the following in loader.conf: >>>> vfs.zfs.arc_max="4096M" >>>> >>>> However, after rebooting, querying the sysctl gives me this: >>>> $ sysctl vfs.zfs.arc_max >>>> vfs.zfs.arc_max: 1726489600 >>>> >>>> or about 1.7GB, an odd number that I can't find any references to. For >>>> reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system with >>>> 8GB >>>> of RAM. The system was previously very stable with 4GB of RAM and a >>>> 512MB >>>> arc_max. I have not modified vm.kmem_size_max (defaults to ~330GB on >>>> amd64) >>>> or any other ZFS tunables. I'd also like to avoid syncing up to the >>>> current >>>> 8-STABLE if at all possible. >>>> >>>> Thanks, >>>> Steve Polyack >>>> >>>> _______________________________________________ >>>> 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" >>>> >>>> >>>> >>> Check your vm.kmem_size. Default setting is way too low. Set it to at >>> least double of desired arc size. >>> >>> --Artem >>> >> I mentioned it briefly, but vm.kmem_size_max was left at the default for >> amd64. At 330GB it is way above and beyond what will ever be allocated to >> ARC: >> $ sysctl vm.kmem_size_max >> vm.kmem_size_max: 329853485875 >> >> >> >> > From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 00:35:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8CE5106568F for ; Sat, 13 Feb 2010 00:35:37 +0000 (UTC) (envelope-from alanbryan1234@yahoo.com) Received: from web50506.mail.re2.yahoo.com (web50506.mail.re2.yahoo.com [206.190.38.82]) by mx1.freebsd.org (Postfix) with SMTP id 4296F8FC12 for ; Sat, 13 Feb 2010 00:35:36 +0000 (UTC) Received: (qmail 49135 invoked by uid 60001); 13 Feb 2010 00:08:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1266019735; bh=Lv0BkxUWzPVmmMAq8FpqGQj6KOZ4moA7RZ/3l6/1Xv4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IeiQ0yMITvlTuMrtBRAGKnN6ANm7+wQUFwlfDHLChA0JpUaYhZiQigB+mPqktEllufVjP6XEnrxu4pUOTa8OXzg+7ThY5w+AO5O2LQK6ZALS78/1fyPTu0iJFVjlK+OLDF7qACMxkj6tFLzbSBV5Y2ffbsHWAnyO/QYm1mpeTXE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=h63O+dFjwx/0SNE6WF6HNMEEHXDCQIkRu2TD4KHdNQyoWoTk+7GZsV+pnhle5YkSYhk+dSvur0XGFq94+cF2jHO5koWSa9N2nKAb4G3nYnwtk+6YXmz6pkTIuDpYvhPOJceaT1YNvq5OzndaMOVdlF2J0ooT5PozMKb/bzq8gQM=; Message-ID: <247310.48932.qm@web50506.mail.re2.yahoo.com> X-YMail-OSG: IzzZhU8VM1ll1poyE018XtnsQVKrenAwqsG.kLObgunHImWm4Q2g93uXL2JQjMS1LKreqeazjWpyO55pfyhaqc7cZDR8Bx_9MI4svDaPuOjX5VCW2S6KloFISxT1CRtVXdePqzmka0pFA9oTVPyDCbPJGLjuE3ZkpSXMZJBImxDSIV6uBkyiRr5.iAo_ENJhfnURuqnLtr2TKNwlQtqiH6X_tGwDFIB_.L6cO572rZkEIwmfI19bkLrTXndJC7lsk_VhfeJAj.P0t8GJooB.OLFblSba5MQfYHIRvcJG8_f7YURIPa9lz_WgWNN7UDYAdnf9pauc9w0x.17sKt0- Received: from [99.24.6.121] by web50506.mail.re2.yahoo.com via HTTP; Fri, 12 Feb 2010 16:08:55 PST X-Mailer: YahooMailClassic/9.1.10 YahooMailWebService/0.8.100.260964 Date: Fri, 12 Feb 2010 16:08:55 -0800 (PST) From: alan bryan To: Dmitry Marakasov , Rick Macklem In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, John Baldwin Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 00:35:37 -0000 =0A=0A--- On Fri, 2/12/10, Rick Macklem wrote:=0A=0A= > From: Rick Macklem =0A> Subject: Re: NFS write corr= uption on 8.0-RELEASE=0A> To: "Dmitry Marakasov" =0A> Cc:= freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, "John Baldwin" =0A> Date: Friday, February 12, 2010, 11:12 AM=0A> =0A> =0A>= On Fri, 12 Feb 2010, Dmitry Marakasov wrote:=0A> =0A> >=0A> > I'm planning= a massive testing for this weekend,=0A> including removing=0A> > soft moun= t option and trying linux client/server.=0A> >=0A> > Btw, I forgot to menti= on that I'm experiencing other=0A> NFS problems from=0A> > time to time, in= cluding "death" of a mount (that is,=0A> all processes that=0A> > try to ac= cess it freeze; this cures itself in some=0A> time with a message=0A> > "se= rver is alive again"). Also I've seen another=0A> strange thing - not=0A> >= only the mount dies but the network is flooded with=0A> NFS traffic.=0A> >= Last time I've seen it quite a while ago, so I don't=0A> remember the=0A> = > circumstances and direction of the traffic.=0A> >=0A> There are some patc= hes at:=0A> =A0=A0=A0 http://people.freebsd.org/~rmacklem=0A> that may be = relevant if you are using vanilla FreeBSD-8.0.=0A> (They're all=0A> now in = stable/8, but are post-release of 8.0.)=0A> =0A> rick=0A> =0A> ____________= ___________________________________=0A> freebsd-stable@freebsd.org=0A> mail= ing list=0A> http://lists.freebsd.org/mailman/listinfo/freebsd-stable=0A> T= o unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"=0A= > =0A=0A=0AThis is interesting:=0A=0A"I've seen another strange thing - not= only the mount dies but the network is flooded with NFS traffic."=0A=0ARic= k - this sounds very similar to the issues I was seeing (and reported in th= e thread on freebsd-stable "Zombie NFS writing from FreeBSD clients to Free= BSD 8.0 server with ZFS". =0A=0AFor the record - I updated to the latest 8= -Stable and that still didn't cure my issues. I was originally on hard mou= nts on udp, tried soft and TCP too, nothing solved it.=0A=0ASo, a few days = ago I switched to using samba and mount_smbfs instead and am now running 3 = days without a crash or any network traffic/load issues. (same machine, sam= e ZFS disks, etc...) Luckily it wasn't too painful to make the change. Wh= en I have more time I'd like to retry NFS.=0A=0A--Alan=0A=0A=0A=0A From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 09:31:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2144106568B; Sat, 13 Feb 2010 09:31:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 7CCAE8FC08; Sat, 13 Feb 2010 09:31:34 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NgELc-00061N-WA; Sat, 13 Feb 2010 11:31:33 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Feb 2010 11:31:32 +0200 From: Daniel Braniss Message-ID: Cc: Subject: NFS/UDP and vfs.nfs.nfs_ip_paranoia=0 does not help X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 09:31:34 -0000 Hi, While trying to find out why our NSF/ZFS servers now hangs about once a week, I got hold of a similiar box, and got a bit more ambitious, I connected it via 2 NICs, to complicate things a bit, the server boots via pxeboot (ie, is datatless). After fiddling with the default gateway, adding -h to rpcbind and mountd, things seem ok, but UDP is 'problematic', I could do with TCP except that am-utils does a fsinfo via UDP when doing a /net/ and will hang the client. even with vfs.nfs.nfs_ip_paranoia=0, when the response from the server arrives with the 'wrong' ip, an ICMP destination unreachable (port unreachable) is replied. in short, on the client: this works: mount_nfs -o mntudp server-ip-vlanA:/mnt /mnt this fails: mount_nfs -o mntudp server-ip-vlanB:/mnt /mnt since the response is coming from server-ip-vlanA. Q: why does this work for TCP and fails for UDP Q: is there a workaround? danny From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 10:39:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63FA41065679 for ; Sat, 13 Feb 2010 10:39:10 +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 BBD2C8FC14 for ; Sat, 13 Feb 2010 10:39:09 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o1DA96Rw058650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 13 Feb 2010 11:09:06 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o1DA93lK052738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Feb 2010 11:09:03 +0100 (CET) (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 o1DA93iY048987; Sat, 13 Feb 2010 11:09:03 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o1DA92Jo048986; Sat, 13 Feb 2010 11:09:02 +0100 (CET) (envelope-from ticso) Date: Sat, 13 Feb 2010 11:09:02 +0100 From: Bernd Walter To: alan bryan Message-ID: <20100213100902.GH43625@cicely7.cicely.de> References: <247310.48932.qm@web50506.mail.re2.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <247310.48932.qm@web50506.mail.re2.yahoo.com> 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, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-hackers@freebsd.org, Dmitry Marakasov , freebsd-stable@freebsd.org, Rick Macklem Subject: Re: NFS write corruption on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 10:39:10 -0000 On Fri, Feb 12, 2010 at 04:08:55PM -0800, alan bryan wrote: > > > --- On Fri, 2/12/10, Rick Macklem wrote: > > > From: Rick Macklem > > Subject: Re: NFS write corruption on 8.0-RELEASE > > To: "Dmitry Marakasov" > > Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, "John Baldwin" > > Date: Friday, February 12, 2010, 11:12 AM > > > > > > On Fri, 12 Feb 2010, Dmitry Marakasov wrote: > > > > > > > > I'm planning a massive testing for this weekend, > > including removing > > > soft mount option and trying linux client/server. > > > > > > Btw, I forgot to mention that I'm experiencing other > > NFS problems from > > > time to time, including "death" of a mount (that is, > > all processes that > > > try to access it freeze; this cures itself in some > > time with a message > > > "server is alive again"). Also I've seen another > > strange thing - not > > > only the mount dies but the network is flooded with > > NFS traffic. > > > Last time I've seen it quite a while ago, so I don't > > remember the > > > circumstances and direction of the traffic. > > > > > There are some patches at: > >     http://people.freebsd.org/~rmacklem > > that may be relevant if you are using vanilla FreeBSD-8.0. > > (They're all > > now in stable/8, but are post-release of 8.0.) > > > > rick > > > > _______________________________________________ > > 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" > > > > > This is interesting: > > "I've seen another strange thing - not only the mount dies but the network is flooded with NFS traffic." You might be able to see NFS flooding with: Write file on client. rm the file during the write on the server. The client now gets IO-errors, but keeps trying forever. Maybe it depends on the mechanism the client application uses to write the file. I never reported because my client is an old 7.0-stable system. I originally noticed it when downloading files with seamonkey on my client and mv it on the server to another partition before it was completely downloaded. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 14:00:59 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8668B1065670 for ; Sat, 13 Feb 2010 14:00:59 +0000 (UTC) (envelope-from turecast@mustang.mos.com.np) Received: from nilgiri.mos.com.np (nilgiri.mos.com.np [202.52.255.7]) by mx1.freebsd.org (Postfix) with ESMTP id CE9AD8FC14 for ; Sat, 13 Feb 2010 14:00:57 +0000 (UTC) Received: from mustang.mos.com.np (mustang.mos.com.np [202.52.255.11]) by nilgiri.mos.com.np (8.13.8/8.13.8) with ESMTP id o1DDSLgi008132 for ; Sat, 13 Feb 2010 19:13:21 +0545 (NPT) (envelope-from turecast@mustang.mos.com.np) Received: (from turecast@localhost) by mustang.mos.com.np (8.13.1/8.13.1/Submit) id o1DDtOBj022284; Sat, 13 Feb 2010 19:40:24 +0545 Date: Sat, 13 Feb 2010 19:40:24 +0545 From: Tulsi Prasad Pathak Message-Id: <201002131355.o1DDtOBj022284@mustang.mos.com.np> To: stable@freebsd.org References: <201002131346.o1DDkBVL009014@kanjiroba.mos.com.np> In-Reply-To: <201002131346.o1DDkBVL009014@kanjiroba.mos.com.np> Cc: Subject: Message rejected due to out of space X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 14:00:59 -0000 Your mail has been administratively rejected. Reciptent will not receive this mail due to quota limit . ############################################################ From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 14:23:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96271106568D; Sat, 13 Feb 2010 14:23:51 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB8A8FC0A; Sat, 13 Feb 2010 14:23:51 +0000 (UTC) Received: from neon.fritz.box (helium.xs4all.nl [83.163.52.241]) (authenticated bits=0) by erg.verweg.com (8.14.4/8.14.3) with ESMTP id o1DENgwN077668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 13 Feb 2010 14:23:48 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host helium.xs4all.nl [83.163.52.241] claimed to be neon.fritz.box From: Ruben van Staveren Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Feb 2010 15:23:37 +0100 Message-Id: <0E158D8A-8170-4306-9DA8-6BA993DC18FB@verweg.com> To: FreeBSD Stable , kvs@pil.dk Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Spam-Status: No, score=3.1 required=5.0 tests=DATE_IN_FUTURE_06_12 autolearn=no version=3.2.5 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on erg.verweg.com X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (erg.verweg.com [94.142.245.8]); Sat, 13 Feb 2010 14:23:49 +0000 (UTC) Cc: bug-followup@FreeBSD.org Subject: Re: kern/140661: [zfs] /boot/loader fails to work on a GPT/ZFS-only system on both 8.0-RC2 and RC3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 14:23:51 -0000 > On Nov 18, 2009, at 21:57 , Scot Hetzel wrote: > > Make sure you have LOADER_ZFS_SUPPORT in your /etc/src.conf: > >=20 > > dv8t01# cat /etc/src.conf > > LOADER_ZFS_SUPPORT=3DYES >=20 > Ah! I also have LOADER_TFTP_SUPPORT=3DYES. Removing that, and = everything works. > I don't know why I didn't think of that in the first place, but maybe = this > is either a bug, or something that should be warned about when = building > loader(8)? >=20 > /Kenneth I had the same problem which went away after removing TFTP support and = reinstalling the bootcode.=20 For now I suggest to add the following patch: --- sys/boot/i386/loader/conf.c.orig 2010-02-13 14:08:31.154391969 = +0000 +++ sys/boot/i386/loader/conf.c 2010-02-13 14:11:11.119255786 +0000 @@ -46,6 +46,10 @@ #error "Cannot have both tftp and nfs support yet." #endif =20 +#if defined(LOADER_ZFS_SUPPORT) && defined(LOADER_TFTP_SUPPORT) +#error "Cannot have both tftp and zfs support yet." +#endif + #if defined(LOADER_FIREWIRE_SUPPORT) extern struct devsw fwohci; #endif I think having both options corrupt each other's environment=20 system: FreeBSD freebsd-master 8.0-STABLE FreeBSD 8.0-STABLE #2: Mon Jan 18 = 16:14:24 UTC 2010 = root@freebsd-master:/usr/obj/usr/cvsup/8-stable/src/sys/VMWARE amd64 Regards, Ruben From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 17:05:18 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C5381065679; Sat, 13 Feb 2010 17:05:18 +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 3ADB08FC08; Sat, 13 Feb 2010 17:05:17 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-37.bna.bellsouth.net [74.241.172.37]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1DH5Fmr034046 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 13 Feb 2010 12:05:15 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Ulrich =?ISO-8859-1?Q?Sp=F6rlein?= In-Reply-To: <20100211074933.GJ9748@acme.spoerlein.net> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <4B728A7A.60706@gmail.com> <1265814670.8609.58.camel@balrog.2hip.net> <20100210180042.GF9748@acme.spoerlein.net> <1265825292.8609.81.camel@balrog.2hip.net> <20100211074933.GJ9748@acme.spoerlein.net> Content-Type: text/plain; charset="ISO-8859-1" Organization: FreeBSD Date: Sat, 13 Feb 2010 11:05:09 -0600 Message-Id: <1266080709.89452.21.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX,RCVD_IN_PBL,RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@FreeBSD.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 17:05:18 -0000 On Thu, 2010-02-11 at 08:49 +0100, Ulrich Spörlein wrote: > On Wed, 10.02.2010 at 12:08:12 -0600, Robert Noland wrote: > > On Wed, 2010-02-10 at 19:00 +0100, Ulrich Spörlein wrote: > > > On Wed, 10.02.2010 at 09:11:10 -0600, Robert Noland wrote: > > > > I have a strong suspicion that the issue is with bus_dma. If this is a > > > > pci based card, then it is trying to allocate 32MB of contiguous > > > > physical ram when the drm device is opened. This usually succeeds the > > > > first time that the driver opens the device, but later, after memory has > > > > become fragmented, this can become an issue. As I have mentioned, I > > > > have code that reworks this whole process and I'll try and make a patch > > > > available soon, but my I don't have a lot of time now, so it might be > > > > the weekend before I can rebase the code and get a clean patch. > > > > > > No deadlocks for me, but I've been hit by the 32MB issue. On 8-STABLE without > > > the recent Xorg update (haven't done that yet) I usually startx right after > > > boot, and this usually works fine. > > > > > > One time I had massive ZFS/git jobs running headless first and wanted to > > > startx afterwards. X11 took quite some time to come up and although > > > window "switching" was snappy, *moving* windows around was slow as hell, > > > window contents were re-drawing at ~1FPS. > > > > > > This also seems to always happen if I stop X11 and startx it again. > > > So I made a diff from a regular Xorg startup against the slow one: > > > > > > --- Xorg.0.log 2010-02-09 20:59:16.000000000 +0100 > > > +++ Xorg.slow.log 2010-01-31 11:04:08.000000000 +0100 > > > ... > > > @@ -599,49 +599,22 @@ > > > (II) RADEON(0): [drm] added 1 reserved context for kernel > > > (II) RADEON(0): X context handle = 0x1 > > > (II) RADEON(0): [drm] installed DRM signal handler > > > -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xed1a5000 > > > -(II) RADEON(0): [pci] ring handle = 0xed1a5000 > > > -(II) RADEON(0): [pci] Ring mapped at 0x802aa0000 > > > -(II) RADEON(0): [pci] Ring contents 0x00000000 > > > -(II) RADEON(0): [pci] ring read ptr handle = 0xed2a6000 > > > -(II) RADEON(0): [pci] Ring read ptr mapped at 0x8006d6000 > > > -(II) RADEON(0): [pci] Ring read ptr contents 0x00000000 > > > -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xed2a7000 > > > -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812c00000 > > > -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000 > > > -(II) RADEON(0): [pci] GART texture map handle = 0xed4a7000 > > > -(II) RADEON(0): [pci] GART Texture map mapped at 0x812ea7000 > > > -(II) RADEON(0): [drm] register handle = 0xfe8e0000 > > > -(II) RADEON(0): [dri] Visual configs initialized > > > +(EE) RADEON(0): [pci] Out of memory (-12) > > > > Yes, drm failed to allocate the 32MB to back the GART, so drm was > > disabled. Hopefully, the new allocation strategy will resolve this > > since it will just require 32MB of physical ram below 4GB without > > needing it to be contiguous. > > Hmm, given that today, 32MB isn't really that much, wouldn't it make > more sense to have radeon(4) reserve those 32MB on load and never let > go? I have radeon_load=YES set in loader.conf so it has a fair chance to > always get it's 32MB contig. memory during startup. Given ZFS' memory > hunger, there may not be enough free physical RAM below 4GB ... Ok, I've put up a patch at: http://people.freebsd.org/~rnoland/drm-radeon-test.patch This is sort of a mega patch and includes: Re-worked drm mapping code, that ensures that we don't end up incorrectly mapping certain maps with overlapping offsets. This generally shows up as the ring buffer not being cleared (contents != 0 in xorg.log) which leads to corruption and other bad behavior. Re-written scatter gather allocation code. This interacts directly with the VM system, rather than using bus_dma to allow us to grab non-contiguous pages for the scatter gather backing of the GART. It also makes it easier to handle the caching mode of the backing pages. Disable cache snooping on radeon cards, since we have write combining set properly now. I have at least done a test build on -CURRENT with this patch, but I haven't had time to do much else without the rest of the code in my tree. I've been running most all of this code for a month or two now at least, so it is mostly just a question of whether or not I got all of the conflicts sorted out properly when I made this patch. The re-mapping code has the most widespread impact and has been tested on radeon r600 amd64, intel g45 i386 and mga amd64. robert. > But it's your call, you obviously know more about this than me anyway :) > > Bye, > Uli -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 18:24:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0588B1065693 for ; Sat, 13 Feb 2010 18:24:06 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id B47358FC08 for ; Sat, 13 Feb 2010 18:24:05 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KXS002D2LS4X960@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 13 Feb 2010 19:24:04 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KXS002T8LS4H752@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 13 Feb 2010 19:24:04 +0100 (CET) Date: Sat, 13 Feb 2010 19:24:04 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100213192404.5e15b5eb.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100207163631.da7205fc.torfinn.ingolfsen@broadpark.no> References: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> <20100207163631.da7205fc.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: panic - sleeping thread on FreeBSD 8.0-stable / amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 18:24:06 -0000 On Sun, 07 Feb 2010 16:36:31 +0100 Torfinn Ingolfsen wrote: > Well, it was stable for many days, but today it rebooted on its ownb again. > After the fact, I see this in /var/log/messages: > Feb 7 11:50:16 kg-f2 ntpd[906]: time reset +2.376096 s > Feb 7 12:02:21 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f > Feb 7 12:02:21 kg-f2 kernel: ata6: hardware reset timeout > Feb 7 12:05:43 kg-f2 syslogd: kernel boot file is /boot/kernel/kernel > > So there is probably some problem with a cable or disk. Or just plain broken hardware. The machine rebooted last night. In /var/log/messages I see: Feb 13 03:50:20 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 13 03:50:20 kg-f2 kernel: ata5: hardware reset timeout Last time it was ata6 and now it is ata5? Hmm... -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 18:50:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A3FD10656A8 for ; Sat, 13 Feb 2010 18:50:35 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 2302C8FC15 for ; Sat, 13 Feb 2010 18:50:34 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KXS002SJN09X970@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 13 Feb 2010 19:50:34 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KXS001VEN09WYF2@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 13 Feb 2010 19:50:33 +0100 (CET) Date: Sat, 13 Feb 2010 19:50:33 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100213195033.f888420c.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100212194604.GA73961@icarus.home.lan> References: <20100211190652.6a66c618.torfinn.ingolfsen@broadpark.no> <20100211192515.GB13854@icarus.home.lan> <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100212194604.GA73961@icarus.home.lan> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.6; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 18:50:35 -0000 On Fri, 12 Feb 2010 11:46:04 -0800 Jeremy Chadwick wrote: > override this though! :-) ), which -- assuming it works -- should > solve your problem. We'll see. The box rebooted again last night (see another thread on this mailing list), so now I have added kern.timecounter.hardware=ACPI-safe to /etc/sysctl.conf, just in case it reboots again. > Technical footnote: I wish I understood 1) the difference between > ACPI-safe and ACPI-fast, and 2) how the system or OS "ranks" the I'm still wondering why this machine doesn't have ACPI-fast: oot@kg-f2# sysctl kern.timecounter.choice kern.timecounter.choice: TSC(-100) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) While my workstation do: tingo@kg-v2$ sysctl kern.timecounter.choice kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) and anaother machine: root@kg-quiet# sysctl kern.timecounter.choice kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-1000000) and another: root@kg-vm# sysctl kern.timecounter.choice kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-1000000) Probably a BIOS / acpi problem. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 19:37:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 692E51065679 for ; Sat, 13 Feb 2010 19:37:37 +0000 (UTC) (envelope-from npapke@acm.org) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id CDE528FC17 for ; Sat, 13 Feb 2010 19:37:36 +0000 (UTC) Received: from pd3ml3so-ssvc.prod.shaw.ca ([10.0.141.149]) by pd4mo1so-svcs.prod.shaw.ca with ESMTP; 13 Feb 2010 12:37:36 -0700 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=ymFRpTLrexEA:10 a=VF9RaR9bft6c8SsOr3WyFg==:17 a=6I5d2MoRAAAA:8 a=N54-gffFAAAA:8 a=aR16PxjQAAAA:8 a=2z1OXlWFAAAA:8 a=Ebazn5UlhOzpjRE1OuQA:9 a=tN7wd87DdxqnCK7R6swA:7 a=D9UI1bhrPA3VvSD718qs1iOQXUwA:4 a=JXQJvpueyLIA:10 a=qqlwiqL-QEIA:10 a=h71UUtTGq9UA:10 a=TRaWWqdqQ4oA:10 a=CiSHi91Bn78A:10 a=nAPXUAfsBmEA:10 a=aWTTYslQkP0A:10 a=4BmTvhtZNv4MxFhP:21 a=yyThsc6ys4sw7eqs:21 Received: from unknown (HELO proven.lan.provenpath.ca) ([24.85.241.34]) by pd3ml3so-dmz.prod.shaw.ca with ESMTP; 13 Feb 2010 12:37:35 -0700 Received: from proven.lan.provenpath.ca (localhost [127.0.0.1]) by proven.lan.provenpath.ca (8.14.4/8.14.4) with ESMTP id o1DJbZak002593; Sat, 13 Feb 2010 11:37:35 -0800 (PST) (envelope-from npapke@acm.org) Received: (from npapke@localhost) by proven.lan.provenpath.ca (8.14.4/8.14.4/Submit) id o1DJbY37002592; Sat, 13 Feb 2010 11:37:34 -0800 (PST) (envelope-from npapke@acm.org) X-Authentication-Warning: proven.lan.provenpath.ca: npapke set sender to npapke@acm.org using -f From: Norbert Papke To: freebsd-stable@freebsd.org, rnoland@freebsd.org Date: Sat, 13 Feb 2010 11:37:34 -0800 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.5; amd64; ; ) References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <20100211074933.GJ9748@acme.spoerlein.net> <1266080709.89452.21.camel@balrog.2hip.net> In-Reply-To: <1266080709.89452.21.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201002131137.34812.npapke@acm.org> Cc: Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 19:37:37 -0000 On February 13, 2010, Robert Noland wrote: > Ok, I've put up a patch at: > > http://people.freebsd.org/~rnoland/drm-radeon-test.patch > > This is sort of a mega patch and includes: > > Re-worked drm mapping code, that ensures that we don't end up > incorrectly mapping certain maps with overlapping offsets. This > generally shows up as the ring buffer not being cleared (contents != 0 > in xorg.log) which leads to corruption and other bad behavior. > > Re-written scatter gather allocation code. This interacts directly with > the VM system, rather than using bus_dma to allow us to grab > non-contiguous pages for the scatter gather backing of the GART. It > also makes it easier to handle the caching mode of the backing pages. > > Disable cache snooping on radeon cards, since we have write combining > set properly now. > > I have at least done a test build on -CURRENT with this patch, but I > haven't had time to do much else without the rest of the code in my > tree. I've been running most all of this code for a month or two now at > least, so it is mostly just a question of whether or not I got all of > the conflicts sorted out properly when I made this patch. > > The re-mapping code has the most widespread impact and has been tested > on radeon r600 amd64, intel g45 i386 and mga amd64. > > robert. I tweaked the patch and applied it to 8-STABLE. It has improved things. I no longer hang when starting X but DRI still does not work. I also intermittently experience the interrupt problem where the screen does not update unless I wiggle the mouse. It is entirely possible that I messed up adapting the patch for 8-STABLE. I did the following: * applied SVN 203287 and 203287 for VIA support * applied your patch * reverted drm_vm.c because it is dependent on r201223 (Update d_mmap() to accept vm_ooffset_t and vm_memattr_t.) * re-enabled snooping in ati_pcigart.c and r600_cp.c I have appended my xorg.0.log file. Perhaps something in there stands out as red flag? Thank you for all the time you put into this. Cheers, -- Norbert Papke. npapke@acm.org X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-STABLE amd64 Current Operating System: FreeBSD proven.lan.provenpath.ca 8.0-STABLE FreeBSD 8.0-STABLE #36 r203841M: Sat Feb 13 10:50:20 PST 2010 npapke@proven.lan.provenpath.ca:/usr/obj/red/usr/public/freebsd/sources/stable8/sys/PROVEN amd64 Build Date: 10 February 2010 06:25:15PM 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: Sat Feb 13 10:55:30 2010 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "LG" (**) | |-->Device "Card0" (**) Option "DontZap" "off" (**) Option "BlankTime" "15" (**) Option "StandbyTime" "120" (**) Option "SuspendTime" "150" (**) Option "OffTime" "180" (**) Option "AIGLX" "on" (**) Option "AllowEmptyInput" "false" (==) Automatically adding devices (==) Automatically enabling devices (WW) `fonts.dir' not found (or not valid) in "/usr/local/share/fonts/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/share/fonts/"). (WW) `fonts.dir' not found (or not valid) in "/usr/local/share/fonts/cmpsfont". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/share/fonts/cmpsfont"). (WW) `fonts.dir' not found (or not valid) in "/usr/local/share/fonts/amspsfont". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/share/fonts/amspsfont"). (**) FontPath set to: /usr/local/lib/X11/fonts/bitstream-vera/, /usr/local/lib/X11/fonts/dejavu/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TrueType/, /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/webfonts/, /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" (**) Extension "Composite" is enabled (==) |-->Input Device "" (==) |-->Input Device "" (==) The core pointer device wasn't specified explicitly in the layout. Using the default mouse configuration. (==) The core keyboard device wasn't specified explicitly in the layout. Using the default keyboard configuration. (II) Loader magic: 0x3f60 (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 9 (--) PCI:*(0:1:0:0) 1002:9598:1043:01e4 ATI Technologies Inc Mobility Radeon HD 3600 Series 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) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.6.5, 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 XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.6.5, 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: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (**) AIGLX enabled (II) Loading extension GLX (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.6.5, 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: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "ati" (II) Loading /usr/local/lib/xorg/modules/drivers//ati_drv.so (II) Module ati: vendor="X.Org Foundation" compiled for 1.6.5, module version = 6.12.4 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) LoadModule: "radeon" (II) Loading /usr/local/lib/xorg/modules/drivers//radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" compiled for 1.6.5, module version = 6.12.4 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.5, 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.5, module version = 1.3.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (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 X800 VE (R420) JT (AGP), ATI Radeon X850 (R480) (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 Radeon HD 4850 x2, 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 Radeon 4800 Series, ATI Radeon 4800 Series, ATI FirePro M7750, ATI M98, ATI M98, ATI M98, ATI Mobility Radeon HD 4650, ATI Radeon RV730 (AGP), ATI Mobility Radeon HD 4670, ATI FirePro M5750, ATI Radeon RV730 (AGP), ATI RV730XT [Radeon HD 4670], ATI RADEON E4600, ATI Radeon HD 4600 Series, ATI RV730 PRO [Radeon HD 4650], ATI FirePro V7750 (FireGL), ATI FirePro V5700 (FireGL), ATI FirePro V3750 (FireGL), ATI Mobility Radeon HD 4830, ATI Mobility Radeon HD 4850, ATI FirePro M7740, ATI RV740, ATI Radeon HD 4770, ATI Radeon HD 4700 Series, ATI Radeon HD 4770, ATI FirePro M5750, 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 FirePro RG220, 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, ATI Radeon HD 3200 Graphics, ATI Radeon 3000 Graphics, ATI Radeon HD 4200, ATI Radeon 4100, ATI Mobility Radeon HD 4200, ATI Mobility Radeon 4100, ATI RS880 (II) Primary Device is: PCI 01@00:00:0 (II) resource ranges after xf86ClaimFixedResources() call: [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) 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] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) RADEON(0): TOTO SAYS 00000000fe9e0000 (II) RADEON(0): MMIO registers at 0x00000000fe9e0000: size 64KB (II) RADEON(0): PCI bus 1 card 0 func 0 (**) RADEON(0): Depth 24, (--) framebuffer bpp 32 (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) (==) RADEON(0): Default visual is TrueColor (**) RADEON(0): Option "AccelMethod" "exa" (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/local/lib/xorg/modules//libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 1.6.5, module version = 0.1.0 ABI class: X.Org Video Driver, version 5.0 (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (==) RADEON(0): RGB weight 888 (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) (--) RADEON(0): Chipset: "ATI Radeon HD 3600 XT" (ChipID = 0x9598) (--) RADEON(0): Linear framebuffer at 0x00000000d0000000 (II) RADEON(0): PCIE card detected (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.5, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) RADEON(0): initializing int10 (==) RADEON(0): Write-combining range (0xa0000,0x20000) was already clear (==) RADEON(0): Write-combining range (0xc0000,0x40000) was already clear (II) RADEON(0): Primary V_BIOS segment is: 0xc000 (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear (II) RADEON(0): ATOM BIOS detected (II) RADEON(0): ATOM BIOS Rom: SubsystemVendorID: 0x1043 SubsystemID: 0x01e4 IOBaseAddress: 0xc000 Filename: SV27381.bin BIOS Bootup Message: 9598.10.74.0.1.AS01 (II) RADEON(0): Framebuffer space used by Firmware (kb): 16 (II) RADEON(0): Start of VRAM area used by Firmware: 0x1fffc000 (II) RADEON(0): AtomBIOS requests 16kB of VRAM scratch space (II) RADEON(0): AtomBIOS VRAM scratch base: 0x1fffc000 (II) RADEON(0): Cannot get VRAM scratch space. Allocating in main memory instead (II) RADEON(0): Default Engine Clock: 725000 (II) RADEON(0): Default Memory Clock: 700000 (II) RADEON(0): Maximum Pixel ClockPLL Frequency Output: 1200000 (II) RADEON(0): Minimum Pixel ClockPLL Frequency Output: 0 (II) RADEON(0): Maximum Pixel ClockPLL Frequency Input: 13500 (II) RADEON(0): Minimum Pixel ClockPLL Frequency Input: 1000 (II) RADEON(0): Maximum Pixel Clock: 400000 (II) RADEON(0): Reference Clock: 27000 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.31.0 (==) RADEON(0): Page Flipping disabled on r5xx and newer chips. (II) RADEON(0): Will try to use DMA for Xv image transfers (II) RADEON(0): Detected total video RAM=524288K, accessible=262144K (PCI BAR=262144K) (--) RADEON(0): Mapped VideoRAM: 262144 kByte (128 bit DDR SDRAM) (II) RADEON(0): Color tiling disabled (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Module "ddc" already built-in (II) Loading sub module "i2c" (II) LoadModule: "i2c" (II) Module "i2c" already built-in (II) RADEON(0): ref_freq: 2700, min_out_pll: 64800, max_out_pll: 120000, min_in_pll: 100, max_in_pll: 1350, xclk: 40000, sclk: 725.000000, mclk: 700.000000 (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=64800 max=120000; xclk=40000 Shared DDC line: 1 4 Shared DDC line: 1 5 Shared DDC line: 4 1 (II) RADEON(0): Output HDMI-0 using monitor section LG (II) RADEON(0): I2C bus "HDMI-0" initialized. (II) RADEON(0): Output VGA-0 has no monitor section (II) RADEON(0): I2C bus "VGA-0" initialized. (II) RADEON(0): Output DVI-0 has no monitor section (II) RADEON(0): I2C bus "DVI-0" initialized. (II) RADEON(0): Port0: XRANDR name: HDMI-0 Connector: HDMI-A DFP1: INTERNAL_UNIPHY DDC reg: 0x7e50 (II) RADEON(0): Port1: XRANDR name: VGA-0 Connector: VGA CRT2: INTERNAL_KLDSCP_DAC2 DDC reg: 0x7e50 (II) RADEON(0): Port2: XRANDR name: DVI-0 Connector: DVI-I CRT1: INTERNAL_KLDSCP_DAC1 DFP2: INTERNAL_KLDSCP_LVTMA DDC reg: 0x7e40 (II) RADEON(0): I2C device "HDMI-0:E-EDID segment register" registered at address 0x60. (II) RADEON(0): I2C device "HDMI-0:ddc2" registered at address 0xA0. (II) RADEON(0): Output: HDMI-0, Detected Monitor Type: 0 finished output detect: 0 (II) RADEON(0): I2C device "VGA-0:E-EDID segment register" registered at address 0x60. (II) RADEON(0): I2C device "VGA-0:ddc2" registered at address 0xA0. Dac detection success (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 finished output detect: 1 (II) RADEON(0): I2C device "DVI-0:E-EDID segment register" registered at address 0x60. (II) RADEON(0): I2C device "DVI-0:ddc2" registered at address 0xA0. (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on output: DVI-0 ---------------------- (II) RADEON(0): Manufacturer: GSM Model: 4a78 Serial#: 71815 (II) RADEON(0): Year: 2005 Week: 2 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max Image Size [cm]: horiz.: 38 vert.: 30 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.647 redY: 0.346 greenX: 0.292 greenY: 0.602 (II) RADEON(0): blueX: 0.149 blueY: 0.130 whiteX: 0.312 whiteY: 0.328 (II) RADEON(0): Supported established timings: (II) RADEON(0): 720x400@70Hz (II) RADEON(0): 640x480@60Hz (II) RADEON(0): 640x480@75Hz (II) RADEON(0): 800x600@60Hz (II) RADEON(0): 800x600@75Hz (II) RADEON(0): 832x624@75Hz (II) RADEON(0): 1024x768@60Hz (II) RADEON(0): 1024x768@75Hz (II) RADEON(0): 1280x1024@75Hz (II) RADEON(0): 1152x870@75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported standard timings: (II) RADEON(0): #0: hsize: 640 vsize 480 refresh: 75 vid: 20273 (II) RADEON(0): #1: hsize: 800 vsize 600 refresh: 75 vid: 20293 (II) RADEON(0): #2: hsize: 1024 vsize 768 refresh: 75 vid: 20321 (II) RADEON(0): #3: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): Supported detailed timing: (II) RADEON(0): clock: 108.0 MHz Image Size: 376 x 301 mm (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 83 kHz, PixClock max 140 MHz (II) RADEON(0): Monitor name: L1910S (II) RADEON(0): Monitor name: (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff001e6d784a87180100 (II) RADEON(0): 020f01036e261e78eaec50a5584a9a26 (II) RADEON(0): 215054a56b80314f454f614f81800101 (II) RADEON(0): 010101010101302a009851002a403070 (II) RADEON(0): 1300782d1100001e000000fd00384b1e (II) RADEON(0): 530e000a202020202020000000fc004c (II) RADEON(0): 3139313053200a2020202020000000fc (II) RADEON(0): 000a20202020202020202020202000d8 finished output detect: 2 finished all detect before xf86InitialConfiguration (II) RADEON(0): Output: HDMI-0, Detected Monitor Type: 0 Dac detection success (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on output: DVI-0 ---------------------- (II) RADEON(0): Manufacturer: GSM Model: 4a78 Serial#: 71815 (II) RADEON(0): Year: 2005 Week: 2 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max Image Size [cm]: horiz.: 38 vert.: 30 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.647 redY: 0.346 greenX: 0.292 greenY: 0.602 (II) RADEON(0): blueX: 0.149 blueY: 0.130 whiteX: 0.312 whiteY: 0.328 (II) RADEON(0): Supported established timings: (II) RADEON(0): 720x400@70Hz (II) RADEON(0): 640x480@60Hz (II) RADEON(0): 640x480@75Hz (II) RADEON(0): 800x600@60Hz (II) RADEON(0): 800x600@75Hz (II) RADEON(0): 832x624@75Hz (II) RADEON(0): 1024x768@60Hz (II) RADEON(0): 1024x768@75Hz (II) RADEON(0): 1280x1024@75Hz (II) RADEON(0): 1152x870@75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported standard timings: (II) RADEON(0): #0: hsize: 640 vsize 480 refresh: 75 vid: 20273 (II) RADEON(0): #1: hsize: 800 vsize 600 refresh: 75 vid: 20293 (II) RADEON(0): #2: hsize: 1024 vsize 768 refresh: 75 vid: 20321 (II) RADEON(0): #3: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): Supported detailed timing: (II) RADEON(0): clock: 108.0 MHz Image Size: 376 x 301 mm (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 83 kHz, PixClock max 140 MHz (II) RADEON(0): Monitor name: L1910S (II) RADEON(0): Monitor name: (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff001e6d784a87180100 (II) RADEON(0): 020f01036e261e78eaec50a5584a9a26 (II) RADEON(0): 215054a56b80314f454f614f81800101 (II) RADEON(0): 010101010101302a009851002a403070 (II) RADEON(0): 1300782d1100001e000000fd00384b1e (II) RADEON(0): 530e000a202020202020000000fc004c (II) RADEON(0): 3139313053200a2020202020000000fc (II) RADEON(0): 000a20202020202020202020202000d8 (II) RADEON(0): EDID vendor "GSM", prod id 19064 (II) RADEON(0): Output HDMI-0 disconnected (II) RADEON(0): Output VGA-0 disconnected (II) RADEON(0): Output DVI-0 connected (II) RADEON(0): Using user preference for initial modes (II) RADEON(0): Output DVI-0 using initial mode 1280x1024 after xf86InitialConfiguration (==) RADEON(0): DPI set to (96, 96) (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.5, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0) (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Module "ramdac" already built-in (==) RADEON(0): Will attempt to use R6xx/R7xx EXA support if DRI is enabled. (II) Loading sub module "exa" (II) LoadModule: "exa" (II) Loading /usr/local/lib/xorg/modules//libexa.so (II) Module exa: vendor="X.Org Foundation" compiled for 1.6.5, module version = 2.4.0 ABI class: X.Org Video Driver, version 5.0 (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear (!!) RADEON(0): For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net. (!!) RADEON(0): MergedFB support has been removed and replaced with xrandr 1.2 support (--) 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] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) RADEON(0): RADEONScreenInit d0000000 0 0 (==) RADEON(0): Write-combining range (0xa0000,0x10000) was already clear Output CRT1 disable success Blank CRTC 0 success Disable CRTC 0 success Disable CRTC memreq 0 success Blank CRTC 1 success Disable CRTC 1 success Disable CRTC memreq 1 success (==) RADEON(0): Using 24 bit depth buffer mc fb loc is 00ef00d0 (II) RADEON(0): RADEONInitMemoryMap() : (II) RADEON(0): mem_size : 0x20000000 (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 (II) RADEON(0): Depth moves disabled by default (II) RADEON(0): Allocating from a screen of 262080 kb (II) RADEON(0): Will use 32 kb for hardware cursor 0 at offset 0x00640000 (II) RADEON(0): Will use 32 kb for hardware cursor 1 at offset 0x00644000 (II) RADEON(0): Will use 6400 kb for front buffer at offset 0x00000000 (II) RADEON(0): Will use 64 kb for PCI GART at offset 0x0fff0000 (II) RADEON(0): Will use 6400 kb for back buffer at offset 0x00648000 (II) RADEON(0): Will use 6400 kb for depth buffer at offset 0x00c88000 (II) RADEON(0): Will use 120832 kb for textures at offset 0x012c8000 (II) RADEON(0): Will use 122016 kb for X Server offscreen at offset 0x088c8000 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) [drm] DRM interface version 1.2 (II) [drm] Mapping SAREA for DRM lock failed. (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ff00e0 (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 (==) RADEON(0): Backing store disabled (WW) RADEON(0): Direct rendering disabled (EE) RADEON(0): Acceleration initialization failed (II) RADEON(0): Acceleration disabled (**) Option "dpms" (**) RADEON(0): DPMS enabled (==) RADEON(0): Silken mouse enabled (II) RADEON(0): Textured video requires CP on R5xx/R6xx/R7xx/IGP (II) RADEON(0): DIG0 transmitter: Coherent Mode enabled Output DIG0 transmitter setup success Output CRT2 disable success Output CRT1 disable success Blank CRTC 0 success Disable CRTC 0 success Disable CRTC memreq 0 success Blank CRTC 1 success Disable CRTC 1 success Disable CRTC memreq 1 success Output CRT1 disable success Blank CRTC 0 success Disable CRTC 0 success Disable CRTC memreq 0 success Mode 1280x1024 - 1688 1066 5 (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 freq: 108000000 best_freq: 108000000 best_feedback_div: 48 best_ref_div: 2 best_post_div: 6 (II) RADEON(0): crtc(0) Clock: mode 108000, PLL 108000 (II) RADEON(0): crtc(0) PLL : refdiv 2, fbdiv 0x30(48), pdiv 6 Set CRTC 0 PLL success Set CRTC Timing success Set CRTC 0 Overscan success Not using RMX scaler 0 setup success Set CRTC 0 Source success crtc 0 YUV disable setup success Output DAC1 setup success Output CRT1 enable success Enable CRTC memreq 0 success Enable CRTC 0 success Unblank CRTC 0 success (II) RADEON(0): DIG0 transmitter: Coherent Mode enabled Output DIG0 transmitter setup success Output CRT2 disable success Blank CRTC 1 success Disable CRTC 1 success Disable CRTC memreq 1 success (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message. Output CRT1 disable success Blank CRTC 0 success Disable CRTC 0 success Disable CRTC memreq 0 success Mode 1280x1024 - 1688 1066 5 (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 freq: 108000000 best_freq: 108000000 best_feedback_div: 48 best_ref_div: 2 best_post_div: 6 (II) RADEON(0): crtc(0) Clock: mode 108000, PLL 108000 (II) RADEON(0): crtc(0) PLL : refdiv 2, fbdiv 0x30(48), pdiv 6 Set CRTC 0 PLL success Set CRTC Timing success Set CRTC 0 Overscan success Not using RMX scaler 0 setup success Set CRTC 0 Source success crtc 0 YUV disable setup success Output DAC1 setup success Output CRT1 enable success Enable CRTC memreq 0 success Enable CRTC 0 success Unblank CRTC 0 success (--) RandR disabled (II) Setting vga for screen 0. (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: Screen 0 is not DRI2 capable (II) AIGLX: Screen 0 is not DRI capable (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 (II) RADEON(0): Setting screen physical size to 376 x 301 (WW) : No Device specified, looking for one... (II) : Setting Device option to "/dev/sysmouse" (--) : Device: "/dev/sysmouse" (==) : Protocol: "Auto" (**) Option "CorePointer" (**) : always reports core events (==) : Emulate3Buttons, Emulate3Timeout: 50 (**) : ZAxisMapping: buttons 4 and 5 (**) : Buttons: 9 (**) : Sensitivity: 1 (II) XINPUT: Adding extended input device "" (type: MOUSE) (**) : (accel) keeping acceleration scheme 1 (**) : (accel) filter chain progression: 2.00 (**) : (accel) filter stage 0: 20.00 ms (**) : (accel) set acceleration profile 0 (II) : SetupAuto: hw.iftype is 4, hw.model is 0 (II) : SetupAuto: protocol is SysMouse (**) Option "CoreKeyboard" (**) : always reports core events (**) Option "Protocol" "standard" (**) : Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) : XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) : XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) : XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) : CustomKeycodes disabled (II) XINPUT: Adding extended input device "" (type: KEYBOARD) (II) config/hal: Adding input device USB-PS/2 Optical Mouse (**) USB-PS/2 Optical Mouse: Device: "/dev/sysmouse" (==) USB-PS/2 Optical Mouse: Protocol: "Auto" (**) USB-PS/2 Optical Mouse: always reports core events (**) Option "Device" "/dev/sysmouse" (==) USB-PS/2 Optical Mouse: Emulate3Buttons, Emulate3Timeout: 50 (**) USB-PS/2 Optical Mouse: ZAxisMapping: buttons 4 and 5 (**) USB-PS/2 Optical Mouse: Buttons: 9 (**) USB-PS/2 Optical Mouse: Sensitivity: 1 (II) XINPUT: Adding extended input device "USB-PS/2 Optical Mouse" (type: MOUSE) (**) USB-PS/2 Optical Mouse: (accel) keeping acceleration scheme 1 (**) USB-PS/2 Optical Mouse: (accel) filter chain progression: 2.00 (**) USB-PS/2 Optical Mouse: (accel) filter stage 0: 20.00 ms (**) USB-PS/2 Optical Mouse: (accel) set acceleration profile 0 (II) USB-PS/2 Optical Mouse: SetupAuto: hw.iftype is 4, hw.model is 0 (II) USB-PS/2 Optical Mouse: SetupAuto: protocol is SysMouse (II) config/hal: Adding input device AT Keyboard (**) AT Keyboard: always reports core events (**) Option "Protocol" "standard" (**) AT Keyboard: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) AT Keyboard: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) AT Keyboard: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) AT Keyboard: XkbLayout: "us" (**) Option "XkbOptions" "terminate:ctrl_alt_bksp" (**) AT Keyboard: XkbOptions: "terminate:ctrl_alt_bksp" (**) Option "CustomKeycodes" "off" (**) AT Keyboard: CustomKeycodes disabled (II) XINPUT: Adding extended input device "AT Keyboard" (type: KEYBOARD) (II) RADEON(0): Output: HDMI-0, Detected Monitor Type: 0 Dac detection success (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 (II) RADEON(0): EDID vendor "GSM", prod id 19064 (II) RADEON(0): Using EDID range info for horizontal sync (II) RADEON(0): Using EDID range info for vertical refresh (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on output: DVI-0 ---------------------- (II) RADEON(0): Manufacturer: GSM Model: 4a78 Serial#: 71815 (II) RADEON(0): Year: 2005 Week: 2 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V (II) RADEON(0): Sync: Separate Composite SyncOnGreen (II) RADEON(0): Max Image Size [cm]: horiz.: 38 vert.: 30 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.647 redY: 0.346 greenX: 0.292 greenY: 0.602 (II) RADEON(0): blueX: 0.149 blueY: 0.130 whiteX: 0.312 whiteY: 0.328 (II) RADEON(0): Supported established timings: (II) RADEON(0): 720x400@70Hz (II) RADEON(0): 640x480@60Hz (II) RADEON(0): 640x480@75Hz (II) RADEON(0): 800x600@60Hz (II) RADEON(0): 800x600@75Hz (II) RADEON(0): 832x624@75Hz (II) RADEON(0): 1024x768@60Hz (II) RADEON(0): 1024x768@75Hz (II) RADEON(0): 1280x1024@75Hz (II) RADEON(0): 1152x870@75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported standard timings: (II) RADEON(0): #0: hsize: 640 vsize 480 refresh: 75 vid: 20273 (II) RADEON(0): #1: hsize: 800 vsize 600 refresh: 75 vid: 20293 (II) RADEON(0): #2: hsize: 1024 vsize 768 refresh: 75 vid: 20321 (II) RADEON(0): #3: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): Supported detailed timing: (II) RADEON(0): clock: 108.0 MHz Image Size: 376 x 301 mm (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 83 kHz, PixClock max 140 MHz (II) RADEON(0): Monitor name: L1910S (II) RADEON(0): Monitor name: (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff001e6d784a87180100 (II) RADEON(0): 020f01036e261e78eaec50a5584a9a26 (II) RADEON(0): 215054a56b80314f454f614f81800101 (II) RADEON(0): 010101010101302a009851002a403070 (II) RADEON(0): 1300782d1100001e000000fd00384b1e (II) RADEON(0): 530e000a202020202020000000fc004c (II) RADEON(0): 3139313053200a2020202020000000fc (II) RADEON(0): 000a20202020202020202020202000d8 (II) RADEON(0): EDID vendor "GSM", prod id 19064 Output CRT1 disable success Blank CRTC 0 success Disable CRTC 0 success Disable CRTC memreq 0 success Blank CRTC 1 success Disable CRTC 1 success Disable CRTC memreq 1 success (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ff00e0 0x00ef00d0 (II) RADEON(0): MC_AGP_LOCATION : 0x00000000 (II) RADEON(0): avivo_restore ! Enable CRTC memreq 0 success Enable CRTC 0 success Unblank CRTC 0 success (==) RADEON(0): Write-combining range (0xa0000,0x10000) was already clear (II) UnloadModule: "kbd" (II) UnloadModule: "mouse" (II) UnloadModule: "kbd" (II) UnloadModule: "mouse" From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 19:39:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52A701065693 for ; Sat, 13 Feb 2010 19:39:14 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 37D568FC2A for ; Sat, 13 Feb 2010 19:39:13 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta13.emeryville.ca.mail.comcast.net with comcast id hVp81d0081Y3wxoADXfErW; Sat, 13 Feb 2010 19:39:14 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id hXfD1d00D3S48mS8bXfERP; Sat, 13 Feb 2010 19:39:14 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id AB4081E301B; Sat, 13 Feb 2010 11:39:12 -0800 (PST) Date: Sat, 13 Feb 2010 11:39:12 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100213193912.GA4894@icarus.home.lan> References: <4B759E70.4030809@comcast.net> <4B75ADC7.6000308@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ZFS ARC being limited below what is defined in /boot/loader.conf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 19:39:14 -0000 On Fri, Feb 12, 2010 at 01:10:51PM -0800, Artem Belevich wrote: > vm.kmem_size_max/vm.kmem_size_min define the range vm.kmem_size can be set to. > vm_kmem_size specifies the actual kmem size. > > ARC size in turn limited by vm.kmem_size. > > If you want to bump ARC size, you do need to bump vm.kmem_size. > > --Artem > > On Fri, Feb 12, 2010 at 11:36 AM, Steve Polyack wrote: > > On 02/12/10 13:47, Artem Belevich wrote: > >> > >> On Fri, Feb 12, 2010 at 10:31 AM, Steve Polyack > >>  wrote: > >> > >> > >>> > >>> Has anyone had an issue with the ZFS ARC max being limited below what has > >>> been defined in /boot/loader.conf?  I just upgraded the RAM in a > >>> ZFS-equipped system and attempted to devote 4GB to the ARC cache by > >>> placing > >>> the following in loader.conf: > >>>  vfs.zfs.arc_max="4096M" > >>> > >>> However, after rebooting, querying the sysctl gives me this: > >>> $ sysctl vfs.zfs.arc_max > >>> vfs.zfs.arc_max: 1726489600 > >>> > >>> or about 1.7GB, an odd number that I can't find any references to.  For > >>> reference, I'm running 8-STABLE (as of Jan 19th) on an amd64 system with > >>> 8GB > >>> of RAM.  The system was previously very stable with 4GB of RAM and a > >>> 512MB > >>> arc_max.  I have not modified vm.kmem_size_max (defaults to ~330GB on > >>> amd64) > >>> or any other ZFS tunables.  I'd also like to avoid syncing up to the > >>> current > >>> 8-STABLE if at all possible. > >>> > >>> Thanks, > >>> Steve Polyack > >>> > >>> _______________________________________________ > >>> 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" > >>> > >>> > >> > >> Check your vm.kmem_size. Default setting is way too low. Set it to at > >> least double of desired arc size. > >> > >> --Artem > > > > I mentioned it briefly, but vm.kmem_size_max was left at the default for > > amd64.  At 330GB it is way above and beyond what will ever be allocated to > > ARC: > > $ sysctl vm.kmem_size_max > > vm.kmem_size_max: 329853485875 I'm concerned about adjusting vm.kmem_size, since vm.kmem_size_max is supposed to be auto-adjusting as of this point in time. How does adjusting vm.kmem_size affect things like kern.maxdsiz, kern.dfldsiz, and kern.maxssiz? These tunings are required for things like userland apps which require a large amount of memory (read: mysqld). The amount of VM-related tunables requiring is getting out of hand. We need documentation of some sort, outlining how all these things fit together as to avoid potential kernel panics or memory exhaustion issues; for example, people with 8GB of RAM installed who utilise both ZFS on the server in addition to a memory-hungry mysqld. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 20:04:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14D6A106568F; Sat, 13 Feb 2010 20:04:33 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 954048FC0A; Sat, 13 Feb 2010 20:04:32 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 8so201701qwh.7 for ; Sat, 13 Feb 2010 12:04:31 -0800 (PST) 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=WsJM2XfT97V0dGFyC597g24F94X/Dyuish0k6wDG8ps=; b=W61QWICxTJUM31deQLmH/hVeQR27vXJo+6cBALS24Y3wp6zqY87dVKeq63GShJ1inl +nbSsqQDK45sjNL4TPRce5zSv8p1kvV6AQ4N7axjbPdc4l/fmWPXyKUtk70pabG9vrnd l8gSoY51QubJ2g01VZEM9TgXu+vLnQV8WrLqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JXxyGO38fTB1b/m8Gy47s+7VxYonlFuhgEu6P5lS/xOAZPrWUuA1wqiDufqJR4x7/V 1ihbrTBE0S5GRZsyx7VsYxIpIttsAB04QvT6YlCYp8q/1iI+38wbO3uWFbLQwlXXSr/L 39B8WYhEfCP/hDF3dxfPWFNY9/CngU6BCI4rM= MIME-Version: 1.0 Received: by 10.224.95.154 with SMTP id d26mr1496260qan.108.1266091471753; Sat, 13 Feb 2010 12:04:31 -0800 (PST) Date: Sat, 13 Feb 2010 22:04:31 +0200 Message-ID: From: Dan Naumov To: freebsd-questions@freebsd.org, freebsd-fs@freebsd.org, FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: booting off a ZFS pool consisting of multiple striped mirror vdevs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 20:04:33 -0000 Hello I have succesfully tested and used a "full ZFS install" of FreeBSD 8.0 on both single disk and mirror disk configurations using both MBR and GPT partitioning. AFAIK, with the more recent -CURRENT and -STABLE it is also possible to boot off a root filesystem located on raidz/raidz2 pools. But what about booting off pools consisting of multiple striped mirror or raidz vdevs? Like this: Assume each disk looks like a half of a traditional ZFS mirror root configuration using GPT 1: freebsd-boot 2: freebsd-swap 3: freebsd-zfs |disk1+disk2| + |disk3+disk4| + |disk5+disk6| My logic tells me that while booting off any of the 6 disks, boot0 and boot1 stage should obviously work fine, but what about the boot2 stage? Can it properly handle booting off a root filesystem thats striped across 3 mirror vdevs or is booting off a single mirror vdev the best that one can do right now? - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 20:25:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B0CC106566C for ; Sat, 13 Feb 2010 20:25:31 +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 6C9888FC17 for ; Sat, 13 Feb 2010 20:25:30 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-37.bna.bellsouth.net [74.241.172.37]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1DKPFXE035048 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 13 Feb 2010 15:25:18 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Norbert Papke In-Reply-To: <201002131137.34812.npapke@acm.org> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <20100211074933.GJ9748@acme.spoerlein.net> <1266080709.89452.21.camel@balrog.2hip.net> <201002131137.34812.npapke@acm.org> Content-Type: text/plain Organization: FreeBSD Date: Sat, 13 Feb 2010 14:25:10 -0600 Message-Id: <1266092710.89452.29.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX,RCVD_IN_PBL,RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 20:25:31 -0000 On Sat, 2010-02-13 at 11:37 -0800, Norbert Papke wrote: > On February 13, 2010, Robert Noland wrote: > > Ok, I've put up a patch at: > > > > http://people.freebsd.org/~rnoland/drm-radeon-test.patch > > > > This is sort of a mega patch and includes: > > > > Re-worked drm mapping code, that ensures that we don't end up > > incorrectly mapping certain maps with overlapping offsets. This > > generally shows up as the ring buffer not being cleared (contents != 0 > > in xorg.log) which leads to corruption and other bad behavior. > > > > Re-written scatter gather allocation code. This interacts directly with > > the VM system, rather than using bus_dma to allow us to grab > > non-contiguous pages for the scatter gather backing of the GART. It > > also makes it easier to handle the caching mode of the backing pages. > > > > Disable cache snooping on radeon cards, since we have write combining > > set properly now. > > > > I have at least done a test build on -CURRENT with this patch, but I > > haven't had time to do much else without the rest of the code in my > > tree. I've been running most all of this code for a month or two now at > > least, so it is mostly just a question of whether or not I got all of > > the conflicts sorted out properly when I made this patch. > > > > The re-mapping code has the most widespread impact and has been tested > > on radeon r600 amd64, intel g45 i386 and mga amd64. > > > > robert. > > I tweaked the patch and applied it to 8-STABLE. It has improved things. I no > longer hang when starting X but DRI still does not work. I also > intermittently experience the interrupt problem where the screen does not > update unless I wiggle the mouse. > > It is entirely possible that I messed up adapting the patch for 8-STABLE. I > did the following: > > * applied SVN 203287 and 203287 for VIA support > * applied your patch > * reverted drm_vm.c because it is dependent on r201223 (Update d_mmap() to > accept vm_ooffset_t and vm_memattr_t.) Ah, on 8 it just needs to use d_mmap2. That is only a couple of line change. IIRC, just change d_mmap to d_mmap2 in drm_drv.c and change the declaration of drm_mmap to the correct type. d_mmap2 in 8 is the same as d_mmap in HEAD. > * re-enabled snooping in ati_pcigart.c and r600_cp.c > > I have appended my xorg.0.log file. Perhaps something in there stands out as > red flag? (II) [drm] Mapping SAREA for DRM lock failed. (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. Hrm... That shouldn't happen... but I'm not sure if I missed something in the patch or if it hasn't applied correctly to 8.... robert. > Thank you for all the time you put into this. > > Cheers, > > -- Norbert Papke. > npapke@acm.org > > > > X.Org X Server 1.6.5 > Release Date: 2009-10-11 > X Protocol Version 11, Revision 0 > Build Operating System: FreeBSD 8.0-STABLE amd64 > Current Operating System: FreeBSD proven.lan.provenpath.ca 8.0-STABLE FreeBSD > 8.0-STABLE #36 r203841M: Sat Feb 13 10:50:20 PST 2010 > npapke@proven.lan.provenpath.ca:/usr/obj/red/usr/public/freebsd/sources/stable8/sys/PROVEN > amd64 > Build Date: 10 February 2010 06:25:15PM > > 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: Sat Feb 13 10:55:30 2010 > (==) Using config file: "/etc/X11/xorg.conf" > (==) ServerLayout "X.org Configured" > (**) |-->Screen "Screen0" (0) > (**) | |-->Monitor "LG" > (**) | |-->Device "Card0" > (**) Option "DontZap" "off" > (**) Option "BlankTime" "15" > (**) Option "StandbyTime" "120" > (**) Option "SuspendTime" "150" > (**) Option "OffTime" "180" > (**) Option "AIGLX" "on" > (**) Option "AllowEmptyInput" "false" > (==) Automatically adding devices > (==) Automatically enabling devices > (WW) `fonts.dir' not found (or not valid) in "/usr/local/share/fonts/". > Entry deleted from font path. > (Run 'mkfontdir' on "/usr/local/share/fonts/"). > (WW) `fonts.dir' not found (or not valid) in > "/usr/local/share/fonts/cmpsfont". > Entry deleted from font path. > (Run 'mkfontdir' on "/usr/local/share/fonts/cmpsfont"). > (WW) `fonts.dir' not found (or not valid) in > "/usr/local/share/fonts/amspsfont". > Entry deleted from font path. > (Run 'mkfontdir' on "/usr/local/share/fonts/amspsfont"). > (**) FontPath set to: > /usr/local/lib/X11/fonts/bitstream-vera/, > /usr/local/lib/X11/fonts/dejavu/, > /usr/local/lib/X11/fonts/misc/, > /usr/local/lib/X11/fonts/TrueType/, > /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/webfonts/, > /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" > (**) Extension "Composite" is enabled > (==) |-->Input Device "" > (==) |-->Input Device "" > (==) The core pointer device wasn't specified explicitly in the layout. > Using the default mouse configuration. > (==) The core keyboard device wasn't specified explicitly in the layout. > Using the default keyboard configuration. > (II) Loader magic: 0x3f60 > (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 9 > > (--) PCI:*(0:1:0:0) 1002:9598:1043:01e4 ATI Technologies Inc Mobility Radeon > HD 3600 Series 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) LoadModule: "extmod" > (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so > (II) Module extmod: vendor="X.Org Foundation" > compiled for 1.6.5, 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 XFree86-DGA > (II) Loading extension DPMS > (II) Loading extension XVideo > (II) Loading extension XVideo-MotionCompensation > (II) Loading extension X-Resource > (II) LoadModule: "dbe" > (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so > (II) Module dbe: vendor="X.Org Foundation" > compiled for 1.6.5, 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: "glx" > (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so > (II) Module glx: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 1.0.0 > ABI class: X.Org Server Extension, version 2.0 > (**) AIGLX enabled > (II) Loading extension GLX > (II) LoadModule: "record" > (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so > (II) Module record: vendor="X.Org Foundation" > compiled for 1.6.5, 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: "dri" > (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so > (II) Module dri: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 1.0.0 > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension XFree86-DRI > (II) LoadModule: "dri2" > (II) Loading /usr/local/lib/xorg/modules/extensions//libdri2.so > (II) Module dri2: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 1.1.0 > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension DRI2 > (II) LoadModule: "ati" > (II) Loading /usr/local/lib/xorg/modules/drivers//ati_drv.so > (II) Module ati: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 6.12.4 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 5.0 > (II) LoadModule: "radeon" > (II) Loading /usr/local/lib/xorg/modules/drivers//radeon_drv.so > (II) Module radeon: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 6.12.4 > 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.5, 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.5, module version = 1.3.2 > Module class: X.Org XInput Driver > ABI class: X.Org XInput driver, version 4.0 > (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 X800 VE (R420) JT (AGP), ATI Radeon X850 (R480) (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 Radeon HD 4850 x2, > 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 Radeon 4800 Series, ATI Radeon 4800 Series, ATI FirePro M7750, > ATI M98, ATI M98, ATI M98, ATI Mobility Radeon HD 4650, > ATI Radeon RV730 (AGP), ATI Mobility Radeon HD 4670, > ATI FirePro M5750, ATI Radeon RV730 (AGP), > ATI RV730XT [Radeon HD 4670], ATI RADEON E4600, > ATI Radeon HD 4600 Series, ATI RV730 PRO [Radeon HD 4650], > ATI FirePro V7750 (FireGL), ATI FirePro V5700 (FireGL), > ATI FirePro V3750 (FireGL), ATI Mobility Radeon HD 4830, > ATI Mobility Radeon HD 4850, ATI FirePro M7740, ATI RV740, > ATI Radeon HD 4770, ATI Radeon HD 4700 Series, ATI Radeon HD 4770, > ATI FirePro M5750, 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 FirePro RG220, 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, > ATI Radeon HD 3200 Graphics, ATI Radeon 3000 Graphics, > ATI Radeon HD 4200, ATI Radeon 4100, ATI Mobility Radeon HD 4200, > ATI Mobility Radeon 4100, ATI RS880 > (II) Primary Device is: PCI 01@00:00:0 > (II) resource ranges after xf86ClaimFixedResources() call: > [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) 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] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] > [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] > [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] > [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] > [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] > (II) Setting vga for screen 0. > (II) RADEON(0): TOTO SAYS 00000000fe9e0000 > (II) RADEON(0): MMIO registers at 0x00000000fe9e0000: size 64KB > (II) RADEON(0): PCI bus 1 card 0 func 0 > (**) RADEON(0): Depth 24, (--) framebuffer bpp 32 > (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) > (==) RADEON(0): Default visual is TrueColor > (**) RADEON(0): Option "AccelMethod" "exa" > (II) Loading sub module "vgahw" > (II) LoadModule: "vgahw" > (II) Loading /usr/local/lib/xorg/modules//libvgahw.so > (II) Module vgahw: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 0.1.0 > ABI class: X.Org Video Driver, version 5.0 > (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is > 0x0000 > (==) RADEON(0): RGB weight 888 > (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) > (--) RADEON(0): Chipset: "ATI Radeon HD 3600 XT" (ChipID = 0x9598) > (--) RADEON(0): Linear framebuffer at 0x00000000d0000000 > (II) RADEON(0): PCIE card detected > (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.5, module version = 1.0.0 > ABI class: X.Org Video Driver, version 5.0 > (II) RADEON(0): initializing int10 > (==) RADEON(0): Write-combining range (0xa0000,0x20000) was already clear > (==) RADEON(0): Write-combining range (0xc0000,0x40000) was already clear > (II) RADEON(0): Primary V_BIOS segment is: 0xc000 > (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear > (II) RADEON(0): ATOM BIOS detected > (II) RADEON(0): ATOM BIOS Rom: > SubsystemVendorID: 0x1043 SubsystemID: 0x01e4 > IOBaseAddress: 0xc000 > Filename: SV27381.bin > BIOS Bootup Message: > 9598.10.74.0.1.AS01 > > (II) RADEON(0): Framebuffer space used by Firmware (kb): 16 > (II) RADEON(0): Start of VRAM area used by Firmware: 0x1fffc000 > (II) RADEON(0): AtomBIOS requests 16kB of VRAM scratch space > (II) RADEON(0): AtomBIOS VRAM scratch base: 0x1fffc000 > (II) RADEON(0): Cannot get VRAM scratch space. Allocating in main memory > instead > (II) RADEON(0): Default Engine Clock: 725000 > (II) RADEON(0): Default Memory Clock: 700000 > (II) RADEON(0): Maximum Pixel ClockPLL Frequency Output: 1200000 > (II) RADEON(0): Minimum Pixel ClockPLL Frequency Output: 0 > (II) RADEON(0): Maximum Pixel ClockPLL Frequency Input: 13500 > (II) RADEON(0): Minimum Pixel ClockPLL Frequency Input: 1000 > (II) RADEON(0): Maximum Pixel Clock: 400000 > (II) RADEON(0): Reference Clock: 27000 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: Searching for BusID pci:0000:01:00.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: drmOpenMinor returns 10 > drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 > (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module > version 1.31.0 > (==) RADEON(0): Page Flipping disabled on r5xx and newer chips. > > (II) RADEON(0): Will try to use DMA for Xv image transfers > (II) RADEON(0): Detected total video RAM=524288K, accessible=262144K (PCI > BAR=262144K) > (--) RADEON(0): Mapped VideoRAM: 262144 kByte (128 bit DDR SDRAM) > (II) RADEON(0): Color tiling disabled > (II) Loading sub module "ddc" > (II) LoadModule: "ddc" > (II) Module "ddc" already built-in > (II) Loading sub module "i2c" > (II) LoadModule: "i2c" > (II) Module "i2c" already built-in > (II) RADEON(0): ref_freq: 2700, min_out_pll: 64800, max_out_pll: 120000, > min_in_pll: 100, max_in_pll: 1350, xclk: 40000, sclk: 725.000000, mclk: > 700.000000 > (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=64800 max=120000; xclk=40000 > Shared DDC line: 1 4 > Shared DDC line: 1 5 > Shared DDC line: 4 1 > (II) RADEON(0): Output HDMI-0 using monitor section LG > (II) RADEON(0): I2C bus "HDMI-0" initialized. > (II) RADEON(0): Output VGA-0 has no monitor section > (II) RADEON(0): I2C bus "VGA-0" initialized. > (II) RADEON(0): Output DVI-0 has no monitor section > (II) RADEON(0): I2C bus "DVI-0" initialized. > (II) RADEON(0): Port0: > XRANDR name: HDMI-0 > Connector: HDMI-A > DFP1: INTERNAL_UNIPHY > DDC reg: 0x7e50 > (II) RADEON(0): Port1: > XRANDR name: VGA-0 > Connector: VGA > CRT2: INTERNAL_KLDSCP_DAC2 > DDC reg: 0x7e50 > (II) RADEON(0): Port2: > XRANDR name: DVI-0 > Connector: DVI-I > CRT1: INTERNAL_KLDSCP_DAC1 > DFP2: INTERNAL_KLDSCP_LVTMA > DDC reg: 0x7e40 > (II) RADEON(0): I2C device "HDMI-0:E-EDID segment register" registered at > address 0x60. > (II) RADEON(0): I2C device "HDMI-0:ddc2" registered at address 0xA0. > (II) RADEON(0): Output: HDMI-0, Detected Monitor Type: 0 > finished output detect: 0 > (II) RADEON(0): I2C device "VGA-0:E-EDID segment register" registered at > address 0x60. > (II) RADEON(0): I2C device "VGA-0:ddc2" registered at address 0xA0. > Dac detection success > (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 > finished output detect: 1 > (II) RADEON(0): I2C device "DVI-0:E-EDID segment register" registered at > address 0x60. > (II) RADEON(0): I2C device "DVI-0:ddc2" registered at address 0xA0. > (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 1 > (II) RADEON(0): EDID data from the display on output: DVI-0 > ---------------------- > (II) RADEON(0): Manufacturer: GSM Model: 4a78 Serial#: 71815 > (II) RADEON(0): Year: 2005 Week: 2 > (II) RADEON(0): EDID Version: 1.3 > (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V > (II) RADEON(0): Sync: Separate Composite SyncOnGreen > (II) RADEON(0): Max Image Size [cm]: horiz.: 38 vert.: 30 > (II) RADEON(0): Gamma: 2.20 > (II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display > (II) RADEON(0): First detailed timing is preferred mode > (II) RADEON(0): redX: 0.647 redY: 0.346 greenX: 0.292 greenY: 0.602 > (II) RADEON(0): blueX: 0.149 blueY: 0.130 whiteX: 0.312 whiteY: 0.328 > (II) RADEON(0): Supported established timings: > (II) RADEON(0): 720x400@70Hz > (II) RADEON(0): 640x480@60Hz > (II) RADEON(0): 640x480@75Hz > (II) RADEON(0): 800x600@60Hz > (II) RADEON(0): 800x600@75Hz > (II) RADEON(0): 832x624@75Hz > (II) RADEON(0): 1024x768@60Hz > (II) RADEON(0): 1024x768@75Hz > (II) RADEON(0): 1280x1024@75Hz > (II) RADEON(0): 1152x870@75Hz > (II) RADEON(0): Manufacturer's mask: 0 > (II) RADEON(0): Supported standard timings: > (II) RADEON(0): #0: hsize: 640 vsize 480 refresh: 75 vid: 20273 > (II) RADEON(0): #1: hsize: 800 vsize 600 refresh: 75 vid: 20293 > (II) RADEON(0): #2: hsize: 1024 vsize 768 refresh: 75 vid: 20321 > (II) RADEON(0): #3: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 > (II) RADEON(0): Supported detailed timing: > (II) RADEON(0): clock: 108.0 MHz Image Size: 376 x 301 mm > (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 > h_border: 0 > (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 > v_border: 0 > (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 83 kHz, > PixClock max 140 MHz > (II) RADEON(0): Monitor name: L1910S > (II) RADEON(0): Monitor name: > (II) RADEON(0): EDID (in hex): > (II) RADEON(0): 00ffffffffffff001e6d784a87180100 > (II) RADEON(0): 020f01036e261e78eaec50a5584a9a26 > (II) RADEON(0): 215054a56b80314f454f614f81800101 > (II) RADEON(0): 010101010101302a009851002a403070 > (II) RADEON(0): 1300782d1100001e000000fd00384b1e > (II) RADEON(0): 530e000a202020202020000000fc004c > (II) RADEON(0): 3139313053200a2020202020000000fc > (II) RADEON(0): 000a20202020202020202020202000d8 > finished output detect: 2 > finished all detect > before xf86InitialConfiguration > (II) RADEON(0): Output: HDMI-0, Detected Monitor Type: 0 > Dac detection success > (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 > (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 1 > (II) RADEON(0): EDID data from the display on output: DVI-0 > ---------------------- > (II) RADEON(0): Manufacturer: GSM Model: 4a78 Serial#: 71815 > (II) RADEON(0): Year: 2005 Week: 2 > (II) RADEON(0): EDID Version: 1.3 > (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V > (II) RADEON(0): Sync: Separate Composite SyncOnGreen > (II) RADEON(0): Max Image Size [cm]: horiz.: 38 vert.: 30 > (II) RADEON(0): Gamma: 2.20 > (II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display > (II) RADEON(0): First detailed timing is preferred mode > (II) RADEON(0): redX: 0.647 redY: 0.346 greenX: 0.292 greenY: 0.602 > (II) RADEON(0): blueX: 0.149 blueY: 0.130 whiteX: 0.312 whiteY: 0.328 > (II) RADEON(0): Supported established timings: > (II) RADEON(0): 720x400@70Hz > (II) RADEON(0): 640x480@60Hz > (II) RADEON(0): 640x480@75Hz > (II) RADEON(0): 800x600@60Hz > (II) RADEON(0): 800x600@75Hz > (II) RADEON(0): 832x624@75Hz > (II) RADEON(0): 1024x768@60Hz > (II) RADEON(0): 1024x768@75Hz > (II) RADEON(0): 1280x1024@75Hz > (II) RADEON(0): 1152x870@75Hz > (II) RADEON(0): Manufacturer's mask: 0 > (II) RADEON(0): Supported standard timings: > (II) RADEON(0): #0: hsize: 640 vsize 480 refresh: 75 vid: 20273 > (II) RADEON(0): #1: hsize: 800 vsize 600 refresh: 75 vid: 20293 > (II) RADEON(0): #2: hsize: 1024 vsize 768 refresh: 75 vid: 20321 > (II) RADEON(0): #3: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 > (II) RADEON(0): Supported detailed timing: > (II) RADEON(0): clock: 108.0 MHz Image Size: 376 x 301 mm > (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 > h_border: 0 > (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 > v_border: 0 > (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 83 kHz, > PixClock max 140 MHz > (II) RADEON(0): Monitor name: L1910S > (II) RADEON(0): Monitor name: > (II) RADEON(0): EDID (in hex): > (II) RADEON(0): 00ffffffffffff001e6d784a87180100 > (II) RADEON(0): 020f01036e261e78eaec50a5584a9a26 > (II) RADEON(0): 215054a56b80314f454f614f81800101 > (II) RADEON(0): 010101010101302a009851002a403070 > (II) RADEON(0): 1300782d1100001e000000fd00384b1e > (II) RADEON(0): 530e000a202020202020000000fc004c > (II) RADEON(0): 3139313053200a2020202020000000fc > (II) RADEON(0): 000a20202020202020202020202000d8 > (II) RADEON(0): EDID vendor "GSM", prod id 19064 > (II) RADEON(0): Output HDMI-0 disconnected > (II) RADEON(0): Output VGA-0 disconnected > (II) RADEON(0): Output DVI-0 connected > (II) RADEON(0): Using user preference for initial modes > (II) RADEON(0): Output DVI-0 using initial mode 1280x1024 > after xf86InitialConfiguration > (==) RADEON(0): DPI set to (96, 96) > (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.5, module version = 1.0.0 > ABI class: X.Org ANSI C Emulation, version 0.4 > (==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0) > (II) Loading sub module "ramdac" > (II) LoadModule: "ramdac" > (II) Module "ramdac" already built-in > (==) RADEON(0): Will attempt to use R6xx/R7xx EXA support if DRI is enabled. > (II) Loading sub module "exa" > (II) LoadModule: "exa" > (II) Loading /usr/local/lib/xorg/modules//libexa.so > (II) Module exa: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 2.4.0 > ABI class: X.Org Video Driver, version 5.0 > (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear > (!!) RADEON(0): For information on using the multimedia capabilities > of this adapter, please see http://gatos.sf.net. > (!!) RADEON(0): MergedFB support has been removed and replaced with xrandr 1.2 > support > (--) 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] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] > [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] > [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] > [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] > [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] > (II) RADEON(0): RADEONScreenInit d0000000 0 0 > (==) RADEON(0): Write-combining range (0xa0000,0x10000) was already clear > Output CRT1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Disable CRTC memreq 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Disable CRTC memreq 1 success > (==) RADEON(0): Using 24 bit depth buffer > mc fb loc is 00ef00d0 > (II) RADEON(0): RADEONInitMemoryMap() : > (II) RADEON(0): mem_size : 0x20000000 > (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > (II) RADEON(0): Depth moves disabled by default > (II) RADEON(0): Allocating from a screen of 262080 kb > (II) RADEON(0): Will use 32 kb for hardware cursor 0 at offset 0x00640000 > (II) RADEON(0): Will use 32 kb for hardware cursor 1 at offset 0x00644000 > (II) RADEON(0): Will use 6400 kb for front buffer at offset 0x00000000 > (II) RADEON(0): Will use 64 kb for PCI GART at offset 0x0fff0000 > (II) RADEON(0): Will use 6400 kb for back buffer at offset 0x00648000 > (II) RADEON(0): Will use 6400 kb for depth buffer at offset 0x00c88000 > (II) RADEON(0): Will use 120832 kb for textures at offset 0x012c8000 > (II) RADEON(0): Will use 122016 kb for X Server offscreen at offset 0x088c8000 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: Searching for BusID pci:0000:01:00.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: drmOpenMinor returns 10 > drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 > (II) [drm] DRM interface version 1.2 > (II) [drm] Mapping SAREA for DRM lock failed. > (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ff00e0 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > (==) RADEON(0): Backing store disabled > (WW) RADEON(0): Direct rendering disabled > (EE) RADEON(0): Acceleration initialization failed > (II) RADEON(0): Acceleration disabled > (**) Option "dpms" > (**) RADEON(0): DPMS enabled > (==) RADEON(0): Silken mouse enabled > (II) RADEON(0): Textured video requires CP on R5xx/R6xx/R7xx/IGP > (II) RADEON(0): DIG0 transmitter: Coherent Mode enabled > Output DIG0 transmitter setup success > Output CRT2 disable success > Output CRT1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Disable CRTC memreq 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Disable CRTC memreq 1 success > Output CRT1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Disable CRTC memreq 0 success > Mode 1280x1024 - 1688 1066 5 > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > freq: 108000000 > best_freq: 108000000 > best_feedback_div: 48 > best_ref_div: 2 > best_post_div: 6 > (II) RADEON(0): crtc(0) Clock: mode 108000, PLL 108000 > (II) RADEON(0): crtc(0) PLL : refdiv 2, fbdiv 0x30(48), pdiv 6 > Set CRTC 0 PLL success > Set CRTC Timing success > Set CRTC 0 Overscan success > Not using RMX > scaler 0 setup success > Set CRTC 0 Source success > crtc 0 YUV disable setup success > Output DAC1 setup success > Output CRT1 enable success > Enable CRTC memreq 0 success > Enable CRTC 0 success > Unblank CRTC 0 success > (II) RADEON(0): DIG0 transmitter: Coherent Mode enabled > Output DIG0 transmitter setup success > Output CRT2 disable success > Blank CRTC 1 success > Disable CRTC 1 success > Disable CRTC memreq 1 success > (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled > message. > Output CRT1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Disable CRTC memreq 0 success > Mode 1280x1024 - 1688 1066 5 > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > freq: 108000000 > best_freq: 108000000 > best_feedback_div: 48 > best_ref_div: 2 > best_post_div: 6 > (II) RADEON(0): crtc(0) Clock: mode 108000, PLL 108000 > (II) RADEON(0): crtc(0) PLL : refdiv 2, fbdiv 0x30(48), pdiv 6 > Set CRTC 0 PLL success > Set CRTC Timing success > Set CRTC 0 Overscan success > Not using RMX > scaler 0 setup success > Set CRTC 0 Source success > crtc 0 YUV disable setup success > Output DAC1 setup success > Output CRT1 enable success > Enable CRTC memreq 0 success > Enable CRTC 0 success > Unblank CRTC 0 success > (--) RandR disabled > (II) Setting vga for screen 0. > (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: Screen 0 is not DRI2 capable > (II) AIGLX: Screen 0 is not DRI capable > (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so > (II) GLX: Initialized DRISWRAST GL provider for screen 0 > (II) RADEON(0): Setting screen physical size to 376 x 301 > (WW) : No Device specified, looking for one... > (II) : Setting Device option to "/dev/sysmouse" > (--) : Device: "/dev/sysmouse" > (==) : Protocol: "Auto" > (**) Option "CorePointer" > (**) : always reports core events > (==) : Emulate3Buttons, Emulate3Timeout: 50 > (**) : ZAxisMapping: buttons 4 and 5 > (**) : Buttons: 9 > (**) : Sensitivity: 1 > (II) XINPUT: Adding extended input device "" (type: MOUSE) > (**) : (accel) keeping acceleration scheme 1 > (**) : (accel) filter chain progression: 2.00 > (**) : (accel) filter stage 0: 20.00 ms > (**) : (accel) set acceleration profile 0 > (II) : SetupAuto: hw.iftype is 4, hw.model is 0 > (II) : SetupAuto: protocol is SysMouse > (**) Option "CoreKeyboard" > (**) : always reports core events > (**) Option "Protocol" "standard" > (**) : Protocol: standard > (**) Option "AutoRepeat" "500 30" > (**) Option "XkbRules" "xorg" > (**) : XkbRules: "xorg" > (**) Option "XkbModel" "pc105" > (**) : XkbModel: "pc105" > (**) Option "XkbLayout" "us" > (**) : XkbLayout: "us" > (**) Option "CustomKeycodes" "off" > (**) : CustomKeycodes disabled > (II) XINPUT: Adding extended input device "" (type: > KEYBOARD) > (II) config/hal: Adding input device USB-PS/2 Optical Mouse > (**) USB-PS/2 Optical Mouse: Device: "/dev/sysmouse" > (==) USB-PS/2 Optical Mouse: Protocol: "Auto" > (**) USB-PS/2 Optical Mouse: always reports core events > (**) Option "Device" "/dev/sysmouse" > (==) USB-PS/2 Optical Mouse: Emulate3Buttons, Emulate3Timeout: 50 > (**) USB-PS/2 Optical Mouse: ZAxisMapping: buttons 4 and 5 > (**) USB-PS/2 Optical Mouse: Buttons: 9 > (**) USB-PS/2 Optical Mouse: Sensitivity: 1 > (II) XINPUT: Adding extended input device "USB-PS/2 Optical Mouse" (type: > MOUSE) > (**) USB-PS/2 Optical Mouse: (accel) keeping acceleration scheme 1 > (**) USB-PS/2 Optical Mouse: (accel) filter chain progression: 2.00 > (**) USB-PS/2 Optical Mouse: (accel) filter stage 0: 20.00 ms > (**) USB-PS/2 Optical Mouse: (accel) set acceleration profile 0 > (II) USB-PS/2 Optical Mouse: SetupAuto: hw.iftype is 4, hw.model is 0 > (II) USB-PS/2 Optical Mouse: SetupAuto: protocol is SysMouse > (II) config/hal: Adding input device AT Keyboard > (**) AT Keyboard: always reports core events > (**) Option "Protocol" "standard" > (**) AT Keyboard: Protocol: standard > (**) Option "AutoRepeat" "500 30" > (**) Option "XkbRules" "xorg" > (**) AT Keyboard: XkbRules: "xorg" > (**) Option "XkbModel" "pc105" > (**) AT Keyboard: XkbModel: "pc105" > (**) Option "XkbLayout" "us" > (**) AT Keyboard: XkbLayout: "us" > (**) Option "XkbOptions" "terminate:ctrl_alt_bksp" > (**) AT Keyboard: XkbOptions: "terminate:ctrl_alt_bksp" > (**) Option "CustomKeycodes" "off" > (**) AT Keyboard: CustomKeycodes disabled > (II) XINPUT: Adding extended input device "AT Keyboard" (type: KEYBOARD) > (II) RADEON(0): Output: HDMI-0, Detected Monitor Type: 0 > Dac detection success > (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 > (II) RADEON(0): EDID vendor "GSM", prod id 19064 > (II) RADEON(0): Using EDID range info for horizontal sync > (II) RADEON(0): Using EDID range info for vertical refresh > (II) RADEON(0): Printing DDC gathered Modelines: > (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 > 1025 1028 1066 +hsync +vsync (64.0 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 > 628 +hsync +vsync (37.9 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 > 500 -hsync -vsync (37.5 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 > 525 -hsync -vsync (31.5 kHz) > (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 > 449 -hsync +vsync (31.5 kHz) > (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 > 1025 1028 1066 +hsync +vsync (80.0 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 > 772 800 +hsync +vsync (60.0 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 > 777 806 -hsync -vsync (48.4 kHz) > (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 > 667 -hsync -vsync (49.7 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 > 625 +hsync +vsync (46.9 kHz) > (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 > 868 900 +hsync +vsync (67.5 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 > 500 -hsync -vsync (37.5 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 > 625 +hsync +vsync (46.9 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 > 772 800 +hsync +vsync (60.0 kHz) > (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 > 1025 1028 1066 +hsync +vsync (64.0 kHz) > (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 1 > (II) RADEON(0): EDID data from the display on output: DVI-0 > ---------------------- > (II) RADEON(0): Manufacturer: GSM Model: 4a78 Serial#: 71815 > (II) RADEON(0): Year: 2005 Week: 2 > (II) RADEON(0): EDID Version: 1.3 > (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V > (II) RADEON(0): Sync: Separate Composite SyncOnGreen > (II) RADEON(0): Max Image Size [cm]: horiz.: 38 vert.: 30 > (II) RADEON(0): Gamma: 2.20 > (II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display > (II) RADEON(0): First detailed timing is preferred mode > (II) RADEON(0): redX: 0.647 redY: 0.346 greenX: 0.292 greenY: 0.602 > (II) RADEON(0): blueX: 0.149 blueY: 0.130 whiteX: 0.312 whiteY: 0.328 > (II) RADEON(0): Supported established timings: > (II) RADEON(0): 720x400@70Hz > (II) RADEON(0): 640x480@60Hz > (II) RADEON(0): 640x480@75Hz > (II) RADEON(0): 800x600@60Hz > (II) RADEON(0): 800x600@75Hz > (II) RADEON(0): 832x624@75Hz > (II) RADEON(0): 1024x768@60Hz > (II) RADEON(0): 1024x768@75Hz > (II) RADEON(0): 1280x1024@75Hz > (II) RADEON(0): 1152x870@75Hz > (II) RADEON(0): Manufacturer's mask: 0 > (II) RADEON(0): Supported standard timings: > (II) RADEON(0): #0: hsize: 640 vsize 480 refresh: 75 vid: 20273 > (II) RADEON(0): #1: hsize: 800 vsize 600 refresh: 75 vid: 20293 > (II) RADEON(0): #2: hsize: 1024 vsize 768 refresh: 75 vid: 20321 > (II) RADEON(0): #3: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 > (II) RADEON(0): Supported detailed timing: > (II) RADEON(0): clock: 108.0 MHz Image Size: 376 x 301 mm > (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 > h_border: 0 > (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 > v_border: 0 > (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 83 kHz, > PixClock max 140 MHz > (II) RADEON(0): Monitor name: L1910S > (II) RADEON(0): Monitor name: > (II) RADEON(0): EDID (in hex): > (II) RADEON(0): 00ffffffffffff001e6d784a87180100 > (II) RADEON(0): 020f01036e261e78eaec50a5584a9a26 > (II) RADEON(0): 215054a56b80314f454f614f81800101 > (II) RADEON(0): 010101010101302a009851002a403070 > (II) RADEON(0): 1300782d1100001e000000fd00384b1e > (II) RADEON(0): 530e000a202020202020000000fc004c > (II) RADEON(0): 3139313053200a2020202020000000fc > (II) RADEON(0): 000a20202020202020202020202000d8 > (II) RADEON(0): EDID vendor "GSM", prod id 19064 > Output CRT1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Disable CRTC memreq 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Disable CRTC memreq 1 success > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0x00ff00e0 0x00ef00d0 > (II) RADEON(0): MC_AGP_LOCATION : 0x00000000 > (II) RADEON(0): avivo_restore ! > Enable CRTC memreq 0 success > Enable CRTC 0 success > Unblank CRTC 0 success > (==) RADEON(0): Write-combining range (0xa0000,0x10000) was already clear > (II) UnloadModule: "kbd" > (II) UnloadModule: "mouse" > (II) UnloadModule: "kbd" > (II) UnloadModule: "mouse" -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 21:27:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3717E1065672 for ; Sat, 13 Feb 2010 21:27:25 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id F0B078FC14 for ; Sat, 13 Feb 2010 21:27:24 +0000 (UTC) Received: from [192.168.1.4] (adsl-241-172-37.bna.bellsouth.net [74.241.172.37]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o1DLRBZc035339 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 13 Feb 2010 16:27:14 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Norbert Papke In-Reply-To: <201002131137.34812.npapke@acm.org> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <20100211074933.GJ9748@acme.spoerlein.net> <1266080709.89452.21.camel@balrog.2hip.net> <201002131137.34812.npapke@acm.org> Content-Type: text/plain Organization: FreeBSD Date: Sat, 13 Feb 2010 15:27:04 -0600 Message-Id: <1266096425.89452.30.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX,RCVD_IN_PBL,RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 21:27:25 -0000 On Sat, 2010-02-13 at 11:37 -0800, Norbert Papke wrote: > On February 13, 2010, Robert Noland wrote: > > Ok, I've put up a patch at: > > > > http://people.freebsd.org/~rnoland/drm-radeon-test.patch > > http://people.freebsd.org/~rnoland/drm-radeon-8-test.patch This one should work on 8... robert. > > This is sort of a mega patch and includes: > > > > Re-worked drm mapping code, that ensures that we don't end up > > incorrectly mapping certain maps with overlapping offsets. This > > generally shows up as the ring buffer not being cleared (contents != 0 > > in xorg.log) which leads to corruption and other bad behavior. > > > > Re-written scatter gather allocation code. This interacts directly with > > the VM system, rather than using bus_dma to allow us to grab > > non-contiguous pages for the scatter gather backing of the GART. It > > also makes it easier to handle the caching mode of the backing pages. > > > > Disable cache snooping on radeon cards, since we have write combining > > set properly now. > > > > I have at least done a test build on -CURRENT with this patch, but I > > haven't had time to do much else without the rest of the code in my > > tree. I've been running most all of this code for a month or two now at > > least, so it is mostly just a question of whether or not I got all of > > the conflicts sorted out properly when I made this patch. > > > > The re-mapping code has the most widespread impact and has been tested > > on radeon r600 amd64, intel g45 i386 and mga amd64. > > > > robert. > > I tweaked the patch and applied it to 8-STABLE. It has improved things. I no > longer hang when starting X but DRI still does not work. I also > intermittently experience the interrupt problem where the screen does not > update unless I wiggle the mouse. > > It is entirely possible that I messed up adapting the patch for 8-STABLE. I > did the following: > > * applied SVN 203287 and 203287 for VIA support > * applied your patch > * reverted drm_vm.c because it is dependent on r201223 (Update d_mmap() to > accept vm_ooffset_t and vm_memattr_t.) > * re-enabled snooping in ati_pcigart.c and r600_cp.c > > I have appended my xorg.0.log file. Perhaps something in there stands out as > red flag? > > Thank you for all the time you put into this. > > Cheers, > > -- Norbert Papke. > npapke@acm.org > > > > X.Org X Server 1.6.5 > Release Date: 2009-10-11 > X Protocol Version 11, Revision 0 > Build Operating System: FreeBSD 8.0-STABLE amd64 > Current Operating System: FreeBSD proven.lan.provenpath.ca 8.0-STABLE FreeBSD > 8.0-STABLE #36 r203841M: Sat Feb 13 10:50:20 PST 2010 > npapke@proven.lan.provenpath.ca:/usr/obj/red/usr/public/freebsd/sources/stable8/sys/PROVEN > amd64 > Build Date: 10 February 2010 06:25:15PM > > 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: Sat Feb 13 10:55:30 2010 > (==) Using config file: "/etc/X11/xorg.conf" > (==) ServerLayout "X.org Configured" > (**) |-->Screen "Screen0" (0) > (**) | |-->Monitor "LG" > (**) | |-->Device "Card0" > (**) Option "DontZap" "off" > (**) Option "BlankTime" "15" > (**) Option "StandbyTime" "120" > (**) Option "SuspendTime" "150" > (**) Option "OffTime" "180" > (**) Option "AIGLX" "on" > (**) Option "AllowEmptyInput" "false" > (==) Automatically adding devices > (==) Automatically enabling devices > (WW) `fonts.dir' not found (or not valid) in "/usr/local/share/fonts/". > Entry deleted from font path. > (Run 'mkfontdir' on "/usr/local/share/fonts/"). > (WW) `fonts.dir' not found (or not valid) in > "/usr/local/share/fonts/cmpsfont". > Entry deleted from font path. > (Run 'mkfontdir' on "/usr/local/share/fonts/cmpsfont"). > (WW) `fonts.dir' not found (or not valid) in > "/usr/local/share/fonts/amspsfont". > Entry deleted from font path. > (Run 'mkfontdir' on "/usr/local/share/fonts/amspsfont"). > (**) FontPath set to: > /usr/local/lib/X11/fonts/bitstream-vera/, > /usr/local/lib/X11/fonts/dejavu/, > /usr/local/lib/X11/fonts/misc/, > /usr/local/lib/X11/fonts/TrueType/, > /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/webfonts/, > /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" > (**) Extension "Composite" is enabled > (==) |-->Input Device "" > (==) |-->Input Device "" > (==) The core pointer device wasn't specified explicitly in the layout. > Using the default mouse configuration. > (==) The core keyboard device wasn't specified explicitly in the layout. > Using the default keyboard configuration. > (II) Loader magic: 0x3f60 > (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 9 > > (--) PCI:*(0:1:0:0) 1002:9598:1043:01e4 ATI Technologies Inc Mobility Radeon > HD 3600 Series 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) LoadModule: "extmod" > (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so > (II) Module extmod: vendor="X.Org Foundation" > compiled for 1.6.5, 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 XFree86-DGA > (II) Loading extension DPMS > (II) Loading extension XVideo > (II) Loading extension XVideo-MotionCompensation > (II) Loading extension X-Resource > (II) LoadModule: "dbe" > (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so > (II) Module dbe: vendor="X.Org Foundation" > compiled for 1.6.5, 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: "glx" > (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so > (II) Module glx: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 1.0.0 > ABI class: X.Org Server Extension, version 2.0 > (**) AIGLX enabled > (II) Loading extension GLX > (II) LoadModule: "record" > (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so > (II) Module record: vendor="X.Org Foundation" > compiled for 1.6.5, 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: "dri" > (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so > (II) Module dri: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 1.0.0 > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension XFree86-DRI > (II) LoadModule: "dri2" > (II) Loading /usr/local/lib/xorg/modules/extensions//libdri2.so > (II) Module dri2: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 1.1.0 > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension DRI2 > (II) LoadModule: "ati" > (II) Loading /usr/local/lib/xorg/modules/drivers//ati_drv.so > (II) Module ati: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 6.12.4 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 5.0 > (II) LoadModule: "radeon" > (II) Loading /usr/local/lib/xorg/modules/drivers//radeon_drv.so > (II) Module radeon: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 6.12.4 > 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.5, 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.5, module version = 1.3.2 > Module class: X.Org XInput Driver > ABI class: X.Org XInput driver, version 4.0 > (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 X800 VE (R420) JT (AGP), ATI Radeon X850 (R480) (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 Radeon HD 4850 x2, > 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 Radeon 4800 Series, ATI Radeon 4800 Series, ATI FirePro M7750, > ATI M98, ATI M98, ATI M98, ATI Mobility Radeon HD 4650, > ATI Radeon RV730 (AGP), ATI Mobility Radeon HD 4670, > ATI FirePro M5750, ATI Radeon RV730 (AGP), > ATI RV730XT [Radeon HD 4670], ATI RADEON E4600, > ATI Radeon HD 4600 Series, ATI RV730 PRO [Radeon HD 4650], > ATI FirePro V7750 (FireGL), ATI FirePro V5700 (FireGL), > ATI FirePro V3750 (FireGL), ATI Mobility Radeon HD 4830, > ATI Mobility Radeon HD 4850, ATI FirePro M7740, ATI RV740, > ATI Radeon HD 4770, ATI Radeon HD 4700 Series, ATI Radeon HD 4770, > ATI FirePro M5750, 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 FirePro RG220, 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, > ATI Radeon HD 3200 Graphics, ATI Radeon 3000 Graphics, > ATI Radeon HD 4200, ATI Radeon 4100, ATI Mobility Radeon HD 4200, > ATI Mobility Radeon 4100, ATI RS880 > (II) Primary Device is: PCI 01@00:00:0 > (II) resource ranges after xf86ClaimFixedResources() call: > [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) 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] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] > [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] > [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] > [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] > [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] > (II) Setting vga for screen 0. > (II) RADEON(0): TOTO SAYS 00000000fe9e0000 > (II) RADEON(0): MMIO registers at 0x00000000fe9e0000: size 64KB > (II) RADEON(0): PCI bus 1 card 0 func 0 > (**) RADEON(0): Depth 24, (--) framebuffer bpp 32 > (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) > (==) RADEON(0): Default visual is TrueColor > (**) RADEON(0): Option "AccelMethod" "exa" > (II) Loading sub module "vgahw" > (II) LoadModule: "vgahw" > (II) Loading /usr/local/lib/xorg/modules//libvgahw.so > (II) Module vgahw: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 0.1.0 > ABI class: X.Org Video Driver, version 5.0 > (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is > 0x0000 > (==) RADEON(0): RGB weight 888 > (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) > (--) RADEON(0): Chipset: "ATI Radeon HD 3600 XT" (ChipID = 0x9598) > (--) RADEON(0): Linear framebuffer at 0x00000000d0000000 > (II) RADEON(0): PCIE card detected > (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.5, module version = 1.0.0 > ABI class: X.Org Video Driver, version 5.0 > (II) RADEON(0): initializing int10 > (==) RADEON(0): Write-combining range (0xa0000,0x20000) was already clear > (==) RADEON(0): Write-combining range (0xc0000,0x40000) was already clear > (II) RADEON(0): Primary V_BIOS segment is: 0xc000 > (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear > (II) RADEON(0): ATOM BIOS detected > (II) RADEON(0): ATOM BIOS Rom: > SubsystemVendorID: 0x1043 SubsystemID: 0x01e4 > IOBaseAddress: 0xc000 > Filename: SV27381.bin > BIOS Bootup Message: > 9598.10.74.0.1.AS01 > > (II) RADEON(0): Framebuffer space used by Firmware (kb): 16 > (II) RADEON(0): Start of VRAM area used by Firmware: 0x1fffc000 > (II) RADEON(0): AtomBIOS requests 16kB of VRAM scratch space > (II) RADEON(0): AtomBIOS VRAM scratch base: 0x1fffc000 > (II) RADEON(0): Cannot get VRAM scratch space. Allocating in main memory > instead > (II) RADEON(0): Default Engine Clock: 725000 > (II) RADEON(0): Default Memory Clock: 700000 > (II) RADEON(0): Maximum Pixel ClockPLL Frequency Output: 1200000 > (II) RADEON(0): Minimum Pixel ClockPLL Frequency Output: 0 > (II) RADEON(0): Maximum Pixel ClockPLL Frequency Input: 13500 > (II) RADEON(0): Minimum Pixel ClockPLL Frequency Input: 1000 > (II) RADEON(0): Maximum Pixel Clock: 400000 > (II) RADEON(0): Reference Clock: 27000 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: Searching for BusID pci:0000:01:00.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: drmOpenMinor returns 10 > drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 > (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module > version 1.31.0 > (==) RADEON(0): Page Flipping disabled on r5xx and newer chips. > > (II) RADEON(0): Will try to use DMA for Xv image transfers > (II) RADEON(0): Detected total video RAM=524288K, accessible=262144K (PCI > BAR=262144K) > (--) RADEON(0): Mapped VideoRAM: 262144 kByte (128 bit DDR SDRAM) > (II) RADEON(0): Color tiling disabled > (II) Loading sub module "ddc" > (II) LoadModule: "ddc" > (II) Module "ddc" already built-in > (II) Loading sub module "i2c" > (II) LoadModule: "i2c" > (II) Module "i2c" already built-in > (II) RADEON(0): ref_freq: 2700, min_out_pll: 64800, max_out_pll: 120000, > min_in_pll: 100, max_in_pll: 1350, xclk: 40000, sclk: 725.000000, mclk: > 700.000000 > (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=64800 max=120000; xclk=40000 > Shared DDC line: 1 4 > Shared DDC line: 1 5 > Shared DDC line: 4 1 > (II) RADEON(0): Output HDMI-0 using monitor section LG > (II) RADEON(0): I2C bus "HDMI-0" initialized. > (II) RADEON(0): Output VGA-0 has no monitor section > (II) RADEON(0): I2C bus "VGA-0" initialized. > (II) RADEON(0): Output DVI-0 has no monitor section > (II) RADEON(0): I2C bus "DVI-0" initialized. > (II) RADEON(0): Port0: > XRANDR name: HDMI-0 > Connector: HDMI-A > DFP1: INTERNAL_UNIPHY > DDC reg: 0x7e50 > (II) RADEON(0): Port1: > XRANDR name: VGA-0 > Connector: VGA > CRT2: INTERNAL_KLDSCP_DAC2 > DDC reg: 0x7e50 > (II) RADEON(0): Port2: > XRANDR name: DVI-0 > Connector: DVI-I > CRT1: INTERNAL_KLDSCP_DAC1 > DFP2: INTERNAL_KLDSCP_LVTMA > DDC reg: 0x7e40 > (II) RADEON(0): I2C device "HDMI-0:E-EDID segment register" registered at > address 0x60. > (II) RADEON(0): I2C device "HDMI-0:ddc2" registered at address 0xA0. > (II) RADEON(0): Output: HDMI-0, Detected Monitor Type: 0 > finished output detect: 0 > (II) RADEON(0): I2C device "VGA-0:E-EDID segment register" registered at > address 0x60. > (II) RADEON(0): I2C device "VGA-0:ddc2" registered at address 0xA0. > Dac detection success > (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 > finished output detect: 1 > (II) RADEON(0): I2C device "DVI-0:E-EDID segment register" registered at > address 0x60. > (II) RADEON(0): I2C device "DVI-0:ddc2" registered at address 0xA0. > (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 1 > (II) RADEON(0): EDID data from the display on output: DVI-0 > ---------------------- > (II) RADEON(0): Manufacturer: GSM Model: 4a78 Serial#: 71815 > (II) RADEON(0): Year: 2005 Week: 2 > (II) RADEON(0): EDID Version: 1.3 > (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V > (II) RADEON(0): Sync: Separate Composite SyncOnGreen > (II) RADEON(0): Max Image Size [cm]: horiz.: 38 vert.: 30 > (II) RADEON(0): Gamma: 2.20 > (II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display > (II) RADEON(0): First detailed timing is preferred mode > (II) RADEON(0): redX: 0.647 redY: 0.346 greenX: 0.292 greenY: 0.602 > (II) RADEON(0): blueX: 0.149 blueY: 0.130 whiteX: 0.312 whiteY: 0.328 > (II) RADEON(0): Supported established timings: > (II) RADEON(0): 720x400@70Hz > (II) RADEON(0): 640x480@60Hz > (II) RADEON(0): 640x480@75Hz > (II) RADEON(0): 800x600@60Hz > (II) RADEON(0): 800x600@75Hz > (II) RADEON(0): 832x624@75Hz > (II) RADEON(0): 1024x768@60Hz > (II) RADEON(0): 1024x768@75Hz > (II) RADEON(0): 1280x1024@75Hz > (II) RADEON(0): 1152x870@75Hz > (II) RADEON(0): Manufacturer's mask: 0 > (II) RADEON(0): Supported standard timings: > (II) RADEON(0): #0: hsize: 640 vsize 480 refresh: 75 vid: 20273 > (II) RADEON(0): #1: hsize: 800 vsize 600 refresh: 75 vid: 20293 > (II) RADEON(0): #2: hsize: 1024 vsize 768 refresh: 75 vid: 20321 > (II) RADEON(0): #3: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 > (II) RADEON(0): Supported detailed timing: > (II) RADEON(0): clock: 108.0 MHz Image Size: 376 x 301 mm > (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 > h_border: 0 > (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 > v_border: 0 > (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 83 kHz, > PixClock max 140 MHz > (II) RADEON(0): Monitor name: L1910S > (II) RADEON(0): Monitor name: > (II) RADEON(0): EDID (in hex): > (II) RADEON(0): 00ffffffffffff001e6d784a87180100 > (II) RADEON(0): 020f01036e261e78eaec50a5584a9a26 > (II) RADEON(0): 215054a56b80314f454f614f81800101 > (II) RADEON(0): 010101010101302a009851002a403070 > (II) RADEON(0): 1300782d1100001e000000fd00384b1e > (II) RADEON(0): 530e000a202020202020000000fc004c > (II) RADEON(0): 3139313053200a2020202020000000fc > (II) RADEON(0): 000a20202020202020202020202000d8 > finished output detect: 2 > finished all detect > before xf86InitialConfiguration > (II) RADEON(0): Output: HDMI-0, Detected Monitor Type: 0 > Dac detection success > (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 > (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 1 > (II) RADEON(0): EDID data from the display on output: DVI-0 > ---------------------- > (II) RADEON(0): Manufacturer: GSM Model: 4a78 Serial#: 71815 > (II) RADEON(0): Year: 2005 Week: 2 > (II) RADEON(0): EDID Version: 1.3 > (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V > (II) RADEON(0): Sync: Separate Composite SyncOnGreen > (II) RADEON(0): Max Image Size [cm]: horiz.: 38 vert.: 30 > (II) RADEON(0): Gamma: 2.20 > (II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display > (II) RADEON(0): First detailed timing is preferred mode > (II) RADEON(0): redX: 0.647 redY: 0.346 greenX: 0.292 greenY: 0.602 > (II) RADEON(0): blueX: 0.149 blueY: 0.130 whiteX: 0.312 whiteY: 0.328 > (II) RADEON(0): Supported established timings: > (II) RADEON(0): 720x400@70Hz > (II) RADEON(0): 640x480@60Hz > (II) RADEON(0): 640x480@75Hz > (II) RADEON(0): 800x600@60Hz > (II) RADEON(0): 800x600@75Hz > (II) RADEON(0): 832x624@75Hz > (II) RADEON(0): 1024x768@60Hz > (II) RADEON(0): 1024x768@75Hz > (II) RADEON(0): 1280x1024@75Hz > (II) RADEON(0): 1152x870@75Hz > (II) RADEON(0): Manufacturer's mask: 0 > (II) RADEON(0): Supported standard timings: > (II) RADEON(0): #0: hsize: 640 vsize 480 refresh: 75 vid: 20273 > (II) RADEON(0): #1: hsize: 800 vsize 600 refresh: 75 vid: 20293 > (II) RADEON(0): #2: hsize: 1024 vsize 768 refresh: 75 vid: 20321 > (II) RADEON(0): #3: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 > (II) RADEON(0): Supported detailed timing: > (II) RADEON(0): clock: 108.0 MHz Image Size: 376 x 301 mm > (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 > h_border: 0 > (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 > v_border: 0 > (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 83 kHz, > PixClock max 140 MHz > (II) RADEON(0): Monitor name: L1910S > (II) RADEON(0): Monitor name: > (II) RADEON(0): EDID (in hex): > (II) RADEON(0): 00ffffffffffff001e6d784a87180100 > (II) RADEON(0): 020f01036e261e78eaec50a5584a9a26 > (II) RADEON(0): 215054a56b80314f454f614f81800101 > (II) RADEON(0): 010101010101302a009851002a403070 > (II) RADEON(0): 1300782d1100001e000000fd00384b1e > (II) RADEON(0): 530e000a202020202020000000fc004c > (II) RADEON(0): 3139313053200a2020202020000000fc > (II) RADEON(0): 000a20202020202020202020202000d8 > (II) RADEON(0): EDID vendor "GSM", prod id 19064 > (II) RADEON(0): Output HDMI-0 disconnected > (II) RADEON(0): Output VGA-0 disconnected > (II) RADEON(0): Output DVI-0 connected > (II) RADEON(0): Using user preference for initial modes > (II) RADEON(0): Output DVI-0 using initial mode 1280x1024 > after xf86InitialConfiguration > (==) RADEON(0): DPI set to (96, 96) > (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.5, module version = 1.0.0 > ABI class: X.Org ANSI C Emulation, version 0.4 > (==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0) > (II) Loading sub module "ramdac" > (II) LoadModule: "ramdac" > (II) Module "ramdac" already built-in > (==) RADEON(0): Will attempt to use R6xx/R7xx EXA support if DRI is enabled. > (II) Loading sub module "exa" > (II) LoadModule: "exa" > (II) Loading /usr/local/lib/xorg/modules//libexa.so > (II) Module exa: vendor="X.Org Foundation" > compiled for 1.6.5, module version = 2.4.0 > ABI class: X.Org Video Driver, version 5.0 > (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear > (!!) RADEON(0): For information on using the multimedia capabilities > of this adapter, please see http://gatos.sf.net. > (!!) RADEON(0): MergedFB support has been removed and replaced with xrandr 1.2 > support > (--) 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] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] > [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] > [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] > [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] > [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] > (II) RADEON(0): RADEONScreenInit d0000000 0 0 > (==) RADEON(0): Write-combining range (0xa0000,0x10000) was already clear > Output CRT1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Disable CRTC memreq 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Disable CRTC memreq 1 success > (==) RADEON(0): Using 24 bit depth buffer > mc fb loc is 00ef00d0 > (II) RADEON(0): RADEONInitMemoryMap() : > (II) RADEON(0): mem_size : 0x20000000 > (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > (II) RADEON(0): Depth moves disabled by default > (II) RADEON(0): Allocating from a screen of 262080 kb > (II) RADEON(0): Will use 32 kb for hardware cursor 0 at offset 0x00640000 > (II) RADEON(0): Will use 32 kb for hardware cursor 1 at offset 0x00644000 > (II) RADEON(0): Will use 6400 kb for front buffer at offset 0x00000000 > (II) RADEON(0): Will use 64 kb for PCI GART at offset 0x0fff0000 > (II) RADEON(0): Will use 6400 kb for back buffer at offset 0x00648000 > (II) RADEON(0): Will use 6400 kb for depth buffer at offset 0x00c88000 > (II) RADEON(0): Will use 120832 kb for textures at offset 0x012c8000 > (II) RADEON(0): Will use 122016 kb for X Server offscreen at offset 0x088c8000 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: Searching for BusID pci:0000:01:00.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: drmOpenMinor returns 10 > drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 > (II) [drm] DRM interface version 1.2 > (II) [drm] Mapping SAREA for DRM lock failed. > (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ff00e0 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > (==) RADEON(0): Backing store disabled > (WW) RADEON(0): Direct rendering disabled > (EE) RADEON(0): Acceleration initialization failed > (II) RADEON(0): Acceleration disabled > (**) Option "dpms" > (**) RADEON(0): DPMS enabled > (==) RADEON(0): Silken mouse enabled > (II) RADEON(0): Textured video requires CP on R5xx/R6xx/R7xx/IGP > (II) RADEON(0): DIG0 transmitter: Coherent Mode enabled > Output DIG0 transmitter setup success > Output CRT2 disable success > Output CRT1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Disable CRTC memreq 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Disable CRTC memreq 1 success > Output CRT1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Disable CRTC memreq 0 success > Mode 1280x1024 - 1688 1066 5 > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > freq: 108000000 > best_freq: 108000000 > best_feedback_div: 48 > best_ref_div: 2 > best_post_div: 6 > (II) RADEON(0): crtc(0) Clock: mode 108000, PLL 108000 > (II) RADEON(0): crtc(0) PLL : refdiv 2, fbdiv 0x30(48), pdiv 6 > Set CRTC 0 PLL success > Set CRTC Timing success > Set CRTC 0 Overscan success > Not using RMX > scaler 0 setup success > Set CRTC 0 Source success > crtc 0 YUV disable setup success > Output DAC1 setup success > Output CRT1 enable success > Enable CRTC memreq 0 success > Enable CRTC 0 success > Unblank CRTC 0 success > (II) RADEON(0): DIG0 transmitter: Coherent Mode enabled > Output DIG0 transmitter setup success > Output CRT2 disable success > Blank CRTC 1 success > Disable CRTC 1 success > Disable CRTC memreq 1 success > (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled > message. > Output CRT1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Disable CRTC memreq 0 success > Mode 1280x1024 - 1688 1066 5 > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0x00ef00d0 0x00ef00d0 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > freq: 108000000 > best_freq: 108000000 > best_feedback_div: 48 > best_ref_div: 2 > best_post_div: 6 > (II) RADEON(0): crtc(0) Clock: mode 108000, PLL 108000 > (II) RADEON(0): crtc(0) PLL : refdiv 2, fbdiv 0x30(48), pdiv 6 > Set CRTC 0 PLL success > Set CRTC Timing success > Set CRTC 0 Overscan success > Not using RMX > scaler 0 setup success > Set CRTC 0 Source success > crtc 0 YUV disable setup success > Output DAC1 setup success > Output CRT1 enable success > Enable CRTC memreq 0 success > Enable CRTC 0 success > Unblank CRTC 0 success > (--) RandR disabled > (II) Setting vga for screen 0. > (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: Screen 0 is not DRI2 capable > (II) AIGLX: Screen 0 is not DRI capable > (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so > (II) GLX: Initialized DRISWRAST GL provider for screen 0 > (II) RADEON(0): Setting screen physical size to 376 x 301 > (WW) : No Device specified, looking for one... > (II) : Setting Device option to "/dev/sysmouse" > (--) : Device: "/dev/sysmouse" > (==) : Protocol: "Auto" > (**) Option "CorePointer" > (**) : always reports core events > (==) : Emulate3Buttons, Emulate3Timeout: 50 > (**) : ZAxisMapping: buttons 4 and 5 > (**) : Buttons: 9 > (**) : Sensitivity: 1 > (II) XINPUT: Adding extended input device "" (type: MOUSE) > (**) : (accel) keeping acceleration scheme 1 > (**) : (accel) filter chain progression: 2.00 > (**) : (accel) filter stage 0: 20.00 ms > (**) : (accel) set acceleration profile 0 > (II) : SetupAuto: hw.iftype is 4, hw.model is 0 > (II) : SetupAuto: protocol is SysMouse > (**) Option "CoreKeyboard" > (**) : always reports core events > (**) Option "Protocol" "standard" > (**) : Protocol: standard > (**) Option "AutoRepeat" "500 30" > (**) Option "XkbRules" "xorg" > (**) : XkbRules: "xorg" > (**) Option "XkbModel" "pc105" > (**) : XkbModel: "pc105" > (**) Option "XkbLayout" "us" > (**) : XkbLayout: "us" > (**) Option "CustomKeycodes" "off" > (**) : CustomKeycodes disabled > (II) XINPUT: Adding extended input device "" (type: > KEYBOARD) > (II) config/hal: Adding input device USB-PS/2 Optical Mouse > (**) USB-PS/2 Optical Mouse: Device: "/dev/sysmouse" > (==) USB-PS/2 Optical Mouse: Protocol: "Auto" > (**) USB-PS/2 Optical Mouse: always reports core events > (**) Option "Device" "/dev/sysmouse" > (==) USB-PS/2 Optical Mouse: Emulate3Buttons, Emulate3Timeout: 50 > (**) USB-PS/2 Optical Mouse: ZAxisMapping: buttons 4 and 5 > (**) USB-PS/2 Optical Mouse: Buttons: 9 > (**) USB-PS/2 Optical Mouse: Sensitivity: 1 > (II) XINPUT: Adding extended input device "USB-PS/2 Optical Mouse" (type: > MOUSE) > (**) USB-PS/2 Optical Mouse: (accel) keeping acceleration scheme 1 > (**) USB-PS/2 Optical Mouse: (accel) filter chain progression: 2.00 > (**) USB-PS/2 Optical Mouse: (accel) filter stage 0: 20.00 ms > (**) USB-PS/2 Optical Mouse: (accel) set acceleration profile 0 > (II) USB-PS/2 Optical Mouse: SetupAuto: hw.iftype is 4, hw.model is 0 > (II) USB-PS/2 Optical Mouse: SetupAuto: protocol is SysMouse > (II) config/hal: Adding input device AT Keyboard > (**) AT Keyboard: always reports core events > (**) Option "Protocol" "standard" > (**) AT Keyboard: Protocol: standard > (**) Option "AutoRepeat" "500 30" > (**) Option "XkbRules" "xorg" > (**) AT Keyboard: XkbRules: "xorg" > (**) Option "XkbModel" "pc105" > (**) AT Keyboard: XkbModel: "pc105" > (**) Option "XkbLayout" "us" > (**) AT Keyboard: XkbLayout: "us" > (**) Option "XkbOptions" "terminate:ctrl_alt_bksp" > (**) AT Keyboard: XkbOptions: "terminate:ctrl_alt_bksp" > (**) Option "CustomKeycodes" "off" > (**) AT Keyboard: CustomKeycodes disabled > (II) XINPUT: Adding extended input device "AT Keyboard" (type: KEYBOARD) > (II) RADEON(0): Output: HDMI-0, Detected Monitor Type: 0 > Dac detection success > (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 > (II) RADEON(0): EDID vendor "GSM", prod id 19064 > (II) RADEON(0): Using EDID range info for horizontal sync > (II) RADEON(0): Using EDID range info for vertical refresh > (II) RADEON(0): Printing DDC gathered Modelines: > (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 > 1025 1028 1066 +hsync +vsync (64.0 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 > 628 +hsync +vsync (37.9 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 > 500 -hsync -vsync (37.5 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 > 525 -hsync -vsync (31.5 kHz) > (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 > 449 -hsync +vsync (31.5 kHz) > (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 > 1025 1028 1066 +hsync +vsync (80.0 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 > 772 800 +hsync +vsync (60.0 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 > 777 806 -hsync -vsync (48.4 kHz) > (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 > 667 -hsync -vsync (49.7 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 > 625 +hsync +vsync (46.9 kHz) > (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 > 868 900 +hsync +vsync (67.5 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 > 500 -hsync -vsync (37.5 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 > 625 +hsync +vsync (46.9 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 > 772 800 +hsync +vsync (60.0 kHz) > (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 > 1025 1028 1066 +hsync +vsync (64.0 kHz) > (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 1 > (II) RADEON(0): EDID data from the display on output: DVI-0 > ---------------------- > (II) RADEON(0): Manufacturer: GSM Model: 4a78 Serial#: 71815 > (II) RADEON(0): Year: 2005 Week: 2 > (II) RADEON(0): EDID Version: 1.3 > (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V > (II) RADEON(0): Sync: Separate Composite SyncOnGreen > (II) RADEON(0): Max Image Size [cm]: horiz.: 38 vert.: 30 > (II) RADEON(0): Gamma: 2.20 > (II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display > (II) RADEON(0): First detailed timing is preferred mode > (II) RADEON(0): redX: 0.647 redY: 0.346 greenX: 0.292 greenY: 0.602 > (II) RADEON(0): blueX: 0.149 blueY: 0.130 whiteX: 0.312 whiteY: 0.328 > (II) RADEON(0): Supported established timings: > (II) RADEON(0): 720x400@70Hz > (II) RADEON(0): 640x480@60Hz > (II) RADEON(0): 640x480@75Hz > (II) RADEON(0): 800x600@60Hz > (II) RADEON(0): 800x600@75Hz > (II) RADEON(0): 832x624@75Hz > (II) RADEON(0): 1024x768@60Hz > (II) RADEON(0): 1024x768@75Hz > (II) RADEON(0): 1280x1024@75Hz > (II) RADEON(0): 1152x870@75Hz > (II) RADEON(0): Manufacturer's mask: 0 > (II) RADEON(0): Supported standard timings: > (II) RADEON(0): #0: hsize: 640 vsize 480 refresh: 75 vid: 20273 > (II) RADEON(0): #1: hsize: 800 vsize 600 refresh: 75 vid: 20293 > (II) RADEON(0): #2: hsize: 1024 vsize 768 refresh: 75 vid: 20321 > (II) RADEON(0): #3: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 > (II) RADEON(0): Supported detailed timing: > (II) RADEON(0): clock: 108.0 MHz Image Size: 376 x 301 mm > (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 > h_border: 0 > (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 > v_border: 0 > (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 83 kHz, > PixClock max 140 MHz > (II) RADEON(0): Monitor name: L1910S > (II) RADEON(0): Monitor name: > (II) RADEON(0): EDID (in hex): > (II) RADEON(0): 00ffffffffffff001e6d784a87180100 > (II) RADEON(0): 020f01036e261e78eaec50a5584a9a26 > (II) RADEON(0): 215054a56b80314f454f614f81800101 > (II) RADEON(0): 010101010101302a009851002a403070 > (II) RADEON(0): 1300782d1100001e000000fd00384b1e > (II) RADEON(0): 530e000a202020202020000000fc004c > (II) RADEON(0): 3139313053200a2020202020000000fc > (II) RADEON(0): 000a20202020202020202020202000d8 > (II) RADEON(0): EDID vendor "GSM", prod id 19064 > Output CRT1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Disable CRTC memreq 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Disable CRTC memreq 1 success > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0x00ff00e0 0x00ef00d0 > (II) RADEON(0): MC_AGP_LOCATION : 0x00000000 > (II) RADEON(0): avivo_restore ! > Enable CRTC memreq 0 success > Enable CRTC 0 success > Unblank CRTC 0 success > (==) RADEON(0): Write-combining range (0xa0000,0x10000) was already clear > (II) UnloadModule: "kbd" > (II) UnloadModule: "mouse" > (II) UnloadModule: "kbd" > (II) UnloadModule: "mouse" -- Robert Noland FreeBSD From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 23:12:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC1E0106566B; Sat, 13 Feb 2010 23:12:58 +0000 (UTC) (envelope-from npapke@acm.org) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 87B278FC0A; Sat, 13 Feb 2010 23:12:58 +0000 (UTC) Received: from pd4ml3so-ssvc.prod.shaw.ca ([10.0.141.150]) by pd3mo1so-svcs.prod.shaw.ca with ESMTP; 13 Feb 2010 16:12:57 -0700 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=ymFRpTLrexEA:10 a=VF9RaR9bft6c8SsOr3WyFg==:17 a=6I5d2MoRAAAA:8 a=N54-gffFAAAA:8 a=npHSuol4oLBSm1V11-kA:9 a=OtCxdYWWZJHQ-NzFGt8A:7 a=UowPwFjn6sf60eK0vN-DQKWljPoA:4 a=nAPXUAfsBmEA:10 Received: from unknown (HELO proven.lan.provenpath.ca) ([24.85.241.34]) by pd4ml3so-dmz.prod.shaw.ca with ESMTP; 13 Feb 2010 16:12:57 -0700 Received: from proven.lan.provenpath.ca (localhost [127.0.0.1]) by proven.lan.provenpath.ca (8.14.4/8.14.4) with ESMTP id o1DNCvOg002309; Sat, 13 Feb 2010 15:12:57 -0800 (PST) (envelope-from npapke@acm.org) Received: (from npapke@localhost) by proven.lan.provenpath.ca (8.14.4/8.14.4/Submit) id o1DNCvNC002308; Sat, 13 Feb 2010 15:12:57 -0800 (PST) (envelope-from npapke@acm.org) X-Authentication-Warning: proven.lan.provenpath.ca: npapke set sender to npapke@acm.org using -f From: Norbert Papke To: Robert Noland Date: Sat, 13 Feb 2010 15:12:56 -0800 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.5; amd64; ; ) References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <201002131137.34812.npapke@acm.org> <1266096425.89452.30.camel@balrog.2hip.net> In-Reply-To: <1266096425.89452.30.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201002131512.57040.npapke@acm.org> Cc: freebsd-stable@freebsd.org Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 23:12:58 -0000 On February 13, 2010, Robert Noland wrote: > On Sat, 2010-02-13 at 11:37 -0800, Norbert Papke wrote: > > On February 13, 2010, Robert Noland wrote: > > > Ok, I've put up a patch at: > > > > > > http://people.freebsd.org/~rnoland/drm-radeon-test.patch > > http://people.freebsd.org/~rnoland/drm-radeon-8-test.patch > > This one should work on 8... Thanks, the patch applies and builds cleanly. Unfortunately, it does not fix things for me. I am back to completely hanging the system. I getting the sense that there is some randomness or a timing issue. Changes that improved the behavior in one trial do not necessarily help in another trial. One thing I did is enable DRM_DEBUG. I wanted to get sense of how far we got before the hang. Unfortunately, there is no guarantee that log messages will be persisted before the system hangs. In a few attempts, the latest messages I observed were the following: Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev->agp_buffer_map->virtual 0xffffff807a51b000 Feb 13 13:37:58 proven kernel: info: [drm] Setting GART location based on new memory map Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] fb 0xd0000000 size 536870912 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv->gart_size 33554432 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv->gart_vm_start 0xf0000000 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv->gart_buffers_offset 0xf0102000 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] Using gart offset 0x0fff0000 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] Setting phys_pci_gart to 0xffffff00dfff0000 0FFF0000 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 0: 0x00000000b956c063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 128: 0x0000000082128063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 256: 0x0000000098b8a063 [...] Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 7936: 0x00000000499df063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 8064: 0x0000000049a21063 Feb 13 13:37:58 proven kernel: info: [drm] Loading RV635 Microcode Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_cp_stop] I will repeat the experiment a few more times. Cheers. -- Norbert Papke. npapke@acm.org From owner-freebsd-stable@FreeBSD.ORG Sat Feb 13 23:38:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D5C8106566C; Sat, 13 Feb 2010 23:38:38 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id F0ADA8FC12; Sat, 13 Feb 2010 23:38:37 +0000 (UTC) Received: by bwz21 with SMTP id 21so3007587bwz.4 for ; Sat, 13 Feb 2010 15:38:36 -0800 (PST) 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=Vv++Nz75mIXRwVp2aaR3WYREl6teI8HxyEXOoSBJcdk=; b=Jhakn8PoIysCLEgPRRpLwqgspqnMzJfSFeZ24XI7d0BjjNb9pI4R3zW/fRfXf1S75K ZY5K/5CDhN9VWhoVVRJ7RB5T9aJwr6MiRPEwFCzfGw5uEsEnkSMT0RpN9cHYfXKolcee kM2xivDanfM64dEPoPdCj3zRYGSsb0xSf3SIk= 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=o8kTXtyLCfqa986yNwcV0gvtP7XEOJqtlruvfDd0kFf5UzpJuOI/JRhImQIpk2Hc1E tsC1xAEpSP7Md0EIABsUC9lC5u2OcnmBVROVfD//HTf/TSEpHukSVdK97CBqaX5PnQUJ eedA/xWlLF0vyomdts5yoQqIpL6QcDsYW9q8g= MIME-Version: 1.0 Received: by 10.204.34.136 with SMTP id l8mr115745bkd.163.1266104316708; Sat, 13 Feb 2010 15:38:36 -0800 (PST) In-Reply-To: <201002131512.57040.npapke@acm.org> References: <6101e8c41002091524q25a7e026u585e575eb4f1589c@mail.gmail.com> <201002131137.34812.npapke@acm.org> <1266096425.89452.30.camel@balrog.2hip.net> <201002131512.57040.npapke@acm.org> Date: Sat, 13 Feb 2010 23:38:35 +0000 Message-ID: <6101e8c41002131538m5c2a62afofd45f1237a988fd1@mail.gmail.com> From: Oliver Pinter To: Norbert Papke Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Robert Noland Subject: Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 23:38:38 -0000 The interest thing is, with the previous version of xorg-server never locked the system up... On 2/13/10, Norbert Papke wrote: > On February 13, 2010, Robert Noland wrote: >> On Sat, 2010-02-13 at 11:37 -0800, Norbert Papke wrote: >> > On February 13, 2010, Robert Noland wrote: >> > > Ok, I've put up a patch at: >> > > >> > > http://people.freebsd.org/~rnoland/drm-radeon-test.patch >> >> http://people.freebsd.org/~rnoland/drm-radeon-8-test.patch >> >> This one should work on 8... > > Thanks, the patch applies and builds cleanly. > > Unfortunately, it does not fix things for me. > I am back to completely hanging the system. I getting > the sense that there is some randomness or a timing issue. > Changes that improved the behavior in one trial do not > necessarily help in another trial. > > One thing I did is enable DRM_DEBUG. I wanted to get > sense of how far we got before the hang. Unfortunately, > there is no guarantee that log messages will be persisted > before the system hangs. In a few attempts, the latest > messages I observed were the following: > > Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] > dev->agp_buffer_map->virtual 0xffffff807a51b000 > Feb 13 13:37:58 proven kernel: info: [drm] Setting GART location based on > new memory map > Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] fb 0xd0000000 > size 536870912 > Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] > dev_priv->gart_size 33554432 > Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] > dev_priv->gart_vm_start 0xf0000000 > Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] > dev_priv->gart_buffers_offset 0xf0102000 > Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] Using gart > offset 0x0fff0000 > Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] Setting > phys_pci_gart to 0xffffff00dfff0000 0FFF0000 > Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page > entry 0: 0x00000000b956c063 > Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page > entry 128: 0x0000000082128063 > Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page > entry 256: 0x0000000098b8a063 > > [...] > > Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page > entry 7936: 0x00000000499df063 > Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page > entry 8064: 0x0000000049a21063 > Feb 13 13:37:58 proven kernel: info: [drm] Loading RV635 Microcode > Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_cp_stop] > > I will repeat the experiment a few more times. > > Cheers. > > -- Norbert Papke. > npapke@acm.org > > _______________________________________________ > 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" >