From owner-freebsd-arch@FreeBSD.ORG Sun Nov 23 01:47:46 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D79EED2 for ; Sun, 23 Nov 2014 01:47:46 +0000 (UTC) Received: from webrelay1.goneo.de (webrelay1.goneo.de [85.220.129.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.goneo.de", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA2FCFE0 for ; Sun, 23 Nov 2014 01:47:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by webrelay1.goneo.de (Postfix) with ESMTP id 50E4223F1D9 for ; Sun, 23 Nov 2014 02:40:41 +0100 (CET) X-Virus-Scanned: by goneo X-Spam-Flag: NO X-Spam-Score: 2.504 X-Spam-Level: ** X-Spam-Status: No, score=2.504 tagged_above=-999 tests=[AWL=-0.007, BAYES_50=0.8, HTML_FONT_SIZE_HUGE=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_BRBL_LASTEXT=1.449] autolearn=no Received: from webrelay1.goneo.de ([127.0.0.1]) by localhost (webrelay1.goneo.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsqC1tViedyP for ; Sun, 23 Nov 2014 02:40:40 +0100 (CET) Received: from goneo.de (w36.goneo.de [82.100.220.66]) by webrelay1.goneo.de (Postfix) with ESMTP id 9C3A923F3F8 for ; Sun, 23 Nov 2014 02:40:40 +0100 (CET) To: freebsd-arch@freebsd.org Subject: ARCH, Delivery Status Notification 0000591631 X-PHP-Originating-Script: 30403:post.php(15) : eval()'d code Mime-Version: 1.0 From: "FedEx International MailService" Reply-To: "FedEx International MailService" Message-Id: Date: Sun, 23 Nov 2014 05:40:48 +0400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 01:47:46 -0000 Dear Arch, =20 We could not deliver your parcel. Shipment Label is attached to this email. =20 Warm regards, Alexander Melton, FedEx Operation Agent. =20 (C) 2014 FedEx. All rights reserved. From owner-freebsd-arch@FreeBSD.ORG Sun Nov 23 04:24:27 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E0FA62E for ; Sun, 23 Nov 2014 04:24:27 +0000 (UTC) Received: from hosting.mksnet.com.br (hosting.mksnet.com.br [187.45.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B7BE1A4 for ; Sun, 23 Nov 2014 04:24:26 +0000 (UTC) Received: from cisbra by hosting.mksnet.com.br with local (Exim 4.82) (envelope-from ) id 1XsMBf-003xnj-C7 for freebsd-arch@freebsd.org; Sat, 22 Nov 2014 22:42:03 -0300 To: freebsd-arch@freebsd.org Subject: ARCH, Postal Status Notification #000980824 Mime-Version: 1.0 From: "FedEx 2Day" Reply-To: "FedEx 2Day" Message-Id: Date: Sun, 23 Nov 2014 05:42:07 +0400 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.mksnet.com.br X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [527 526] / [47 12] X-AntiAbuse: Sender Address Domain - hosting.mksnet.com.br X-Get-Message-Sender-Via: hosting.mksnet.com.br: authenticated_id: cisbra/from_h Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 04:24:27 -0000 Dear Arch, =20 This is to confirm that one or more of your parcels has been shipped. Shipment Label is attached to email. =20 Yours trully, Enrique Wells, Support Agent. =20 (C) 2014 FedEx. All rights reserved. From owner-freebsd-arch@FreeBSD.ORG Sun Nov 23 04:31:02 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1FE7F71E for ; Sun, 23 Nov 2014 04:31:02 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E93B1D3 for ; Sun, 23 Nov 2014 04:31:01 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 0D42137B5C2; Sat, 22 Nov 2014 22:21:42 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3jldc520x1z2Vm; Sat, 22 Nov 2014 22:21:41 -0600 (CST) Date: Sat, 22 Nov 2014 22:21:41 -0600 From: "Matthew D. Fuller" To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: svn commit: r274739 - head/sys/mips/conf Message-ID: <20141123042141.GN38982@over-yonder.net> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <86ioi7ufva.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86ioi7ufva.fsf@nine.des.no> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.5 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 04:31:02 -0000 On Sat, Nov 22, 2014 at 09:42:17PM +0100 I heard the voice of Dag-Erling Smørgrav, and lo! it spake thus: > > The flower said I wish I were a tree / the tree said I wish I could be a > different kind of tree /the cat wished that it was a bee / the SO wished > that he could kill / rsh and rlogin... Obviously that should be 'rloginD', to preserve the rhyme and scansion. Why don't we have a Poetry Officer to supervise this stuff? -- 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-arch@FreeBSD.ORG Sun Nov 23 10:13:48 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D85BBA11; Sun, 23 Nov 2014 10:13:48 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9DCB3168; Sun, 23 Nov 2014 10:13:48 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 8B3393BD36; Sun, 23 Nov 2014 10:13:38 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id sANADcfY064789; Sun, 23 Nov 2014 10:13:38 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin Subject: Re: I'd like to axe some drivers In-reply-to: <201411201631.27556.jhb@freebsd.org> From: "Poul-Henning Kamp" References: <201411201631.27556.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64787.1416737618.1@critter.freebsd.dk> Date: Sun, 23 Nov 2014 10:13:38 +0000 Message-ID: <64788.1416737618@critter.freebsd.dk> Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 10:13:48 -0000 -------- In message <201411201631.27556.jhb@freebsd.org>, John Baldwin writes: >To that end, here is my short list of things that I think we can bid >farewell to in 11. Note that many of these are for ISA devices. Kill them, we can always resurrect them should we be in dire need of a zombie. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sun Nov 23 21:25:57 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 273858D0 for ; Sun, 23 Nov 2014 21:25:57 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D9E3D967 for ; Sun, 23 Nov 2014 21:25:56 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 6B695AC4B; Sun, 23 Nov 2014 21:25:49 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 4F01310E7; Sun, 23 Nov 2014 22:25:49 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Matthew D. Fuller" Subject: Re: svn commit: r274739 - head/sys/mips/conf References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <86ioi7ufva.fsf@nine.des.no> <20141123042141.GN38982@over-yonder.net> Date: Sun, 23 Nov 2014 22:25:49 +0100 In-Reply-To: <20141123042141.GN38982@over-yonder.net> (Matthew D. Fuller's message of "Sat, 22 Nov 2014 22:21:41 -0600") Message-ID: <86sih9a9sy.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 21:25:57 -0000 "Matthew D. Fuller" writes: > Dag-Erling Sm=C3=B8rgrav writes: > > The flower said I wish I were a tree / the tree said I wish I could be a > > different kind of tree /the cat wished that it was a bee / the SO wished > > that he could kill / rsh and rlogin... > Obviously that should be 'rloginD', to preserve the rhyme and > scansion. Why don't we have a Poetry Officer to supervise this stuff? I got hung up on the original lyrics ("the turtle wished that it could fly / really high into the sky / over rooftops and then dive / deep into the sea") and gave up trying to make mine rhyme or scan. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sun Nov 23 23:14:41 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 063D91FE for ; Sun, 23 Nov 2014 23:14:41 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CFC33E8 for ; Sun, 23 Nov 2014 23:14:40 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id h11so4123998wiw.3 for ; Sun, 23 Nov 2014 15:14:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=Vb5wKYpLJNIMaYIJ3b01JmwV5ogHQDqcoXW+qOlbAeE=; b=Z3y7wnWBcEIAjy5RAw1/li9qjDgtpWD19GJi3UTMFngDuDUzClO7pJ1MkrOSXhOaZX nK0y9jGOaSKbXNME6u/6MvKTwaAd89zvR7/ZaqoDJPYiSDXg7LZfcnWpl0Xa5jbizFQT mGc0PQvmCs//EZA18A3GxSOoeYfNpXOBpYm5jHSFVQ2wGyNJZmvVJWiXhe2hudqzBePh IrVhg8oJhfD5FondioWxkgqiMnZRUS01AmSMBk9CfA/H1jRzNeca6cZLbEhoCEZk4thA 8jbH6BGXkzg/7kIHNLN8Px9ARih9xVKXOR53mj9eGeTofk4r76r0iUHKh7Yp0wqYdKBq xgjQ== X-Received: by 10.180.78.73 with SMTP id z9mr16151619wiw.52.1416784478915; Sun, 23 Nov 2014 15:14:38 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id r10sm9547586wiy.13.2014.11.23.15.14.37 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 23 Nov 2014 15:14:38 -0800 (PST) Date: Mon, 24 Nov 2014 00:14:35 +0100 From: Mateusz Guzik To: freebsd-arch@freebsd.org Subject: rarely changing process-wide data vs threads Message-ID: <20141123231435.GA32084@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 23:14:41 -0000 Currently we have some things frequently accessed which require locking, even though they very rarely change. This includes: - cwd, root, jdir vnodes - resource limits File lookup typically requires us to vref and unref cwd and root dir and locking filedesc lock shared which competes with fd open/close in other threads. Any resource limit checks requires taking PROC_LOCK, which is an exclusive lock. Turns out we already have a nice solution which only needs some minor refining and it was used to manage credentials: Each thread has a reference on active credentials and has its own pointer. When credentials are updated, a new structure is allocated and threads check that they got the right pointer on syscall boundary. If they got the wrong one, they lock PROC_LOCK and update. We can make this more general to suit other needs with an introduction of 'generation' counter and optionally an rwlock instead of using PROC_LOCK. If 'generation' is unequal to what is set in the process, at least one of creds/dirs/rlimits/$something needs updating and we can take the lock and iterate over structs. This may pose some concern since it may seem this introduces a window where given thread uses stale data while a concurrently executing thread uses new one. This window is already present for all users that I can see. During file lookups filedesc lock is only temporarily held (and current code even has a possible use after free since it does not start with refing root vnode while fdp is locked so it can be freed/recycled). resource limits are inherently racy anyway. proc lock is held only for a short them to read them, that's it. As such, I don't believe this approach introduces any new windows (although it extends already existing ones). When it comes to implementation of this concept for dir vnodes, one would need to split current struct filedesc. chdir in threaded processes would be more expensive since new struct would have to be allocated and vnodes vrefed, but chdirs are way less frequent than lookups so it should be worth it anyway. There is also a note on filedescs shared between processes. In such cases we would abandon this optimisation (dir struct can have a flag to note cow is not suitable and lookups need to vref like they do now). Comments? -- Mateusz Guzik From owner-freebsd-arch@FreeBSD.ORG Mon Nov 24 02:16:45 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBAA792C for ; Mon, 24 Nov 2014 02:16:45 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9210C7C5 for ; Mon, 24 Nov 2014 02:16:45 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NFI00LCRUAM9O30@st11p02mm-asmtp001.mac.com> for freebsd-arch@freebsd.org; Mon, 24 Nov 2014 02:16:00 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.28,0.0.0000 definitions=2014-11-24_01:2014-11-21,2014-11-23,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411240020 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: rarely changing process-wide data vs threads From: Rui Paulo In-reply-to: <20141123231435.GA32084@dft-labs.eu> Date: Sun, 23 Nov 2014 18:15:58 -0800 Content-transfer-encoding: quoted-printable Message-id: <7683D4D1-9458-48D1-A4DF-602E2C4D13C2@me.com> References: <20141123231435.GA32084@dft-labs.eu> To: Mateusz Guzik X-Mailer: Apple Mail (2.1993) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 02:16:45 -0000 On Nov 23, 2014, at 15:14, Mateusz Guzik wrote: >=20 > Currently we have some things frequently accessed which require > locking, even though they very rarely change. >=20 > This includes: > - cwd, root, jdir vnodes > - resource limits >=20 > File lookup typically requires us to vref and unref cwd and root dir = and > locking filedesc lock shared which competes with fd open/close in = other > threads. >=20 > Any resource limit checks requires taking PROC_LOCK, which is an > exclusive lock. >=20 > Turns out we already have a nice solution which only needs some minor > refining and it was used to manage credentials: >=20 > Each thread has a reference on active credentials and has its own > pointer. When credentials are updated, a new structure is allocated = and > threads check that they got the right pointer on syscall boundary. If > they got the wrong one, they lock PROC_LOCK and update. >=20 > We can make this more general to suit other needs with an introduction > of 'generation' counter and optionally an rwlock instead of using > PROC_LOCK. If 'generation' is unequal to what is set in the process, > at least one of creds/dirs/rlimits/$something needs updating and we = can > take the lock and iterate over structs. Right, this is the same model used by the routing table. > This may pose some concern since it may seem this introduces a window > where given thread uses stale data while a concurrently executing = thread > uses new one. Likewise there's a small race for the networking stack. > This window is already present for all users that I can see. >=20 > During file lookups filedesc lock is only temporarily held (and = current > code even has a possible use after free since it does not start with > refing root vnode while fdp is locked so it can be freed/recycled). >=20 > resource limits are inherently racy anyway. proc lock is held only for = a > short them to read them, that's it. >=20 > As such, I don't believe this approach introduces any new windows > (although it extends already existing ones). I agree. > When it comes to implementation of this concept for dir vnodes, one > would need to split current struct filedesc. chdir in threaded = processes > would be more expensive since new struct would have to be allocated = and > vnodes vrefed, but chdirs are way less frequent than lookups so it > should be worth it anyway. I agree. A lookup is a different operation but most of the time a chdir = is followed by a lookup, so if we optimise the lookup case the end = result might still be better. > There is also a note on filedescs shared between processes. In such > cases we would abandon this optimisation (dir struct can have a flag = to > note cow is not suitable and lookups need to vref like they do now). Are you talking about your optimisation or something that's already = there? -- Rui Paulo From owner-freebsd-arch@FreeBSD.ORG Mon Nov 24 03:13:17 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 958583A3 for ; Mon, 24 Nov 2014 03:13:17 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 260FFDC6 for ; Mon, 24 Nov 2014 03:13:17 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id r20so4295998wiv.12 for ; Sun, 23 Nov 2014 19:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=SCckZKqaNoYMPNu37JdlD/OKaIPRXg7kznvqKOa91Uo=; b=ylIiRJ9/ymmAkESxsVWZ4wPnoXDAqAIyppLWuCa5F7RNTo44FzQNeWm5h4iWwhRaVI CfKZewxf0g6Iu53R7eK7OK+iSM6wV6IvXlq4jXP3MRYdtN0GJtcXNxcypUd32pH5WdXW e7Zcvq5NBE8konbIS/WLcZNcyDjzxBDPmZ9hTGReEjWYFEND9GHvdfn40E7bEAQi0xz+ 7DSk7Y16WViFlHBjsGRaz3qVc6IzkRCqovbSvOtQFdfvvjNYEG3XlTVKsjW3fIniuVzH Mp0zHMP+H95QRWE2k+GUAunbs5mkH5Lx/AdNYJPBoVzNyNm8ITQTQ9vmyflSjwtWnqkm zrvw== X-Received: by 10.180.102.135 with SMTP id fo7mr17871443wib.79.1416798795558; Sun, 23 Nov 2014 19:13:15 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id u9sm11859201wjy.37.2014.11.23.19.13.14 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 23 Nov 2014 19:13:14 -0800 (PST) Date: Mon, 24 Nov 2014 04:13:12 +0100 From: Mateusz Guzik To: Rui Paulo Subject: Re: rarely changing process-wide data vs threads Message-ID: <20141124031312.GA6985@dft-labs.eu> References: <20141123231435.GA32084@dft-labs.eu> <7683D4D1-9458-48D1-A4DF-602E2C4D13C2@me.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7683D4D1-9458-48D1-A4DF-602E2C4D13C2@me.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 03:13:17 -0000 On Sun, Nov 23, 2014 at 06:15:58PM -0800, Rui Paulo wrote: > On Nov 23, 2014, at 15:14, Mateusz Guzik wrote: > > There is also a note on filedescs shared between processes. In such > > cases we would abandon this optimisation (dir struct can have a flag to > > note cow is not suitable and lookups need to vref like they do now). > > Are you talking about your optimisation or something that's already there? > I'm saying if the table is shared between processes just vrefing like we do now is the simplest way to go. This feature has to remain operational and there are no problems ensuring so. -- Mateusz Guzik From owner-freebsd-arch@FreeBSD.ORG Mon Nov 24 05:28:22 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08E3E397 for ; Mon, 24 Nov 2014 05:28:22 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9FE13AC5 for ; Mon, 24 Nov 2014 05:28:20 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XsmCB-00044r-5t; Mon, 24 Nov 2014 05:28:19 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAO5SGHf009664; Sun, 23 Nov 2014 22:28:17 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+/3X4ykeYBUI+C1pMiuLG8 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Ian Lepore To: Mark R V Murray In-Reply-To: <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> Content-Type: multipart/mixed; boundary="=-NTbRHXDDO6bb9n80THD/" Date: Sun, 23 Nov 2014 22:28:14 -0700 Message-ID: <1416806894.1147.362.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 05:28:22 -0000 --=-NTbRHXDDO6bb9n80THD/ Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sAO5SGHf009664 On Sat, 2014-11-22 at 22:55 +0000, Mark R V Murray wrote: > > On 22 Nov 2014, at 21:21, Ian Lepore wrote: > >> We now have automatic unblocking back (which is *precisely* what you > >=20 > > I noted that in one of my replies, and also said that it appeared fro= m > > this thread that that was considered a temporary action which would b= e > > undone. Nobody contradicted that until now. >=20 > This is Yarrow-specific. As Yarrow is no longer recommended by its > designers, it should be considered deprecated. >=20 > Fortuna gets going much quicker than Yarrow; have you tried this like > I asked? >=20 > >> wanted), and I am willing to allow a tunable to turn it off, but I w= ill > >> not allow disabling it by default, because I believe it is better th= an > >=20 > > That's all I ever asked for, from day one, and this is the first > > non-negative response to it I can remember. I never asked for it to = be > > disabled by default. I asked for a knob. I asked for it to possibil= y > > take multiple knobs, or anything else reasonable to make it difficult= to > > do the wrong thing by accident. >=20 > See above and my other mail (the one you didn=A2t answer). >=20 > M I've been unable to boot -current on one of these low-end arm boards for quite a while. Today I finally found a few hours to debug that and get it at least to the point of trying to mount root, where it hangs apparently forever. I don't think that has anything to do with random stuff, it's probably just more buggage in the atmel arm stuff that I need to dig into. But I got some logging that maybe will be useful to you, attached. This is the boot logging from hitting the reset button 4 times in a row. I had RANDOM_DEBUG and FORTUNA options on. In the random debugging printf for device attach I added a display of the actual bits being fed in as well as the count. That data in tabular form (from 3 of the 4 runs so it fits email width) is interesting: nexus0: 0x00000010c6f7a0b6 0x00000010c6f7a0b6 0x00000010c6f7a0b6 at91_aic0: 0x00000010c6f7a0b6 0x00000010c6f7a0b6 0x00000010c6f7a0b6 at91_pmc0: 0x00000010c6f7a0b6 0x00000010c6f7a0b6 0x00000010c6f7a0b6 at91_st0: 0x0000003254e6e222 0x0000003254e6e222 0x0000003254e6e222 mmc0: 0x0000000000000000 0x0000000000000000 0x0000020000000000 at91_mci0: 0x0004480000000000 0x0004480000000000 0x00044e0000000000 ukphy0: 0x0001980000000000 0x00019a0000000000 0x0001960000000000 miibus0: 0x00060a0000000000 0x00060c0000000000 0x00060a0000000000 ate0: 0x000d260000000000 0x000d280000000000 0x000d2a0000000000 uart0: 0x0001400000000000 0x0001400000000000 0x0001400000000000 atmelarm0: 0x00231cc9539b8887 0x00231ec9539b8887 0x002328c9539b8887 mmcsd0: 0x0002620000000000 0x0002620000000000 0x0002620000000000 This nicely illustrates one of the main points I've been trying to make for a long time: This kind of system boots nearly identically every time you power on or reset. On every boot, all that "entropy" that's getting fed in is about the same as last time it booted. In addition to the low quantity of data available, when you consider its similarity from one reboot to the next it's hard to even grace it with the name "entropy." -- Ian --=-NTbRHXDDO6bb9n80THD/ Content-Disposition: attachment; filename="boot_random_debug.txt" Content-Type: text/plain; name="boot_random_debug.txt"; charset="us-ascii" Content-Transfer-Encoding: 7bit TSC board boot Default: /boot/kernel/kernel.gz.tramp boot: GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2014 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 11.0-CURRENT #8 r274946M: Sun Nov 23 21:36:52 MST 2014 ilepore@revolution.hippie.lan:/local/build/staging/freebsd/rm92/obj/arm.arm/local/build/staging/freebsd/rm92/src/sys/TFLEX arm FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: ARM920T rev 0 (ARM9TDMI core) Little-endian DC enabled IC enabled WB enabled LABT branch prediction disabled 16KB/32B 64-way instruction cache 16KB/32B 64-way write-back-locking-A data cache real memory = 67108864 (64 MB) avail memory = 59838464 (57 MB) random device not loaded/active; using insecure pseudo-random number generator random: entropy device infrastructure driver random: random_adaptors_init random: selecting highest priority adaptor random: random_adaptor_choose - changing from NULL to Dummy random: dummy_random_init random: SOFT: fortuna init() random: selecting highest priority adaptor random: random_adaptor_choose - changing from Dummy to Fortuna random: random_harvestq_init random: device_attach(): feeding 4 bit(s) of entropy from nexus0: 0x00000010c6f7a0b6 atmelarm0: at91_aic0: mem 0xfffff000-0xfffff1ff on atmelarm0 at91_aic0: Attach 2147483647 random: device_attach(): feeding 4 bit(s) of entropy from at91_aic0: 0x00000010c6f7a0b6 at91_pmc0: mem 0xfffffc00-0xfffffcff irq 1 on atmelarm0 at91_pmc0: Primary: 16000000 Hz PLLA: 180 MHz CPU: 180 MHz MCK: 90 MHz random: device_attach(): feeding 4 bit(s) of entropy from at91_pmc0: 0x00000010c6f7a0b6 at91_st0: mem 0xfffffd00-0xfffffdff irq 1 on atmelarm0 at91_st0: watchdog registered, timeout intervall max. 64 sec at91_st0: Cannot get 100 Hz clock; using 100Hz Timecounter "AT91RM9200 timer" frequency 32768 Hz quality 1000 random: device_attach(): feeding 4 bit(s) of entropy from at91_st0: 0x0000003254e6e222 at91_mci0: mem 0xfffb4000-0xfffb7fff irq 10 on atmelarm0 mmc0: on at91_mci0 random: device_attach(): feeding 4 bit(s) of entropy from mmc0: 0x0000000000000000 random: device_attach(): feeding 4 bit(s) of entropy from at91_mci0: 0x0004480000000000 ate0: mem 0xfffbc000-0xfffbffff irq 24 on atmelarm0 miibus0: on ate0 ukphy0: PHY 0 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto random: device_attach(): feeding 4 bit(s) of entropy from ukphy0: 0x0001980000000000 random: device_attach(): feeding 4 bit(s) of entropy from miibus0: 0x00060a0000000000 ate0: Ethernet address: 42:53:44:00:00:01 random: device_attach(): feeding 4 bit(s) of entropy from ate0: 0x000d260000000000 uart0: mem 0xfffff200-0xfffff3ff irq 1 on atmelarm0 uart0: console (115200,n,8,1) random: device_attach(): feeding 4 bit(s) of entropy from uart0: 0x0001400000000000 random: device_attach(): feeding 4 bit(s) of entropy from atmelarm0: 0x00231cc9539b8887 Timecounters tick every 10.000 msec mmcsd0: 8GB at mmc0 22.5MHz/1bit/64-block random: device_attach(): feeding 4 bit(s) of entropy from mmcsd0: 0x0002620000000000 Trying to mount root from ufs:/dev/mmcsd0s1a []... warning: no time-of-day clock registered, system time will not be set accurately TSC board boot Default: /boot/kernel/kernel.gz.tramp boot: GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2014 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 11.0-CURRENT #8 r274946M: Sun Nov 23 21:36:52 MST 2014 ilepore@revolution.hippie.lan:/local/build/staging/freebsd/rm92/obj/arm.arm/local/build/staging/freebsd/rm92/src/sys/TFLEX arm FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: ARM920T rev 0 (ARM9TDMI core) Little-endian DC enabled IC enabled WB enabled LABT branch prediction disabled 16KB/32B 64-way instruction cache 16KB/32B 64-way write-back-locking-A data cache real memory = 67108864 (64 MB) avail memory = 59838464 (57 MB) random device not loaded/active; using insecure pseudo-random number generator random: entropy device infrastructure driver random: random_adaptors_init random: selecting highest priority adaptor random: random_adaptor_choose - changing from NULL to Dummy random: dummy_random_init random: SOFT: fortuna init() random: selecting highest priority adaptor random: random_adaptor_choose - changing from Dummy to Fortuna random: random_harvestq_init random: device_attach(): feeding 4 bit(s) of entropy from nexus0: 0x00000010c6f7a0b6 atmelarm0: at91_aic0: mem 0xfffff000-0xfffff1ff on atmelarm0 at91_aic0: Attach 2147483647 random: device_attach(): feeding 4 bit(s) of entropy from at91_aic0: 0x00000010c6f7a0b6 at91_pmc0: mem 0xfffffc00-0xfffffcff irq 1 on atmelarm0 at91_pmc0: Primary: 16000000 Hz PLLA: 180 MHz CPU: 180 MHz MCK: 90 MHz random: device_attach(): feeding 4 bit(s) of entropy from at91_pmc0: 0x00000010c6f7a0b6 at91_st0: mem 0xfffffd00-0xfffffdff irq 1 on atmelarm0 at91_st0: watchdog registered, timeout intervall max. 64 sec at91_st0: Cannot get 100 Hz clock; using 100Hz Timecounter "AT91RM9200 timer" frequency 32768 Hz quality 1000 random: device_attach(): feeding 4 bit(s) of entropy from at91_st0: 0x0000003254e6e222 at91_mci0: mem 0xfffb4000-0xfffb7fff irq 10 on atmelarm0 mmc0: on at91_mci0 random: device_attach(): feeding 4 bit(s) of entropy from mmc0: 0x0000000000000000 random: device_attach(): feeding 4 bit(s) of entropy from at91_mci0: 0x0004480000000000 ate0: mem 0xfffbc000-0xfffbffff irq 24 on atmelarm0 miibus0: on ate0 ukphy0: PHY 0 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto random: device_attach(): feeding 4 bit(s) of entropy from ukphy0: 0x00019a0000000000 random: device_attach(): feeding 4 bit(s) of entropy from miibus0: 0x00060c0000000000 ate0: Ethernet address: 42:53:44:00:00:01 random: device_attach(): feeding 4 bit(s) of entropy from ate0: 0x000d280000000000 uart0: mem 0xfffff200-0xfffff3ff irq 1 on atmelarm0 uart0: console (115200,n,8,1) random: device_attach(): feeding 4 bit(s) of entropy from uart0: 0x0001400000000000 random: device_attach(): feeding 4 bit(s) of entropy from atmelarm0: 0x00231ec9539b8887 Timecounters tick every 10.000 msec mmcsd0: 8GB at mmc0 22.5MHz/1bit/64-block random: device_attach(): feeding 4 bit(s) of entropy from mmcsd0: 0x0002620000000000 Trying to mount root from ufs:/dev/mmcsd0s1a []... warning: no time-of-day clock registered, system time will not be set accurately TSC board boot Default: /boot/kernel/kernel.gz.tramp boot: GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2014 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 11.0-CURRENT #8 r274946M: Sun Nov 23 21:36:52 MST 2014 ilepore@revolution.hippie.lan:/local/build/staging/freebsd/rm92/obj/arm.arm/local/build/staging/freebsd/rm92/src/sys/TFLEX arm FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: ARM920T rev 0 (ARM9TDMI core) Little-endian DC enabled IC enabled WB enabled LABT branch prediction disabled 16KB/32B 64-way instruction cache 16KB/32B 64-way write-back-locking-A data cache real memory = 67108864 (64 MB) avail memory = 59838464 (57 MB) random device not loaded/active; using insecure pseudo-random number generator random: entropy device infrastructure driver random: random_adaptors_init random: selecting highest priority adaptor random: random_adaptor_choose - changing from NULL to Dummy random: dummy_random_init random: SOFT: fortuna init() random: selecting highest priority adaptor random: random_adaptor_choose - changing from Dummy to Fortuna random: random_harvestq_init random: device_attach(): feeding 4 bit(s) of entropy from nexus0: 0x00000010c6f7a0b6 atmelarm0: at91_aic0: mem 0xfffff000-0xfffff1ff on atmelarm0 at91_aic0: Attach 2147483647 random: device_attach(): feeding 4 bit(s) of entropy from at91_aic0: 0x00000010c6f7a0b6 at91_pmc0: mem 0xfffffc00-0xfffffcff irq 1 on atmelarm0 at91_pmc0: Primary: 16000000 Hz PLLA: 180 MHz CPU: 180 MHz MCK: 90 MHz random: device_attach(): feeding 4 bit(s) of entropy from at91_pmc0: 0x00000010c6f7a0b6 at91_st0: mem 0xfffffd00-0xfffffdff irq 1 on atmelarm0 at91_st0: watchdog registered, timeout intervall max. 64 sec at91_st0: Cannot get 100 Hz clock; using 100Hz Timecounter "AT91RM9200 timer" frequency 32768 Hz quality 1000 random: device_attach(): feeding 4 bit(s) of entropy from at91_st0: 0x0000003254e6e222 at91_mci0: mem 0xfffb4000-0xfffb7fff irq 10 on atmelarm0 mmc0: on at91_mci0 random: device_attach(): feeding 4 bit(s) of entropy from mmc0: 0x0000020000000000 random: device_attach(): feeding 4 bit(s) of entropy from at91_mci0: 0x00044e0000000000 ate0: mem 0xfffbc000-0xfffbffff irq 24 on atmelarm0 miibus0: on ate0 ukphy0: PHY 0 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto random: device_attach(): feeding 4 bit(s) of entropy from ukphy0: 0x0001980000000000 random: device_attach(): feeding 4 bit(s) of entropy from miibus0: 0x00060c0000000000 ate0: Ethernet address: 42:53:44:00:00:01 random: device_attach(): feeding 4 bit(s) of entropy from ate0: 0x000d2e0000000000 uart0: mem 0xfffff200-0xfffff3ff irq 1 on atmelarm0 uart0: console (115200,n,8,1) random: device_attach(): feeding 4 bit(s) of entropy from uart0: 0x0001400000000000 random: device_attach(): feeding 4 bit(s) of entropy from atmelarm0: 0x00232ac9539b8887 Timecounters tick every 10.000 msec mmcsd0: 8GB at mmc0 22.5MHz/1bit/64-block random: device_attach(): feeding 4 bit(s) of entropy from mmcsd0: 0x0002640000000000 Trying to mount root from ufs:/dev/mmcsd0s1a []... warning: no time-of-day clock registered, system time will not be set accurately TSC board boot Default: /boot/kernel/kernel.gz.tramp boot: GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2014 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 11.0-CURRENT #8 r274946M: Sun Nov 23 21:36:52 MST 2014 ilepore@revolution.hippie.lan:/local/build/staging/freebsd/rm92/obj/arm.arm/local/build/staging/freebsd/rm92/src/sys/TFLEX arm FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: ARM920T rev 0 (ARM9TDMI core) Little-endian DC enabled IC enabled WB enabled LABT branch prediction disabled 16KB/32B 64-way instruction cache 16KB/32B 64-way write-back-locking-A data cache real memory = 67108864 (64 MB) avail memory = 59838464 (57 MB) random device not loaded/active; using insecure pseudo-random number generator random: entropy device infrastructure driver random: random_adaptors_init random: selecting highest priority adaptor random: random_adaptor_choose - changing from NULL to Dummy random: dummy_random_init random: SOFT: fortuna init() random: selecting highest priority adaptor random: random_adaptor_choose - changing from Dummy to Fortuna random: random_harvestq_init random: device_attach(): feeding 4 bit(s) of entropy from nexus0: 0x00000010c6f7a0b6 atmelarm0: at91_aic0: mem 0xfffff000-0xfffff1ff on atmelarm0 at91_aic0: Attach 2147483647 random: device_attach(): feeding 4 bit(s) of entropy from at91_aic0: 0x00000010c6f7a0b6 at91_pmc0: mem 0xfffffc00-0xfffffcff irq 1 on atmelarm0 at91_pmc0: Primary: 16000000 Hz PLLA: 180 MHz CPU: 180 MHz MCK: 90 MHz random: device_attach(): feeding 4 bit(s) of entropy from at91_pmc0: 0x00000010c6f7a0b6 at91_st0: mem 0xfffffd00-0xfffffdff irq 1 on atmelarm0 at91_st0: watchdog registered, timeout intervall max. 64 sec at91_st0: Cannot get 100 Hz clock; using 100Hz Timecounter "AT91RM9200 timer" frequency 32768 Hz quality 1000 random: device_attach(): feeding 4 bit(s) of entropy from at91_st0: 0x0000003254e6e222 at91_mci0: mem 0xfffb4000-0xfffb7fff irq 10 on atmelarm0 mmc0: on at91_mci0 random: device_attach(): feeding 4 bit(s) of entropy from mmc0: 0x0000020000000000 random: device_attach(): feeding 4 bit(s) of entropy from at91_mci0: 0x00044e0000000000 ate0: mem 0xfffbc000-0xfffbffff irq 24 on atmelarm0 miibus0: on ate0 ukphy0: PHY 0 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto random: device_attach(): feeding 4 bit(s) of entropy from ukphy0: 0x0001960000000000 random: device_attach(): feeding 4 bit(s) of entropy from miibus0: 0x00060a0000000000 ate0: Ethernet address: 42:53:44:00:00:01 random: device_attach(): feeding 4 bit(s) of entropy from ate0: 0x000d2a0000000000 uart0: mem 0xfffff200-0xfffff3ff irq 1 on atmelarm0 uart0: console (115200,n,8,1) random: device_attach(): feeding 4 bit(s) of entropy from uart0: 0x0001400000000000 random: device_attach(): feeding 4 bit(s) of entropy from atmelarm0: 0x002328c9539b8887 Timecounters tick every 10.000 msec mmcsd0: 8GB at mmc0 22.5MHz/1bit/64-block random: device_attach(): feeding 4 bit(s) of entropy from mmcsd0: 0x0002620000000000 Trying to mount root from ufs:/dev/mmcsd0s1a []... warning: no time-of-day clock registered, system time will not be set accurately --=-NTbRHXDDO6bb9n80THD/-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 24 07:53:22 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8AA9C23; Mon, 24 Nov 2014 07:53:22 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B4FEAF8; Mon, 24 Nov 2014 07:53:22 +0000 (UTC) Received: from [2001:470:9174:1:20:a85c:9bd2:23e4] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XsoSV-0001Ie-AR; Mon, 24 Nov 2014 07:53:19 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <1416806894.1147.362.camel@revolution.hippie.lan> Date: Mon, 24 Nov 2014 07:53:18 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 07:53:22 -0000 > On 24 Nov 2014, at 05:28, Ian Lepore wrote: >=20 > But I got some logging that maybe will be useful to you, attached. = This > is the boot logging from hitting the reset button 4 times in a row. I > had RANDOM_DEBUG and FORTUNA options on. Thanks. > In the random debugging printf for device attach I added a display of > the actual bits being fed in as well as the count. That data in = tabular > form (from 3 of the 4 runs so it fits email width) is interesting: >=20 > nexus0: 0x00000010c6f7a0b6 0x00000010c6f7a0b6 0x00000010c6f7a0b6 > at91_aic0: 0x00000010c6f7a0b6 0x00000010c6f7a0b6 0x00000010c6f7a0b6 > at91_pmc0: 0x00000010c6f7a0b6 0x00000010c6f7a0b6 0x00000010c6f7a0b6 > at91_st0: 0x0000003254e6e222 0x0000003254e6e222 0x0000003254e6e222 > mmc0: 0x0000000000000000 0x0000000000000000 0x0000020000000000 > at91_mci0: 0x0004480000000000 0x0004480000000000 0x00044e0000000000 > ukphy0: 0x0001980000000000 0x00019a0000000000 0x0001960000000000 > miibus0: 0x00060a0000000000 0x00060c0000000000 0x00060a0000000000 > ate0: 0x000d260000000000 0x000d280000000000 0x000d2a0000000000 > uart0: 0x0001400000000000 0x0001400000000000 0x0001400000000000 > atmelarm0: 0x00231cc9539b8887 0x00231ec9539b8887 0x002328c9539b8887 > mmcsd0: 0x0002620000000000 0x0002620000000000 0x0002620000000000 Those numbers look weird; please send a diff of your change. The number of devices probed is also low. When you get the booting problem sorted, there are some constants that we could change that may help. > This nicely illustrates one of the main points I've been trying to = make > for a long time: This kind of system boots nearly identically every > time you power on or reset. On every boot, all that "entropy" that's > getting fed in is about the same as last time it booted. In addition = to > the low quantity of data available, when you consider its similarity > from one reboot to the next it's hard to even grace it with the name > "entropy.=E2=80=9D I=E2=80=99m well aware of that; I=E2=80=99ve been saying something = similar since at least 2000. M --=20 Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Mon Nov 24 15:01:12 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2290AB1 for ; Mon, 24 Nov 2014 15:01:12 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5973F70 for ; Mon, 24 Nov 2014 15:01:11 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xsv8Y-000KOE-Nm; Mon, 24 Nov 2014 15:01:10 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAOF18Zh010751; Mon, 24 Nov 2014 08:01:09 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+z4PgXnfGQzilg7j9pEo8M X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Ian Lepore To: Mark R V Murray In-Reply-To: <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> Content-Type: text/plain; charset="iso-8859-13" Date: Mon, 24 Nov 2014 08:01:08 -0700 Message-ID: <1416841268.1147.386.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sAOF18Zh010751 Cc: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 15:01:12 -0000 On Mon, 2014-11-24 at 07:53 +0000, Mark R V Murray wrote: > > On 24 Nov 2014, at 05:28, Ian Lepore wrote: > >=20 > > But I got some logging that maybe will be useful to you, attached. T= his > > is the boot logging from hitting the reset button 4 times in a row. = I > > had RANDOM_DEBUG and FORTUNA options on. >=20 > Thanks. >=20 > > In the random debugging printf for device attach I added a display of > > the actual bits being fed in as well as the count. That data in tabu= lar > > form (from 3 of the 4 runs so it fits email width) is interesting: > >=20 > > nexus0: 0x00000010c6f7a0b6 0x00000010c6f7a0b6 0x00000010c6f7a0b6 > > at91_aic0: 0x00000010c6f7a0b6 0x00000010c6f7a0b6 0x00000010c6f7a0b6 > > at91_pmc0: 0x00000010c6f7a0b6 0x00000010c6f7a0b6 0x00000010c6f7a0b6 > > at91_st0: 0x0000003254e6e222 0x0000003254e6e222 0x0000003254e6e222 > > mmc0: 0x0000000000000000 0x0000000000000000 0x0000020000000000 > > at91_mci0: 0x0004480000000000 0x0004480000000000 0x00044e0000000000 > > ukphy0: 0x0001980000000000 0x00019a0000000000 0x0001960000000000 > > miibus0: 0x00060a0000000000 0x00060c0000000000 0x00060a0000000000 > > ate0: 0x000d260000000000 0x000d280000000000 0x000d2a0000000000 > > uart0: 0x0001400000000000 0x0001400000000000 0x0001400000000000 > > atmelarm0: 0x00231cc9539b8887 0x00231ec9539b8887 0x002328c9539b8887 > > mmcsd0: 0x0002620000000000 0x0002620000000000 0x0002620000000000 >=20 > Those numbers look weird; please send a diff of your change. >=20 > The number of devices probed is also low. When you get the booting > problem sorted, there are some constants that we could change that > may help. >=20 > > This nicely illustrates one of the main points I've been trying to ma= ke > > for a long time: This kind of system boots nearly identically every > > time you power on or reset. On every boot, all that "entropy" that's > > getting fed in is about the same as last time it booted. In addition= to > > the low quantity of data available, when you consider its similarity > > from one reboot to the next it's hard to even grace it with the name > > "entropy.=A1 >=20 > I=FFm well aware of that; I=FFve been saying something similar since at > least 2000. >=20 > M The logging change was pretty simple: Index: kern/subr_bus.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 --- kern/subr_bus.c (revision 274946) +++ kern/subr_bus.c (working copy) @@ -2851,8 +2851,8 @@ device_attach(device_t dev) * need to be adjusted on other platforms. */ #ifdef RANDOM_DEBUG - printf("random: %s(): feeding %d bit(s) of entropy from %s%d\n", - __func__, 4, dev->driver->name, dev->unit); + printf("random: %s(): feeding %d bit(s) of entropy from %s%d: 0x%016llx= \n", + __func__, 4, dev->driver->name, dev->unit, attachtime); #endif random_harvest(&attachtime, sizeof(attachtime), 4, RANDOM_ATTACH); device_sysctl_update(dev); The low number of devices is pretty typical. Sometimes there'll be another uart. Sometimes an i2c eeprom. =20 I have no idea what's up with the first 3 unchanging numbers, but I suspect a big part of the explanation for the other numbers is the 32KHz clock it's getting the numbers from. There used to be a clock running at about 2.8MHz, but the source code for that driver seems to have disappeared from FreeBSD at some point between 8.x and -current. -- Ian From owner-freebsd-arch@FreeBSD.ORG Mon Nov 24 17:03:57 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B17AB2B9; Mon, 24 Nov 2014 17:03:57 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 60DA4FD1; Mon, 24 Nov 2014 17:03:56 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sAOH3i8Z014319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 24 Nov 2014 09:03:46 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <547364EB.7090505@freebsd.org> Date: Tue, 25 Nov 2014 01:03:39 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" , Craig Rodrigues Subject: Re: RFC: Enabling VIMAGE in GENERIC References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> In-Reply-To: <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Net , Marko Zec , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:03:57 -0000 On 11/20/14, 8:33 AM, Bjoern A. Zeeb wrote: > On 19 Nov 2014, at 23:14 , Craig Rodrigues wrote: > >> On Wed, Nov 19, 2014 at 11:59 AM, John-Mark Gurney wrote: >> >>> Yes, we need a man page talking about this feature first, how to enable >>> it, compile it into the kernel, how to manage it, what subsystems it >>> interacts w/, what sysctl nodes it provides, etc. >>> >> Marko, >> >> Do you have any text which can be put into a vnet(9) man page? >> It doesn't have to be perfect, but just something that we can start from. >> >> I tried looking at some of the notes and presentations that you have done >> on VIMAGE: >> https://wiki.freebsd.org/?action=fullsearch&context=180&value=VIMAGE&titlesearch=Titles >> >> but didn’t see anything that could be readily turned into a man page. > > https://people.freebsd.org/~bz/20100530-02.vnet.9.html > > The man page should be in that perforce branch you converted to github. also look at the following: (a little dated) http://p4web.freebsd.org/@md=d&cd=//depot/projects/vimage/&cdf=//depot/projects/vimage/porting_to_vimage.txt&c=tO0@//depot/projects/vimage/porting_to_vimage.txt?ac=22 > > — > Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > From owner-freebsd-arch@FreeBSD.ORG Mon Nov 24 19:15:27 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41C373B0; Mon, 24 Nov 2014 19:15:27 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02DE22AE; Mon, 24 Nov 2014 19:15:27 +0000 (UTC) Received: from [2001:470:9174:1:20:a85c:9bd2:23e4] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xsz6a-0002Go-7i; Mon, 24 Nov 2014 19:15:24 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <1416841268.1147.386.camel@revolution.hippie.lan> Date: Mon, 24 Nov 2014 19:15:22 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 19:15:27 -0000 > On 24 Nov 2014, at 15:01, Ian Lepore wrote: >=20 >=20 > The logging change was pretty simple: >=20 > Index: kern/subr_bus.c Thanks. > The low number of devices is pretty typical. Sometimes there'll be > another uart. Sometimes an i2c eeprom. OK - a good example of a low-entropy system then. > I have no idea what's up with the first 3 unchanging numbers, but I > suspect a big part of the explanation for the other numbers is the = 32KHz > clock it's getting the numbers from. There used to be a clock running > at about 2.8MHz, but the source code for that driver seems to have > disappeared from FreeBSD at some point between 8.x and -current. What really bothers me is that these should be the difference between 2 = essentially similar numbers; times not all that far apart, yet some of = the numbers are truly massive. I don=E2=80=99t know how that could be the case. Its *WEIRD*. :-( M --=20 Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Mon Nov 24 22:37:42 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBD15697 for ; Mon, 24 Nov 2014 22:37:42 +0000 (UTC) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 59125DA1 for ; Mon, 24 Nov 2014 22:37:41 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.9/8.14.9/ALCHEMY.FRANKEN.DE) with ESMTP id sAOMbVLD054705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Nov 2014 23:37:32 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.9/8.14.9/Submit) id sAOMbVhX054704; Mon, 24 Nov 2014 23:37:31 +0100 (CET) (envelope-from marius) Date: Mon, 24 Nov 2014 23:37:31 +0100 From: Marius Strobl To: Warner Losh Subject: Re: I'd like to axe some drivers Message-ID: <20141124223731.GA54578@alchemy.franken.de> References: <201411201631.27556.jhb@freebsd.org> <20141120220752.GI24601@funkthat.com> <573D346B-3AB8-4EC7-A03F-1B2B1291A5BC@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573D346B-3AB8-4EC7-A03F-1B2B1291A5BC@bsdimp.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Mon, 24 Nov 2014 23:37:32 +0100 (CET) Cc: arch@freebsd.org, John-Mark Gurney X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 22:37:42 -0000 On Thu, Nov 20, 2014 at 03:37:10PM -0700, Warner Losh wrote: > > On Nov 20, 2014, at 3:07 PM, John-Mark Gurney wrote: > > > I'm fine w/ removing these... Should we do some house cleaning on > > amd64's GENERIC too? > > > > amd64's GENERIC has a lot of ISA or 100Mbit ethernet cards that are > > clearly not going to be used on these machines... > > > > My recommended list to remove: > > ae, bfe, dc, fxp, hme?, pcn, rl, tx, vr, wb, xl, cs, ed, ex, ep, fe, > > sn, xe > > All the PC Card ones (cs, ed, ex, ep, fe, sn, xe) are no brainers to remove > from GENERIC. > > hme is a Sparc-centric card, so can go. > FYI, cas(4) and hme(4) are in the x86 GENERIC kernel config files as the quad-port NIC variants driven by them aren't uncommon to be used with pfSense, which likely is due to the fact that these cards are cheap to get these days and someone writing the following article: http://www.glitchwrks.com/2012/08/03/Quad-Port-PCI-Ethernet-Roundup/ Now why the pfSense project can't have its own kernel config or why modules aren't an alternative I don't really know. Based on some mails I got it seems like the pfSense developers are reluctant to diverging from upstream regarding the former and their users have problems with kernel modules - at least in practice - as pfSense ships without modules and, thus, have to be fetch from FreeBSD install bits, though. Marius From owner-freebsd-arch@FreeBSD.ORG Mon Nov 24 23:16:58 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00E61C64; Mon, 24 Nov 2014 23:16:57 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id AD716188; Mon, 24 Nov 2014 23:16:57 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id EBB02A656; Mon, 24 Nov 2014 23:16:49 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 03795122E; Tue, 25 Nov 2014 00:16:43 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark R V Murray Subject: Re: svn commit: r274739 - head/sys/mips/conf References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> Date: Tue, 25 Nov 2014 00:16:43 +0100 In-Reply-To: (Mark R. V. Murray's message of "Mon, 24 Nov 2014 19:15:22 +0000") Message-ID: <86wq6k9okk.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, Ian Lepore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 23:16:58 -0000 Mark R V Murray writes: >> On 24 Nov 2014, at 15:01, Ian Lepore wrote: >>=20 >>=20 >> The logging change was pretty simple: >>=20 >> Index: kern/subr_bus.c > > Thanks. > >> The low number of devices is pretty typical. Sometimes there'll be >> another uart. Sometimes an i2c eeprom. > > OK - a good example of a low-entropy system then. > >> I have no idea what's up with the first 3 unchanging numbers, but I >> suspect a big part of the explanation for the other numbers is the 32KHz >> clock it's getting the numbers from. There used to be a clock running >> at about 2.8MHz, but the source code for that driver seems to have >> disappeared from FreeBSD at some point between 8.x and -current. > > What really bothers me is that these should be the difference between > 2 essentially similar numbers; times not all that far apart, yet some > of the numbers are truly massive. They're not just massive, they're preposterous, as is the fact that most of them are absolutely identical, or just one bit off, from one run to the next. My best guess is that get_cyclecount() is broken. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Nov 24 23:22:29 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 074DFDD9 for ; Mon, 24 Nov 2014 23:22:29 +0000 (UTC) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0342267 for ; Mon, 24 Nov 2014 23:22:28 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id w10so10610409pde.5 for ; Mon, 24 Nov 2014 15:22:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=w8qZvWxjpbySHjEowuHNHKPEJBoHoFak+k9s+Qx8ErA=; b=STEE2zQJd1EfP1kS4PKmJ+FQdmVqS/WyN9/4j7eDtIdMGg2iEm4qQJTAPv34UbSU4I ggXowN1FRyA4UxmG/4DezgXWFK6FexmJ0ubmbr9dp51JsWcBEemtkALP5aObXbpNjTjQ djSF+knfsMcPXtEkGu6cUsf2Kwk3xnasA6PHFTV2XM037sZ7/yuZrf40q+SoU/z66zue Zps7rVZXq64+Zifl4VO4onlo8sW4fywCqmyeGiiPz8Btycd3Ng/U6t1K60iNee/mgqg+ RcbBMRStbpPk6ElZ1GIkm6Jh3utcyQZlIqOHlsjZ4MPMINPvNY9C+zCovng3iYLs+Ijs fgBw== X-Gm-Message-State: ALoCoQmG6O5vZQRaPSYpVYJrSxqixUyjS+qpQwy1FcNtJTF8k9W0+eyA/hd/uqHoy7HgRrypv515 X-Received: by 10.66.189.101 with SMTP id gh5mr37599476pac.56.1416871347793; Mon, 24 Nov 2014 15:22:27 -0800 (PST) Received: from [10.64.26.139] ([69.53.236.236]) by mx.google.com with ESMTPSA id y10sm13406931pdq.15.2014.11.24.15.22.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Nov 2014 15:22:26 -0800 (PST) Sender: Warner Losh Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3450DD1C-F153-4F44-8384-982126E9CCBB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b2 From: Warner Losh In-Reply-To: <86wq6k9okk.fsf@nine.des.no> Date: Mon, 24 Nov 2014 16:22:23 -0700 Message-Id: <4C2BD093-BEA2-47F9-B575-90342712E9B2@bsdimp.com> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= X-Mailer: Apple Mail (2.1993) Cc: arch@freebsd.org, Ian Lepore , Mark R V Murray X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 23:22:29 -0000 --Apple-Mail=_3450DD1C-F153-4F44-8384-982126E9CCBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 24, 2014, at 4:16 PM, Dag-Erling Sm=C3=B8rgrav = wrote: >=20 > Mark R V Murray writes: >=20 >>> On 24 Nov 2014, at 15:01, Ian Lepore wrote: >>>=20 >>>=20 >>> The logging change was pretty simple: >>>=20 >>> Index: kern/subr_bus.c >>=20 >> Thanks. >>=20 >>> The low number of devices is pretty typical. Sometimes there'll be >>> another uart. Sometimes an i2c eeprom. >>=20 >> OK - a good example of a low-entropy system then. >>=20 >>> I have no idea what's up with the first 3 unchanging numbers, but I >>> suspect a big part of the explanation for the other numbers is the = 32KHz >>> clock it's getting the numbers from. There used to be a clock = running >>> at about 2.8MHz, but the source code for that driver seems to have >>> disappeared from FreeBSD at some point between 8.x and -current. >>=20 >> What really bothers me is that these should be the difference between >> 2 essentially similar numbers; times not all that far apart, yet some >> of the numbers are truly massive. >=20 > They're not just massive, they're preposterous, as is the fact that = most > of them are absolutely identical, or just one bit off, from one run to > the next. My best guess is that get_cyclecount() is broken. What=E2=80=99s the minimum specs required for get_cyclecount()? Not all = of the boxes that Ian was posting about have high-resolution time-keeping = counters in hardware=E2=80=A6 Maybe there=E2=80=99s some underlying expectation = for this function that these systems either aren=E2=80=99t providing or can=E2=80=99t = provide. Warner --Apple-Mail=_3450DD1C-F153-4F44-8384-982126E9CCBB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUc72wAAoJEGwc0Sh9sBEAeE8P/ibUhZZbEF1MhrNTZ0YbuDvf kLlRnnjz+UKUMSN9cQZQD2m+L1Y+rmHV7BLdcAFH2CiRF2pBXvkM/gnR8CWLSulC mFSyLWE77k56ko2cEOX/xTyyKV9laZGABtwts78GxXFAIhbvW1pqvqMGWMGJwZ4W Q6F6dr8PRCBCIKclK1jz1uV/3wRVPSxORRvmeL6N8deyeWtTE6G1qpAOlrk6A/DU aneDmOxZ48WVUie2u8NVPoGxLirTNK9kV/QojmYU93nWY2Jh+kLWy+2w6xd1wP/N G2kuCD8hxoQA6yRdov2KlvamSzeIgvmkPQCzN+WMWm5/bk0LbA5bEsjGAWtNm9BN cdEP3RjOBFmnSX5Sqq9Yrys0gaIVFvGzrG2v4IoZYvpgdB/Bg+y7IZ71hYPqfLWq Ck0ZbFY8rQavds7ZyxShbVrWGYnBWsmUAtmoWCMQCxgvWIl+ebSx5O5qg7b8h1fg Uqc2rPx7oEV1At2NyPut5a691tNMdlOQG9TUo0tAq4ptBKJMhXeH84JR8E3621IM /6qz9GqfNPmdg8v4IV7GtfPY+tQaaRIGsknsZWeyI0zvLBlR6B5JBOAYz7Nr+hYs ukAQvYl8G2IdQsZQqo6ZYfo78dSMTWf25Y+YEzabEnpNtz1BQ7YABTDERBxV10tm no5xGOcsGB1lq2stdg+A =9can -----END PGP SIGNATURE----- --Apple-Mail=_3450DD1C-F153-4F44-8384-982126E9CCBB-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 02:01:37 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF1A05BC; Tue, 25 Nov 2014 02:01:37 +0000 (UTC) Received: from kawasaki3.org (blackpearl.kawasaki3.org [173.230.157.78]) by mx1.freebsd.org (Postfix) with ESMTP id DCC41628; Tue, 25 Nov 2014 02:01:37 +0000 (UTC) Received: from localhost (p7195-ipbffx02marunouchi.tokyo.ocn.ne.jp [61.126.191.195]) (Authenticated sender: moto) by kawasaki3.org (Postfix) with ESMTPSA id 7F73D1CFFC; Mon, 24 Nov 2014 20:52:01 -0500 (EST) Date: Tue, 25 Nov 2014 10:51:57 +0900 (JST) Message-Id: <20141125.105157.1187546753207512759.moto@kawasaki3.org> To: jhb@freebsd.org Subject: Re: I'd like to axe some drivers From: moto kawasaki In-Reply-To: <201411201631.27556.jhb@freebsd.org> References: <201411201631.27556.jhb@freebsd.org> X-Mailer: Mew version 6.5 on Emacs 24.3.50 / Mule 6.0 (HANACHIRUSATO) X-Face: )._4~w!_D$r6qNS0+; nS|]WNeI4f3o)QnH[ItB[esXuc$~hQ$.,?}$SnLe/[24Hao%^q/Is 'SJtZe#21h;7z;q+iyj[^%7\46.Gg-t7.px<}L-f_:P+6i4-a{DIL[ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 02:01:38 -0000 Hello, Thank you very much developers for giving me such a nice OS up-to-date. It sounds reasonable for me to remove old devices from GENERIC. But may I ask a question? If removed, how can I use those device drivers ? Do I need to re-compile kernel ? Or, can I use one of them with kldload ? Is it automatically loaded during the boot process, with charm in /boot/loader.conf ? I personally runs fxp and dc on my home pc, so I am very curious. Thank you very much. Best Regards, -- moto kawasaki From: John Baldwin To: arch@freebsd.org Subject: I'd like to axe some drivers Date:Thu, 20 Nov 2014 16:31:27 -0500 Message-ID: <201411201631.27556.jhb@freebsd.org> jhb> I'm >< close to removing timeout/untimeout from the tree. As part of this I jhb> have updated several older drivers to use callout(9), but most of those jhb> patches were untested. Keeping old code around that no one uses does add jhb> future work as tree-wide API changes are made as well as things like locking jhb> (note that several of these drivers weren't locked until I recently changed jhb> them). To that end, here is my short list of things that I think we can bid jhb> farewell to in 11. Note that many of these are for ISA devices. jhb> jhb> asr(4): This is a driver for a set of older Adaptec PCI RAID adapters. This jhb> driver is _really_ crufty and is the only thing I didn't convert to jhb> callout(9) because it has no notion of software state for a given jhb> request. It is also 32-bit only since it stuff kernel pointers into jhb> 32 bit fields in hardware-defined structures. jhb> From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 06:40:52 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08F8AC5A; Tue, 25 Nov 2014 06:40:52 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B98A06A2; Tue, 25 Nov 2014 06:40:51 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id D67243BD1A; Tue, 25 Nov 2014 06:40:49 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id sAP6elHj090679; Tue, 25 Nov 2014 06:40:48 GMT (envelope-from phk@phk.freebsd.dk) To: Warner Losh Subject: Re: svn commit: r274739 - head/sys/mips/conf In-reply-to: <4C2BD093-BEA2-47F9-B575-90342712E9B2@bsdimp.com> From: "Poul-Henning Kamp" References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <4C2BD093-BEA2-47F9-B575-90342712E9B2@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <90677.1416897647.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Nov 2014 06:40:47 +0000 Message-ID: <90678.1416897647@critter.freebsd.dk> Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , Mark R V Murray , Ian Lepore , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 06:40:52 -0000 -------- In message <4C2BD093-BEA2-47F9-B575-90342712E9B2@bsdimp.com>, Warner Losh = writes: >What's the minimum specs required for get_cyclecount()? In randomness context: That there exists a complex and unpredictable cache-hierarchy which makes the exact number of cycles for any one instruction pseudo-random. Apart from x86 and zSeries no currently relevant architecture has that. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 07:57:32 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCE04FC7; Tue, 25 Nov 2014 07:57:32 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [93.89.92.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9BEB5E22; Tue, 25 Nov 2014 07:57:32 +0000 (UTC) Received: from [2001:470:9174:1:a022:fe58:8d38:bb1f] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XtB05-0003GM-91; Tue, 25 Nov 2014 07:57:29 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <4C2BD093-BEA2-47F9-B575-90342712E9B2@bsdimp.com> Date: Tue, 25 Nov 2014 07:57:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <4C2BD093-BEA2-47F9-B575-90342712E9B2@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , Ian Lepore , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 07:57:33 -0000 > On 24 Nov 2014, at 23:22, Warner Losh wrote: >=20 > What=E2=80=99s the minimum specs required for get_cyclecount()? Not = all of the > boxes that Ian was posting about have high-resolution time-keeping = counters > in hardware=E2=80=A6 Maybe there=E2=80=99s some underlying expectation = for this function > that these systems either aren=E2=80=99t providing or can=E2=80=99t = provide. get_cyclecount should be a high-resolution timing counter linear in = time, with a minimum tick no more accurate than a single instruction = execution. In practice we take what we can get. It is used to measure = hopefully chaotic events in order to obtain environmental entropy. M --=20 Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 07:59:50 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4126127 for ; Tue, 25 Nov 2014 07:59:50 +0000 (UTC) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78326E43 for ; Tue, 25 Nov 2014 07:59:50 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id p10so58969pdj.39 for ; Mon, 24 Nov 2014 23:59:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=wMYIC6NtnTXuINCbwMBDH3Y51ThH1vNs7znWpyHJ4xQ=; b=kXc/3h+R1ckAdDP8MD2fytqSAhpRFbMmyrpEMnBY6Yw6cm3ASBKYQUR9o5exYZ39qE X/9v4YsSkRNhFJ2cx8t9rqB7ojJE9NaqrrX3+J+vnbzFruqX3K9ek59V++vouVYo5dM8 vD+GbQ4eHsTqLCsHhE7wSaAlC4xQTlU5behM+nofxapK+2D5bEFeEp0JYdqqSwSqvvBy 4M49dVZM/Wu4GMrOCbSkhGkXQ39t7EsvK2AQt2quLMyUDxLkmpfWDzPS/MnLCJppU5sv 2GButlijgpsDxFXk77s269HLwvz9RwLEzCStCi101jpmaL+FXqCdVkVtj3EZ+feVVETu Kifg== X-Gm-Message-State: ALoCoQmfH/Hjgm7iBJHMV2exFxKU4iw5gnZvCN4t+HD9jIfQ3W1NchPtA/0TAa3JZTTc6ZWfajhy X-Received: by 10.70.100.170 with SMTP id ez10mr40395387pdb.73.1416902384061; Mon, 24 Nov 2014 23:59:44 -0800 (PST) Received: from [10.64.26.139] ([69.53.236.236]) by mx.google.com with ESMTPSA id pj5sm652715pdb.65.2014.11.24.23.59.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Nov 2014 23:59:43 -0800 (PST) Sender: Warner Losh Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_194AE083-21C7-43E7-BD0E-386E833EAC1E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b2 From: Warner Losh In-Reply-To: Date: Tue, 25 Nov 2014 00:59:40 -0700 Message-Id: <4DC9E093-C877-40D4-A998-2C94318FECA6@bsdimp.com> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <4C2BD093-BEA2-47F9-B575-90342712E9B2@bsdimp.com> To: Mark R V Murray X-Mailer: Apple Mail (2.1993) Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , Ian Lepore , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 07:59:50 -0000 --Apple-Mail=_194AE083-21C7-43E7-BD0E-386E833EAC1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 25, 2014, at 12:57 AM, Mark R V Murray = wrote: >=20 >=20 >> On 24 Nov 2014, at 23:22, Warner Losh wrote: >>=20 >> What=E2=80=99s the minimum specs required for get_cyclecount()? Not = all of the >> boxes that Ian was posting about have high-resolution time-keeping = counters >> in hardware=E2=80=A6 Maybe there=E2=80=99s some underlying = expectation for this function >> that these systems either aren=E2=80=99t providing or can=E2=80=99t = provide. >=20 > get_cyclecount should be a high-resolution timing counter linear in = time, with a minimum tick no more accurate than a single instruction = execution. In practice we take what we can get. It is used to measure = hopefully chaotic events in order to obtain environmental entropy. So right. armv6 and mips have something akin to that, but IIRC, not all = arm v4/5 boxes can do much better than microseconds=E2=80=A6 Warner --Apple-Mail=_194AE083-21C7-43E7-BD0E-386E833EAC1E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUdDbtAAoJEGwc0Sh9sBEArCkP+wf+vA3VfAeJdNzdxB36gH8V XTfdstgV6flM723BaurBHy187uqHhZP4GMVhvdIRvIKO7xYYOPm6Vk2bxZZ5Nexv 5mDN2bgOWiPMB0h68sm8nmsno2U/0tcbK+DWEVBwDIsMB/IYYTByl98nH90oyVDk lgVUeM5SQ0FRTyH1VRL5txRTHE1WrvC7jtCyLTjIHCnHMYSAUbd0R++EYVmSvWHV 1aANPADhrDX9DWnhytw/Dxj4C/6FA6dWNRcCc/BW9eZUrUOneo/LUX0EXNE5xnTu SaUrZQxXThDVgCbExtB7OPKJ9/liigtcQMxR0MNoJaNlqmNwZW6xiVKSEXAVCKNR 7gUQFG29k2eQrB/XYbAF8xkSWbZXyHYzXpUHpTQd6CdHgRHfw4AtppZF+w0YvSLn zINTGEBH8EQEf90Y+e7wZnhC01OCPYFk5LH/4p32IbCYXkkMKB/iMbbdMXZQ0Hnu E59rl0M0UWRWQksdD4YwiZegynk1fyjJR2IcP8Aa8CIe3xwlniuMF59RLrqFy21S Qj6j9ysH9QGwvAt1qXRj3lzznly4nLLfvU9RkhAydWOX9DH8NdViL/uy65l/u12T Xe0yBWp9fsE+NC9fPvA9haxsYTMpyvBF1gIxk0GDBfrX9m7hKEODnN1Tkk9UZY/r 6KA8jzwxFNiP9CFrZf45 =ffoI -----END PGP SIGNATURE----- --Apple-Mail=_194AE083-21C7-43E7-BD0E-386E833EAC1E-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 08:00:02 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D14A51DE; Tue, 25 Nov 2014 08:00:02 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [93.89.92.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92118E4B; Tue, 25 Nov 2014 08:00:02 +0000 (UTC) Received: from [2001:470:9174:1:a022:fe58:8d38:bb1f] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XtAwa-0003Fz-Tg; Tue, 25 Nov 2014 07:53:54 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <86wq6k9okk.fsf@nine.des.no> Date: Tue, 25 Nov 2014 07:53:51 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: arch@freebsd.org, Ian Lepore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 08:00:02 -0000 > On 24 Nov 2014, at 23:16, Dag-Erling Sm=C3=B8rgrav wrote: >=20 > They're not just massive, they're preposterous, as is the fact that = most > of them are absolutely identical, or just one bit off, from one run to > the next. My best guess is that get_cyclecount() is broken. How two consecutive calls to get_cyclecount() can repeatedly return such = massive numbers is an indication that something has gone badly wrong. On this platform, this is just a wrapper round the internal timekeeping = routines; could it be that these are being messed with during startup? = Whatever is happening is pretty deterministic. M --=20 Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 08:32:50 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5253F9AD; Tue, 25 Nov 2014 08:32:50 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [93.89.92.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0FA74278; Tue, 25 Nov 2014 08:32:48 +0000 (UTC) Received: from [2001:470:9174:1:a022:fe58:8d38:bb1f] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XtBX0-0003KU-Ik; Tue, 25 Nov 2014 08:31:32 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <4DC9E093-C877-40D4-A998-2C94318FECA6@bsdimp.com> Date: Tue, 25 Nov 2014 08:31:29 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <4C2BD093-BEA2-47F9-B575-90342712E9B2@bsdimp.com> <4DC9E093-C877-40D4-A998-2C94318FECA6@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , Ian Lepore , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 08:32:50 -0000 > On 25 Nov 2014, at 07:59, Warner Losh wrote: >=20 >=20 >> On Nov 25, 2014, at 12:57 AM, Mark R V Murray = wrote: >>=20 >>=20 >>> On 24 Nov 2014, at 23:22, Warner Losh wrote: >>>=20 >>> What=E2=80=99s the minimum specs required for get_cyclecount()? Not = all of the >>> boxes that Ian was posting about have high-resolution time-keeping = counters >>> in hardware=E2=80=A6 Maybe there=E2=80=99s some underlying = expectation for this function >>> that these systems either aren=E2=80=99t providing or can=E2=80=99t = provide. >>=20 >> get_cyclecount should be a high-resolution timing counter linear in = time, with a minimum tick no more accurate than a single instruction = execution. In practice we take what we can get. It is used to measure = hopefully chaotic events in order to obtain environmental entropy. >=20 > So right. armv6 and mips have something akin to that, but IIRC, not = all arm v4/5 boxes can do much better than microseconds=E2=80=A6 That=E2=80=99s my understanding. I still don=E2=80=99t get the massive = differences; they should be tiny. M --=20 Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 08:46:43 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 304DCDC5; Tue, 25 Nov 2014 08:46:43 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id DA9CC3F5; Tue, 25 Nov 2014 08:46:42 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 5A168ABB8; Tue, 25 Nov 2014 08:46:41 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 0C8871274; Tue, 25 Nov 2014 09:46:32 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Poul-Henning Kamp" Subject: Re: svn commit: r274739 - head/sys/mips/conf References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <4C2BD093-BEA2-47F9-B575-90342712E9B2@bsdimp.com> <90678.1416897647@critter.freebsd.dk> Date: Tue, 25 Nov 2014 09:46:31 +0100 In-Reply-To: <90678.1416897647@critter.freebsd.dk> (Poul-Henning Kamp's message of "Tue, 25 Nov 2014 06:40:47 +0000") Message-ID: <86a93fwtug.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, Mark R V Murray , Ian Lepore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 08:46:43 -0000 "Poul-Henning Kamp" writes: > Warner Losh writes: > > What's the minimum specs required for get_cyclecount()? > In randomness context: That there exists a complex and unpredictable > cache-hierarchy which makes the exact number of cycles for any one > instruction pseudo-random. No. It just needs to be monotonic across cores and have reasonably high resolution. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 08:52:52 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCE00EC2; Tue, 25 Nov 2014 08:52:52 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 85E806AF; Tue, 25 Nov 2014 08:52:52 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id E07F2ABC8; Tue, 25 Nov 2014 08:52:51 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 019031276; Tue, 25 Nov 2014 09:52:41 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark R V Murray Subject: Re: svn commit: r274739 - head/sys/mips/conf References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> Date: Tue, 25 Nov 2014 09:52:41 +0100 In-Reply-To: (Mark R. V. Murray's message of "Tue, 25 Nov 2014 07:53:51 +0000") Message-ID: <8661e3wtk6.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, Ian Lepore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 08:52:52 -0000 Mark R V Murray writes: > How two consecutive calls to get_cyclecount() can repeatedly return > such massive numbers is an indication that something has gone badly > wrong. No, wait. I looked at the code. The most likely explanation is that it is falling through to this: binuptime(&bt); return ((uint64_t)bt.sec << 56 | bt.frac >> 8); so the top 8 bits are seconds (meaning that get_cyclecount wraps around every 256 seconds) and the bottom 64 are the base 2 fractional part. At first glance, Ian's number seem to be identical from one run to the next, but they're not - there seems to be a small amount of variation. But I'm still very suspicious of at91_st0, which is constant, and nexus0, at91_aic0 and at91_pmc0, which are constant *and* identical. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 08:58:51 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3E321CE; Tue, 25 Nov 2014 08:58:51 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73736783; Tue, 25 Nov 2014 08:58:51 +0000 (UTC) Received: from [2001:470:9174:1:a022:fe58:8d38:bb1f] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XtBxP-0003Mi-2n; Tue, 25 Nov 2014 08:58:48 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <8661e3wtk6.fsf@nine.des.no> Date: Tue, 25 Nov 2014 08:58:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <8661e3wtk6.fsf@nine.des.no> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: arch@freebsd.org, Ian Lepore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 08:58:51 -0000 > On 25 Nov 2014, at 08:52, Dag-Erling Sm=C3=B8rgrav wrote: >=20 > Mark R V Murray writes: >> How two consecutive calls to get_cyclecount() can repeatedly return >> such massive numbers is an indication that something has gone badly >> wrong. >=20 > No, wait. I looked at the code. The most likely explanation is that = it > is falling through to this: >=20 > binuptime(&bt); > return ((uint64_t)bt.sec << 56 | bt.frac >> 8); >=20 > so the top 8 bits are seconds (meaning that get_cyclecount wraps = around > every 256 seconds) and the bottom 64 are the base 2 fractional part. = At > first glance, Ian's number seem to be identical from one run to the > next, but they're not - there seems to be a small amount of variation. > But I'm still very suspicious of at91_st0, which is constant, and > nexus0, at91_aic0 and at91_pmc0, which are constant *and* identical. Ian - could you please print the 2 get_cyclecount() return values as = well as the difference on that same hardware and at the same place as = you did you previous change? Thanks. M --=20 Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 09:09:45 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11A9E4CF; Tue, 25 Nov 2014 09:09:45 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C0EFF8CB; Tue, 25 Nov 2014 09:09:44 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 5C4856A6008; Tue, 25 Nov 2014 10:09:41 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id sAP99fMs015417; Tue, 25 Nov 2014 10:09:41 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id sAP99cZS014180; Tue, 25 Nov 2014 10:09:38 +0100 (CET) (envelope-from lars) Date: Tue, 25 Nov 2014 10:09:38 +0100 From: Lars Engels To: moto kawasaki Subject: Re: I'd like to axe some drivers Message-ID: <20141125090938.GH15721@e-new.0x20.net> References: <201411201631.27556.jhb@freebsd.org> <20141125.105157.1187546753207512759.moto@kawasaki3.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9sSKoi6Rw660DLir" Content-Disposition: inline In-Reply-To: <20141125.105157.1187546753207512759.moto@kawasaki3.org> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p16 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 09:09:45 -0000 --9sSKoi6Rw660DLir Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 25, 2014 at 10:51:57AM +0900, moto kawasaki wrote: >=20 > Hello, >=20 > Thank you very much developers for giving me such a nice OS > up-to-date. >=20 > It sounds reasonable for me to remove old devices from GENERIC. > But may I ask a question? >=20 > If removed, how can I use those device drivers ? > Do I need to re-compile kernel ? > Or, can I use one of them with kldload ? > Is it automatically loaded during the boot process, with charm in > /boot/loader.conf ? >=20 > I personally runs fxp and dc on my home pc, so I am very curious. >=20 > Thank you very much. >=20 >=20 > Best Regards, >=20 You can usually just load the kernel module with kldload(8). --9sSKoi6Rw660DLir Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUdEdSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1t9dcH/RG5+UKvvbLwdcusLZFccWbP 7YISRm5eIdNxc99UGYx44k9Q6ADbQMAvud+bDLxvpUolm3HNuTiv15K2NpB9ZULH VUP/wR8VCdtEwqkpio3t9vjCRZngtPn0CehmpWRIqAfDnVV02l9a5q/Hpaf4WK4D 2aL9b3vkB5dMbXYwsOI1PswHTyBHuoH036KY8YnP2zKvZ2sKbvNyUYJvTQvraDRA iNMNTbnAJR/fc+6mEmc2r68wtI0Gh4bNtfEDn0f+o/sVb31GS55m9WJS0lKzgCL+ ywVfKdQz/C+gVOizINipKPCZSsAQEuReQy0/pg0rMOtDYZsdPZ8GPei+3EwW0tU= =7Scn -----END PGP SIGNATURE----- --9sSKoi6Rw660DLir-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 10:31:50 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57229805; Tue, 25 Nov 2014 10:31:50 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id B79EC1AC; Tue, 25 Nov 2014 10:31:49 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 2E9C9AC9A; Tue, 25 Nov 2014 10:31:48 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 746131294; Tue, 25 Nov 2014 11:31:38 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark R V Murray Subject: Re: svn commit: r274739 - head/sys/mips/conf References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <8661e3wtk6.fsf@nine.des.no> Date: Tue, 25 Nov 2014 11:31:38 +0100 In-Reply-To: (Mark R. V. Murray's message of "Tue, 25 Nov 2014 08:58:45 +0000") Message-ID: <86oarvvaet.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, Ian Lepore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 10:31:50 -0000 Mark R V Murray writes: > Ian - could you please print the 2 get_cyclecount() return values as > well as the difference on that same hardware and at the same place as > you did you previous change? Better yet, use my old attachtimes patch which includes code to collect statistics in a buffer which can be retrieved and analyzed later. I'll prepare an updated version later today. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 10:32:20 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 000A78AF; Tue, 25 Nov 2014 10:32:19 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 65ECB240; Tue, 25 Nov 2014 10:32:19 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id DBF34ACA0; Tue, 25 Nov 2014 10:32:17 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 1C7701296; Tue, 25 Nov 2014 11:32:08 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark R V Murray Subject: Re: svn commit: r274739 - head/sys/mips/conf In-Reply-To: (Mark R. V. Murray's message of "Tue, 25 Nov 2014 08:58:45 +0000") References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <8661e3wtk6.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) Date: Tue, 25 Nov 2014 11:32:08 +0100 Message-ID: <86fvd7vadz.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, Ian Lepore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 10:32:20 -0000 Mark R V Murray writes: > Ian - could you please print the 2 get_cyclecount() return values as > well as the difference on that same hardware and at the same place as > you did you previous change? Better yet, use my old attachtimes patch which includes code to collect statistics in a buffer which can be retrieved and analyzed later. I'll prepare an updated version later today. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 12:16:02 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBDC081C; Tue, 25 Nov 2014 12:16:02 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4EEFFFAE; Tue, 25 Nov 2014 12:16:01 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 3099AAD8F; Tue, 25 Nov 2014 12:16:01 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id A6EC712B1; Tue, 25 Nov 2014 13:15:54 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ian Lepore Subject: Re: svn commit: r274739 - head/sys/mips/conf References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <8661e3wtk6.fsf@nine.des.no> <86oarvvaet.fsf@nine.des.no> Date: Tue, 25 Nov 2014 13:15:54 +0100 In-Reply-To: <86oarvvaet.fsf@nine.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8r?= =?utf-8?Q?grav=22's?= message of "Tue, 25 Nov 2014 11:31:38 +0100") Message-ID: <86egsrxypx.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: arch@freebsd.org, Mark R V Murray X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 12:16:03 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ian, please try the attached patch. The way this is intended to be used is that you set up a system with an /etc/rc that does nothing else than mount the root file system and append the output from "sysctl -b hw.attachtimes" to a log file, then reboot. You let it run for as long as you wish, then copy the log file to another machine and run the attachtimes utility (source code below) on the log file to extract the data and display either the raw numbers or a histogram showing the distribution. See freefall:~des/software/attachtimes.tgz for an example of how to set this up. All you need is the loader and kernel, a minimal /etc, and the tools required by /etc/rc (sh, fsck, mount, df, sysctl, halt, reboot). The example contains quite a bit more than that because I wanted to be able to boot it in single-user mode for debugging. The patch can easily be modified to record the actual timestamps instead of just the delta, but remember to modify the utility as well, or the output will be complete nonsense. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=attachtimes-20141125.diff Index: sys/kern/subr_bus.c =================================================================== --- sys/kern/subr_bus.c (revision 275022) +++ sys/kern/subr_bus.c (working copy) @@ -32,6 +32,7 @@ #include #include +#include #include #include #include @@ -66,6 +67,16 @@ SYSCTL_NODE(_hw, OID_AUTO, bus, CTLFLAG_RW, NULL, NULL); SYSCTL_ROOT_NODE(OID_AUTO, dev, CTLFLAG_RW, NULL, NULL); +#define MAXNATTACHTIMES 128 +static struct attachtime { + char name[24]; + uint64_t delta; +} attachtimes[MAXNATTACHTIMES]; +static int nattachtimes; +SYSCTL_OPAQUE(_hw, OID_AUTO, attachtimes, CTLFLAG_RD, + &attachtimes, sizeof(attachtimes), "S,attachtimes", + "time spent in device_attach()"); + /* * Used to attach drivers to devclasses. */ @@ -2801,6 +2812,19 @@ return error; } +static void +device_harvest_random(device_t dev, uint64_t attachtime) +{ + + if (nattachtimes < MAXNATTACHTIMES) { + strlcpy(attachtimes[nattachtimes].name, dev->nameunit, + sizeof(attachtimes[nattachtimes])); + attachtimes[nattachtimes].delta = htobe64(attachtime); + ++nattachtimes; + } + random_harvest(&attachtime, sizeof(attachtime), 4, RANDOM_ATTACH); +} + /** * @brief Attach a device driver to a device * @@ -2849,17 +2873,7 @@ dev->state = DS_NOTPRESENT; return (error); } - attachtime = get_cyclecount() - attachtime; - /* - * 4 bits per device is a reasonable value for desktop and server - * hardware with good get_cyclecount() implementations, but may - * need to be adjusted on other platforms. - */ -#ifdef RANDOM_DEBUG - printf("random: %s(): feeding %d bit(s) of entropy from %s%d\n", - __func__, 4, dev->driver->name, dev->unit); -#endif - random_harvest(&attachtime, sizeof(attachtime), 4, RANDOM_ATTACH); + device_harvest_random(dev, get_cyclecount() - attachtime); device_sysctl_update(dev); if (dev->busy) dev->state = DS_BUSY; --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename=attachtimes.c Content-Transfer-Encoding: quoted-printable /*- * Copyright (c) 2012 Dag-Erling Sm=C3=B8rgrav * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer * in this position and unchanged. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPO= SE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTI= AL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRI= CT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $Id$ */ #include #include #include #include #include #include #include #include #include static int opt_c; /* clobber */ static int opt_h; /* create histogram */ static int opt_v; /* verbose mode */ struct attachtime { char name[24]; uint64_t delta; }; // typedef struct at_entry at_entry; struct at_entry { RB_ENTRY(at_entry) at_rb; char name[24]; FILE *f; unsigned long count; }; RB_HEAD(at_entry_tree, at_entry) at_entry_head; static inline int at_entry_cmp(const struct at_entry *a, const struct at_entry *b) { return (strcmp(a->name, b->name)); } RB_PROTOTYPE_STATIC(at_entry_tree, at_entry, at_rb, at_entry_cmp); RB_GENERATE_STATIC(at_entry_tree, at_entry, at_rb, at_entry_cmp); static void init_at_entry(void) { RB_INIT(&at_entry_head); } static struct at_entry * get_at_entry(const char *name) { =09 struct at_entry key, *e; strcpy(key.name, name); if ((e =3D RB_FIND(at_entry_tree, &at_entry_head, &key)) !=3D NULL) return (e); if (opt_v > 1) warnx("adding device %s", name); if ((e =3D calloc(1, sizeof *e)) =3D=3D NULL) err(1, "calloc()"); strcpy(e->name, name); if ((e->f =3D fopen(name, "a")) =3D=3D NULL) err(1, "open(\"%s\")", name); if (opt_c && ftruncate(fileno(e->f), 0) < 0) err(1, "truncate(\"%s\")", name); RB_INSERT(at_entry_tree, &at_entry_head, e); return (e); } static void exit_at_entry(void) { struct at_entry *e; while ((e =3D RB_ROOT(&at_entry_head)) !=3D NULL) { RB_REMOVE(at_entry_tree, &at_entry_head, e); fclose(e->f); free(e); } } #define MAX_HIST_BITS 16 static unsigned long *hist; static int hist_size =3D 8192; static int hist_max; static int hist_count; static int hist_ignored; static void add_histogram(unsigned long long delta) { int bits, bucket; bits =3D flsll((unsigned long long)delta) - 10; if (bits < 0) return; if (bits > MAX_HIST_BITS) { ++hist_ignored; return; } bucket =3D (int)(delta & ~((uint64_t)1 << bits)); if (hist =3D=3D NULL || hist_size <=3D bucket) { while (hist_size <=3D bucket) hist_size *=3D 2; if ((hist =3D realloc(hist, hist_size * sizeof *hist)) =3D=3D NULL) err(1, "realloc()"); } if (bucket > hist_max) hist_max =3D bucket; ++hist[bucket]; ++hist_count; } static void write_histogram(const char *fn) { FILE *f; int i; if (opt_v) warnx("%d samples collected", hist_count); if (hist_ignored > 0) warnx("%d samples greater than %lu were ignored", hist_ignored, (unsigned long)1 << MAX_HIST_BITS); if (opt_v) warnx("saving histogram"); if ((f =3D fopen(fn, "w")) =3D=3D NULL) err(1, "open(\"%s\")", fn); if (opt_c && ftruncate(fileno(f), 0) < 0) err(1, "truncate(\"%s\")", fn); for (i =3D 0; i < hist_max; ++i) if (hist[i] > 0) fprintf(f, "%d %lu\n", i, hist[i]); fclose(f); } static void read_attachtimes(const char *fn) { struct attachtime at; struct at_entry *e; uint64_t delta; ssize_t rlen; int fd; if (opt_v) warnx("reading %s", fn); if ((fd =3D open(fn, O_RDONLY)) < 0) err(1, "%s", fn); for (;;) { if ((rlen =3D read(fd, &at, sizeof at)) < 0) err(1, "%s", fn); if (rlen =3D=3D 0) break; if (rlen !=3D sizeof at) { warnx("%s: short read", fn); break; } if (*at.name =3D=3D '\0') continue; e =3D get_at_entry(at.name); delta =3D be64toh(at.delta); fprintf(e->f, "%llu\n", (unsigned long long)delta); ++e->count; if (opt_h) add_histogram(delta); } close(fd); } static void usage(void) { fprintf(stderr, "attachtimes [-chv] [file ...]\n" "\n" "\t-c\tclobber existing files\n" "\t-h\tcreate histogram\n" "\t-v\tverbose\n"); exit(1); } int main(int argc, char *argv[]) { int opt; while ((opt =3D getopt(argc, argv, "chv")) !=3D -1) switch (opt) { case 'c': ++opt_c; break; case 'h': ++opt_h; break; case 'v': ++opt_v; break; default: usage(); } argc -=3D optind; argv +=3D optind; init_at_entry(); if (argc =3D=3D 0) read_attachtimes("/dev/stdout"); else while (argc--) read_attachtimes(*argv++); exit_at_entry(); if (opt_h) write_histogram("histogram"); exit(0); } --=-=-=-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 12:18:24 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 207DC8F7 for ; Tue, 25 Nov 2014 12:18:24 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D77DCFD2 for ; Tue, 25 Nov 2014 12:18:23 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id ED62CAD95; Tue, 25 Nov 2014 12:18:22 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id A154D12B3; Tue, 25 Nov 2014 13:18:15 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Lars Engels Subject: Re: I'd like to axe some drivers References: <201411201631.27556.jhb@freebsd.org> <20141125.105157.1187546753207512759.moto@kawasaki3.org> <20141125090938.GH15721@e-new.0x20.net> Date: Tue, 25 Nov 2014 13:18:15 +0100 In-Reply-To: <20141125090938.GH15721@e-new.0x20.net> (Lars Engels's message of "Tue, 25 Nov 2014 10:09:38 +0100") Message-ID: <86a93fxym0.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, moto kawasaki X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 12:18:24 -0000 Lars Engels writes: > moto kawasaki writes: > > If removed, how can I use those device drivers ? [...] I > > personally runs fxp and dc on my home pc, so I am very curious. > You can usually just load the kernel module with kldload(8). or add if_dc_load=3Dyes if_fxp_load=3Dyes to /boot/loader.conf. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 15:10:33 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DE70F0F for ; Tue, 25 Nov 2014 15:10:33 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02C0A8A3 for ; Tue, 25 Nov 2014 15:10:32 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XtH1K-000BPV-I5; Tue, 25 Nov 2014 14:23:10 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAPEN8eW013437; Tue, 25 Nov 2014 07:23:08 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19z5vrPXja+TeWMWA0N27fO X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Ian Lepore To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86egsrxypx.fsf@nine.des.no> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <8661e3wtk6.fsf@nine.des.no> <86oarvvaet.fsf@nine.des.no> <86egsrxypx.fsf@nine.des.no> Content-Type: text/plain; charset="ISO-8859-1" Date: Tue, 25 Nov 2014 07:23:07 -0700 Message-ID: <1416925387.1147.437.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sAPEN8eW013437 Cc: arch@freebsd.org, Mark R V Murray X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 15:10:33 -0000 On Tue, 2014-11-25 at 13:15 +0100, Dag-Erling Sm=F8rgrav wrote: > Ian, please try the attached patch. >=20 > The way this is intended to be used is that you set up a system with an > /etc/rc that does nothing else than mount the root file system and > append the output from "sysctl -b hw.attachtimes" to a log file, then > reboot. You let it run for as long as you wish, then copy the log file > to another machine and run the attachtimes utility (source code below) > on the log file to extract the data and display either the raw numbers > or a histogram showing the distribution. >=20 > See freefall:~des/software/attachtimes.tgz for an example of how to set > this up. All you need is the loader and kernel, a minimal /etc, and th= e > tools required by /etc/rc (sh, fsck, mount, df, sysctl, halt, reboot). > The example contains quite a bit more than that because I wanted to be > able to boot it in single-user mode for debugging. >=20 > The patch can easily be modified to record the actual timestamps instea= d > of just the delta, but remember to modify the utility as well, or the > output will be complete nonsense. >=20 > DES Getting the results for this is going to take a while... I can't get the system past mountroot right now. I have no idea why. It's been months since I last successfully booted -current on this old hardware. I'm also very busy with $work. For the 3 numbers that are identical at the start, I think we're reading garbage in binuptime() because the clock driver isn't working yet. The numbers first change with at91_st0, that's the clock driver. atmelarm0 is the parent of everything listed between nexus and it, so the large number there is probably the subtraction of the post-init clock value from the pre-init clock garbage. In a more general sense, I'm going to repeat a couple things... The clock all this is being measured with runs at 32 KHz. That's 'K'. =20 This output is evidence that the system behaves exactly as I've been saying it behaves for a long long while. You seem convinced, I don't understand why, that there must be some error here. I don't understand why you think a system like this would behave any differently each time it is powered on. The only actual entropy involved is whatever minor thermal transients may exist in the crystal oscillator. With 32KHz resolution (or even a few MHz) that amounts to not a lot of measurable variation at all. The repeatability of the boot sequence of hardware like this is nearly perfect at the resolution we're measuring. While that may be bad for gathering entropy, it's a wonderful thing when you're debugging, because problems that would be almost impossible to nail down on modern complex hardware are 100% reproducible by just hitting the reset button. That reproducibility extends all the way into multiuser mode unless there is a network connection where packet arrival times start adding interrupt-based entropy. -- Ian From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 16:59:47 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 177DA7D6; Tue, 25 Nov 2014 16:59:47 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E8467A4; Tue, 25 Nov 2014 16:59:46 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id h11so9834135wiw.1 for ; Tue, 25 Nov 2014 08:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+lUjGBvddbpc0VsbOstHFvdNlPJenTvdIzmG1cb43SI=; b=cGGOXGic5TTlvMzI6R4dsUdOgQ1P4WLw83+T2iooOOdJKBR4Pn9lMORWC4O92dTMHN LijC2qXWKWGUrBOqasDQVZysF2ZcolzFQCzXCvo7m1Am4L9uUHtpP2A0+636/2KJSfVn 8eW9YexT+4JlaFp+ktSLTs7gFLIE3hY2RoxwOV00UECMeOw3dpOekr2xTi8uDDXcRhUa 069siI0/tIlHcddMkDhhn3lTCuNzYJRBU9ejrUWRHo3auSqRmElTTFznA2+HLks3m5IY Q1ofdw3Hb3GwgyYsPEjWuUHyf58AeHFtT7Px9yUnXHEgvWWZ0HXvnu6wo5RrrHX9z4/s dezA== MIME-Version: 1.0 X-Received: by 10.180.92.169 with SMTP id cn9mr33450214wib.26.1416934784954; Tue, 25 Nov 2014 08:59:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Tue, 25 Nov 2014 08:59:44 -0800 (PST) In-Reply-To: <1416925387.1147.437.camel@revolution.hippie.lan> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <8661e3wtk6.fsf@nine.des.no> <86oarvvaet.fsf@nine.des.no> <86egsrxypx.fsf@nine.des.no> <1416925387.1147.437.camel@revolution.hippie.lan> Date: Tue, 25 Nov 2014 08:59:44 -0800 X-Google-Sender-Auth: OWK5AcbPcj8pL16ZsvYOhc98vnY Message-ID: Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , Mark R V Murray , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 16:59:47 -0000 On 25 November 2014 at 06:23, Ian Lepore wrote: > On Tue, 2014-11-25 at 13:15 +0100, Dag-Erling Sm=C3=B8rgrav wrote: >> Ian, please try the attached patch. >> >> The way this is intended to be used is that you set up a system with an >> /etc/rc that does nothing else than mount the root file system and >> append the output from "sysctl -b hw.attachtimes" to a log file, then >> reboot. You let it run for as long as you wish, then copy the log file >> to another machine and run the attachtimes utility (source code below) >> on the log file to extract the data and display either the raw numbers >> or a histogram showing the distribution. >> >> See freefall:~des/software/attachtimes.tgz for an example of how to set >> this up. All you need is the loader and kernel, a minimal /etc, and the >> tools required by /etc/rc (sh, fsck, mount, df, sysctl, halt, reboot). >> The example contains quite a bit more than that because I wanted to be >> able to boot it in single-user mode for debugging. >> >> The patch can easily be modified to record the actual timestamps instead >> of just the delta, but remember to modify the utility as well, or the >> output will be complete nonsense. >> >> DES > > Getting the results for this is going to take a while... I can't get the > system past mountroot right now. I have no idea why. It's been months > since I last successfully booted -current on this old hardware. I'm > also very busy with $work. > > For the 3 numbers that are identical at the start, I think we're reading > garbage in binuptime() because the clock driver isn't working yet. The > numbers first change with at91_st0, that's the clock driver. atmelarm0 > is the parent of everything listed between nexus and it, so the large > number there is probably the subtraction of the post-init clock value > from the pre-init clock garbage. > > In a more general sense, I'm going to repeat a couple things... > > The clock all this is being measured with runs at 32 KHz. That's 'K'. > > This output is evidence that the system behaves exactly as I've been > saying it behaves for a long long while. You seem convinced, I don't > understand why, that there must be some error here. I don't understand > why you think a system like this would behave any differently each time > it is powered on. The only actual entropy involved is whatever minor > thermal transients may exist in the crystal oscillator. With 32KHz > resolution (or even a few MHz) that amounts to not a lot of measurable > variation at all. > > The repeatability of the boot sequence of hardware like this is nearly > perfect at the resolution we're measuring. While that may be bad for > gathering entropy, it's a wonderful thing when you're debugging, because > problems that would be almost impossible to nail down on modern complex > hardware are 100% reproducible by just hitting the reset button. That > reproducibility extends all the way into multiuser mode unless there is > a network connection where packet arrival times start adding > interrupt-based entropy. > Can you bring up the clock first? Or at least earlier? Should bintime() be returning garbage so early? I wonder if that'd have an effect on any other driver startup paths that may use it. -adrian From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 17:08:19 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EBF3B51; Tue, 25 Nov 2014 17:08:19 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 314A58B6; Tue, 25 Nov 2014 17:08:18 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XtJb7-0009dW-CR; Tue, 25 Nov 2014 17:08:17 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAPH8F40013732; Tue, 25 Nov 2014 10:08:15 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+xKkRlxR4pN1Cdv5BsDYaC X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <8661e3wtk6.fsf@nine.des.no> <86oarvvaet.fsf@nine.des.no> <86egsrxypx.fsf@nine.des.no> <1416925387.1147.437.camel@revolution.hippie.lan> Content-Type: text/plain; charset="ISO-8859-1" Date: Tue, 25 Nov 2014 10:08:15 -0700 Message-ID: <1416935295.1147.457.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sAPH8F40013732 Cc: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= , Mark R V Murray , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 17:08:19 -0000 On Tue, 2014-11-25 at 08:59 -0800, Adrian Chadd wrote: > On 25 November 2014 at 06:23, Ian Lepore wrote: > > On Tue, 2014-11-25 at 13:15 +0100, Dag-Erling Sm=F8rgrav wrote: > >> Ian, please try the attached patch. > >> > >> The way this is intended to be used is that you set up a system with= an > >> /etc/rc that does nothing else than mount the root file system and > >> append the output from "sysctl -b hw.attachtimes" to a log file, the= n > >> reboot. You let it run for as long as you wish, then copy the log f= ile > >> to another machine and run the attachtimes utility (source code belo= w) > >> on the log file to extract the data and display either the raw numbe= rs > >> or a histogram showing the distribution. > >> > >> See freefall:~des/software/attachtimes.tgz for an example of how to = set > >> this up. All you need is the loader and kernel, a minimal /etc, and= the > >> tools required by /etc/rc (sh, fsck, mount, df, sysctl, halt, reboot= ). > >> The example contains quite a bit more than that because I wanted to = be > >> able to boot it in single-user mode for debugging. > >> > >> The patch can easily be modified to record the actual timestamps ins= tead > >> of just the delta, but remember to modify the utility as well, or th= e > >> output will be complete nonsense. > >> > >> DES > > > > Getting the results for this is going to take a while... I can't get = the > > system past mountroot right now. I have no idea why. It's been mont= hs > > since I last successfully booted -current on this old hardware. I'm > > also very busy with $work. > > > > For the 3 numbers that are identical at the start, I think we're read= ing > > garbage in binuptime() because the clock driver isn't working yet. T= he > > numbers first change with at91_st0, that's the clock driver. atmelar= m0 > > is the parent of everything listed between nexus and it, so the large > > number there is probably the subtraction of the post-init clock value > > from the pre-init clock garbage. > > > > In a more general sense, I'm going to repeat a couple things... > > > > The clock all this is being measured with runs at 32 KHz. That's 'K'. > > > > This output is evidence that the system behaves exactly as I've been > > saying it behaves for a long long while. You seem convinced, I don't > > understand why, that there must be some error here. I don't understa= nd > > why you think a system like this would behave any differently each ti= me > > it is powered on. The only actual entropy involved is whatever minor > > thermal transients may exist in the crystal oscillator. With 32KHz > > resolution (or even a few MHz) that amounts to not a lot of measurabl= e > > variation at all. > > > > The repeatability of the boot sequence of hardware like this is nearl= y > > perfect at the resolution we're measuring. While that may be bad for > > gathering entropy, it's a wonderful thing when you're debugging, beca= use > > problems that would be almost impossible to nail down on modern compl= ex > > hardware are 100% reproducible by just hitting the reset button. Tha= t > > reproducibility extends all the way into multiuser mode unless there = is > > a network connection where packet arrival times start adding > > interrupt-based entropy. > > >=20 > Can you bring up the clock first? Or at least earlier? >=20 First as in "before nexus"? That sounds tricky. Looking at the order of things now, it's nexus, the main SoC bus, the interrupt controller, power-management, clock driver. That seems reasonable to me, you need all that other stuff first to get the clock to the point where it can register as a timecounter and provide timestamps. > Should bintime() be returning garbage so early? I wonder if that'd > have an effect on any other driver startup paths that may use it. >=20 >=20 It seems odd that it returns garbage, but the alternative would be to return zero, and while that makes more sense to me, it isn't helpful in terms of providing useful data (other than as an indication that the clock isn't running yet). -- Ian From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 17:11:13 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2B3AE42 for ; Tue, 25 Nov 2014 17:11:13 +0000 (UTC) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B40DB971 for ; Tue, 25 Nov 2014 17:11:13 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id kq14so960485pab.6 for ; Tue, 25 Nov 2014 09:11:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=2F6+vf/f441ZCxYMKT7yD5k2JyBehNPNbJcjoh+2y0Q=; b=OBSa1mcIYLzc7s+ODKpVMcqFV/JMtSArTBUlmjzamhw2GInHLduq1yyah67ylmcHyx 26p0cRy+MaMbrHqwDtCWG1bqtG23uyrCJixy6TUP+YR+YaaaHS4PYJdqXYWERXDMdV1w 1d3F4ROPeYBPQzew1sXyL+hYpbFvlHuwhwW9ki79Y6Hb3k9pbQOR//z09sWKQ18yL0VZ GZEYL3BeGKJq6bVyeaZmIffgo+Rzuh0UY19Q85Qp7UUGcHCny3AyDN/YtKbeaXM0XEHj BaMCMwocqFG24sdwIUYBqkEkQ6YRqWOMM/k3xELLexzh5dWHQ6lTJOnEjQg1dI80Y3hn /SDg== X-Gm-Message-State: ALoCoQmQoGkuNo5UR+M9qH4is/trJJ5kcnQ7QDncZMT01GSXboXJBrtDIxCddiKLQOWHzx5s0YFC X-Received: by 10.66.159.201 with SMTP id xe9mr45689398pab.13.1416935466817; Tue, 25 Nov 2014 09:11:06 -0800 (PST) Received: from [10.64.26.139] ([69.53.236.236]) by mx.google.com with ESMTPSA id uy8sm2019654pab.44.2014.11.25.09.11.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 09:11:05 -0800 (PST) Sender: Warner Losh Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3E3AC760-EC54-425C-AEB4-F42CF2CF15DB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b2 From: Warner Losh In-Reply-To: <1416925387.1147.437.camel@revolution.hippie.lan> Date: Tue, 25 Nov 2014 10:11:03 -0700 Message-Id: <18F34536-CA8B-4365-BDD9-C2D23E6067AA@bsdimp.com> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <8661e3wtk6.fsf@nine.des.no> <86oarvvaet.fsf@nine.des.no> <86egsrxypx.fsf@nine.des.no> <1416925387.1147.437.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1993) Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , Mark R V Murray , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 17:11:14 -0000 --Apple-Mail=_3E3AC760-EC54-425C-AEB4-F42CF2CF15DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Nov 25, 2014, at 7:23 AM, Ian Lepore wrote: >=20 > On Tue, 2014-11-25 at 13:15 +0100, Dag-Erling Sm=F8rgrav wrote: >> Ian, please try the attached patch. >>=20 >> The way this is intended to be used is that you set up a system with = an >> /etc/rc that does nothing else than mount the root file system and >> append the output from "sysctl -b hw.attachtimes" to a log file, then >> reboot. You let it run for as long as you wish, then copy the log = file >> to another machine and run the attachtimes utility (source code = below) >> on the log file to extract the data and display either the raw = numbers >> or a histogram showing the distribution. >>=20 >> See freefall:~des/software/attachtimes.tgz for an example of how to = set >> this up. All you need is the loader and kernel, a minimal /etc, and = the >> tools required by /etc/rc (sh, fsck, mount, df, sysctl, halt, = reboot). >> The example contains quite a bit more than that because I wanted to = be >> able to boot it in single-user mode for debugging. >>=20 >> The patch can easily be modified to record the actual timestamps = instead >> of just the delta, but remember to modify the utility as well, or the >> output will be complete nonsense. >>=20 >> DES >=20 > Getting the results for this is going to take a while... I can't get = the > system past mountroot right now. I have no idea why. It's been = months > since I last successfully booted -current on this old hardware. I'm > also very busy with $work. I have similar hardware on my desk, and I might be able to find a little time to boot it. > For the 3 numbers that are identical at the start, I think we're = reading > garbage in binuptime() because the clock driver isn't working yet. = The > numbers first change with at91_st0, that's the clock driver. = atmelarm0 > is the parent of everything listed between nexus and it, so the large > number there is probably the subtraction of the post-init clock value > from the pre-init clock garbage. Yea, at best this bug is solved by initializing something to zero :) > In a more general sense, I'm going to repeat a couple things... >=20 > The clock all this is being measured with runs at 32 KHz. That's 'K=92.= Since these systems run at 200MHz or 400MHz, it makes a lot of sense that we=92re seeing the same number. That=92s like ~10k instructions = between ticks. And since that is really 32,768Hz, it makes sense that the bottom 15 bits are zeros given how bintime encodes things. > This output is evidence that the system behaves exactly as I've been > saying it behaves for a long long while. You seem convinced, I don't > understand why, that there must be some error here. I don't = understand > why you think a system like this would behave any differently each = time > it is powered on. The only actual entropy involved is whatever minor > thermal transients may exist in the crystal oscillator. With 32KHz > resolution (or even a few MHz) that amounts to not a lot of measurable > variation at all. Yes, we=92re 4 orders of magnitude above the =91changes every = instruction or so=92 notion that Mark had sent out. > The repeatability of the boot sequence of hardware like this is nearly > perfect at the resolution we're measuring. While that may be bad for > gathering entropy, it's a wonderful thing when you're debugging, = because > problems that would be almost impossible to nail down on modern = complex > hardware are 100% reproducible by just hitting the reset button. That > reproducibility extends all the way into multiuser mode unless there = is > a network connection where packet arrival times start adding > interrupt-based entropy. Yea, every boot it is the same registers that are being read, in the same sequence, resulting in very similar cache patterns and performance profiles. I=92d be surprised if anything apart from the ethernet chip=92s state was different between boots. And even the ethernet=92s stuff has a low variance until interrupts are turned on=85 Warner --Apple-Mail=_3E3AC760-EC54-425C-AEB4-F42CF2CF15DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUdLgnAAoJEGwc0Sh9sBEAb7oP/Al2E4SXLa702GmiwHCllEQr PCl1vTy9XuBCQfgKNiT9M4MDFADg818/ZAL+kFxXVxCUvW1Lr4bUoy51bGTrdnpR +6/IGcSZ3UXm606wwuqj1FVorlgrVTxnXybCZNRQbiHZxsDUPnEIMWEyjUMAReBu RHkUUyYWSLRe2P/Mx30fMOygJUx1Q3NRAvhWn/gQk/viq6p9gIuR8dbwAL1tmAQX Ve1JBa6rkhp+d1/kWbSuImE3wSCIjYv8RF+/unxCZxJ1ocr2RQwXd/LavHOG7GAa e9VJb5jMRvTx/Gr5pby37UAeQGVQ4gIbiU75b9TNJXNMvi9z6f8GWbP+bn15U9tK 0cFe8ww6QZaP7L/XuWUtfOM4IjUMK4+2UVHf1XiePVACJ5WHt8sMlzMJWDVocenC VaN+QazmVJqpQxPEMQQyukDHJ9QwKbpHt/qMy8BK75d65s7rBXuwYiPBg0oYvIAk 2HBio3IkWgji0fsZzZMdIfMndie+Rd1YzUwv0ZAK9La0iIMgbrpw+8iDdvMQHtP+ y5AC+8UfFGz6VaZ+ZpYbqbx5GDtz8kwyI6cfjOFlcgf5OUgqZXsixbJJUI5Yz0d6 ODIwoK+sjPkqDAeODsbFXPzzdts2J+8STD7UlUasudcTHf5we9ekuMTJJuNED/BI xEoMYEJJONikyZjuXhkl =Ugyv -----END PGP SIGNATURE----- --Apple-Mail=_3E3AC760-EC54-425C-AEB4-F42CF2CF15DB-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 18:35:46 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD426B0C; Tue, 25 Nov 2014 18:35:46 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79B692F7; Tue, 25 Nov 2014 18:35:46 +0000 (UTC) Received: from [2001:470:9174:1:a022:fe58:8d38:bb1f] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XtKxh-0004J3-2z; Tue, 25 Nov 2014 18:35:43 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=windows-1252 From: Mark R V Murray In-Reply-To: <18F34536-CA8B-4365-BDD9-C2D23E6067AA@bsdimp.com> Date: Tue, 25 Nov 2014 18:35:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <8661e3wtk6.fsf@nine.des.no> <86oarvvaet.fsf@nine.des.no> <86egsrxypx.fsf@nine.des.no> <1416925387 .1147.437.camel@revolution.hippie.lan> <18F34536-CA8B-4365-BDD9-C2D23E6067AA@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: =?windows-1252?Q?Dag-Erling_Sm=F8rgrav?= , Ian Lepore , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 18:35:46 -0000 > On 25 Nov 2014, at 17:11, Warner Losh wrote: >> The repeatability of the boot sequence of hardware like this is = nearly >> perfect at the resolution we're measuring. While that may be bad for >> gathering entropy, it's a wonderful thing when you're debugging, = because >> problems that would be almost impossible to nail down on modern = complex >> hardware are 100% reproducible by just hitting the reset button. = That >> reproducibility extends all the way into multiuser mode unless there = is >> a network connection where packet arrival times start adding >> interrupt-based entropy. >=20 > Yea, every boot it is the same registers that are being read, in the > same sequence, resulting in very similar cache patterns and = performance > profiles. I=92d be surprised if anything apart from the ethernet = chip=92s > state was different between boots. And even the ethernet=92s stuff has > a low variance until interrupts are turned on=85 Things are far from perfect, but not entirely unexpected. I=92m well aware that PCs are low-entropy beasties at the best of times as we have to struggle like crazy to get what we have. The bottom-end boxes with no high-resolution timers are clearly going to be much worse. For real security, I guess the answer is cached entropy in files that are preserved over a boot and deleted straight after boot. Ian=92s case, where security is not an issue, should be solvable by getting the random(4) driver to be content with whatever it gets from the boot entropy, crappy as it is, in a way that doesn=92t offer an attack vector. This should be doable. M --=20 Mark R V Murray From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 18:43:00 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95D14ECB; Tue, 25 Nov 2014 18:43:00 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4CC653FE; Tue, 25 Nov 2014 18:42:59 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 07172A565; Tue, 25 Nov 2014 18:42:58 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 651CD12E0; Tue, 25 Nov 2014 19:42:48 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ian Lepore Subject: Re: svn commit: r274739 - head/sys/mips/conf References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <8661e3wtk6.fsf@nine.des.no> <86oarvvaet.fsf@nine.des.no> <86egsrxypx.fsf@nine.des.no> <1416925387.1147.437.camel@revolution.hippie.lan> Date: Tue, 25 Nov 2014 19:42:48 +0100 In-Reply-To: <1416925387.1147.437.camel@revolution.hippie.lan> (Ian Lepore's message of "Tue, 25 Nov 2014 07:23:07 -0700") Message-ID: <86mw7fjf4n.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, Mark R V Murray X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 18:43:00 -0000 Ian Lepore writes: > The clock all this is being measured with runs at 32 KHz. That's 'K'.=20= =20 That explains a lot. Is there absolutely no instruction counter in this chip? Any other devices we can use, such as temperature sensors or ADCs? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Nov 25 20:55:03 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1AA95C10 for ; Tue, 25 Nov 2014 20:55:03 +0000 (UTC) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D26F76A9 for ; Tue, 25 Nov 2014 20:55:02 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id fp1so1303748pdb.0 for ; Tue, 25 Nov 2014 12:54:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=1bx+MUB4fBzR+Li4XL+OZj8YWKgVvXl6KbGDcumcuQA=; b=eifs4E4iDH1QV4jIEviWJ7R/pN3lPNaSQXD8dtseFLOhn2EvtqlnFAB415ZlL5xJGS bBxfCVzirriFJfVkR03NPJVO8d47iZmQ6KFwHLaC03bqnQykaTbYTd7A9vTjHAWofHSR M9Ohr1AlHcDbR8JwSYSHvev0QSbB+BVVnY1Xt9CI5J+4NY271jWdnGCzbxDKeUDZRTtb vyG68jOcr4DllxUcwbTlNshNGPeOa7EtQA6Dp2ZCOT8uaKqzd3hQrO0VZlSM+mwK3WsW krcuSGSIb++AIwDfCjceNVcg/5IzwjMTMgAmD97Q0D54bNDxvHSP8w5qh/oZ2jTFurb3 a5FA== X-Gm-Message-State: ALoCoQmdppP58VWTXfetXwCwoZR7DPaNUXddNPC92I8xVZ8IV2uSPV5PN9UcmADyVYtVP/3JTfvM X-Received: by 10.66.253.34 with SMTP id zx2mr45963409pac.96.1416948896807; Tue, 25 Nov 2014 12:54:56 -0800 (PST) Received: from [10.64.26.139] ([69.53.236.236]) by mx.google.com with ESMTPSA id gy10sm2288409pbd.67.2014.11.25.12.54.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 12:54:55 -0800 (PST) Sender: Warner Losh Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BF3D74F7-77DD-41E0-807F-9446E0705751"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b2 From: Warner Losh In-Reply-To: <86mw7fjf4n.fsf@nine.des.no> Date: Tue, 25 Nov 2014 13:54:28 -0700 Message-Id: <3676CE09-A68A-40F2-8D4A-F821DCD0CF0D@bsdimp.com> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <86wq6k9okk.fsf@nine.des.no> <8661e3wtk6.fsf@nine.des.no> <86oarvvaet.fsf@nine.des.no> <86egsrxypx.fsf@nine.des.no> <1416925387.1147.437.camel@revolution.hippie.lan> <86mw7fjf4n.fsf@nine.des.no> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= X-Mailer: Apple Mail (2.1993) Cc: arch@freebsd.org, Mark R V Murray , Ian Lepore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 20:55:03 -0000 --Apple-Mail=_BF3D74F7-77DD-41E0-807F-9446E0705751 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 25, 2014, at 11:42 AM, Dag-Erling Sm=C3=B8rgrav = wrote: >=20 > Ian Lepore writes: >> The clock all this is being measured with runs at 32 KHz. That's = 'K'. >=20 > That explains a lot. >=20 > Is there absolutely no instruction counter in this chip? Any other > devices we can use, such as temperature sensors or ADCs? There=E2=80=99s no temperature sensors or useful ADCs. Many of the chips don=E2=80=99t have any ADC. Some have ADCs, but the OS can=E2=80=99t = necessarily use them easily in the boot process. Any ADCs that we might have on the chip (and it varies from chip to chip which we won=E2=80=99t know = until late in the boot process) aren=E2=80=99t necessarily wired to anything and often times share pins with other functions which could be quite disruptive to bring on line (ADC on an unconnected line on these chips likely isn=E2=80=99t going to give that much entropy since = you=E2=80=99re measuring grounded pins). There=E2=80=99s really no good sources of entropy in these systems until unpredictable peripherals get online (network, SD cards, etc) and then it is too late. These chips are based on the ARM920 and ARM926 cores, which don=E2=80=99t have instruction counters, unlike their newer brethren. = This is fairly typical of the embedded space: unless you really need feature X, it is omitted. Warner --Apple-Mail=_BF3D74F7-77DD-41E0-807F-9446E0705751 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUdOyEAAoJEGwc0Sh9sBEA/a4P+QEEXtzd5JAkWu8R6t0f29he IWIDMxsgew8SQXMUyMG9yK/TDv3DW2it9EKbO2xA/zCJRp149N1mWo14ek6O3dDj Pmi0bGKba7pO16j6Gpaj6oCAno4jSOyyYR6jxpRHGlAbcngiFZZOjSy6bXmGK6IM w9cRDp91CqmH4wHnKsDofEEGEjFo8R+79fPcQOlMcUXYzbLcTC1r7AKla6/ZLSd5 hdmOLzdByaoD1BPpdnWJzW/52Tf2U85Y7nR7273IOZ9Q/8KWEj23TOPoiN7rZILr TfX7irME5OjMXQtW5FavpWoJQjywihfzfKFTKeW2KI4zi8+3P4u7LqRbGuKcgnBQ WRc/nZLbW0SzisIcrfUJ6RrP7hwaCctE3pXw8t2xTUIuiQQ0dO+dwdATQ4ofhQT1 d2D7HgxxPjMgdUG19LnechPKPo2Ghuy1mv8iDSHRqYO90qidMZlH4E7giP5aQZzL wZS0yHapUukL+oz1OtCeclHUHN4PE/M7nokC2ukOwgtZ10z9tDRaIou4yLprmDH6 DWKEbqVJUjtvrvpvxcnj1xTvQPVfRcnNjw+fRu2lCQHmgeZjjVroJTub/wV3dbYN kL9j9uS+IIyS41HQKYzxIeY3Cq+YvU8t/cvZV306oWxSxYS1+oh4BT86Kr30p+uP 2uv1EVp+v/lhRuUSH+Qy =l0MD -----END PGP SIGNATURE----- --Apple-Mail=_BF3D74F7-77DD-41E0-807F-9446E0705751-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 26 01:12:45 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9CC7A19 for ; Wed, 26 Nov 2014 01:12:45 +0000 (UTC) Received: from kawasaki3.org (blackpearl.kawasaki3.org [173.230.157.78]) by mx1.freebsd.org (Postfix) with ESMTP id B5CD13B4 for ; Wed, 26 Nov 2014 01:12:45 +0000 (UTC) Received: from localhost (p7195-ipbffx02marunouchi.tokyo.ocn.ne.jp [61.126.191.195]) (Authenticated sender: moto) by kawasaki3.org (Postfix) with ESMTPSA id 0E1441CFFC; Tue, 25 Nov 2014 20:12:43 -0500 (EST) Date: Wed, 26 Nov 2014 10:12:25 +0900 (JST) Message-Id: <20141126.101225.716034406244872775.moto@kawasaki3.org> To: des@des.no Subject: Re: I'd like to axe some drivers From: moto kawasaki In-Reply-To: <86a93fxym0.fsf@nine.des.no> References: <20141125.105157.1187546753207512759.moto@kawasaki3.org> <20141125090938.GH15721@e-new.0x20.net> <86a93fxym0.fsf@nine.des.no> X-Face: )._4~w!_D$r6qNS0+; nS|]WNeI4f3o)QnH[ItB[esXuc$~hQ$.,?}$SnLe/[24Hao%^q/Is 'SJtZe#21h;7z;q+iyj[^%7\46.Gg-t7.px<}L-f_:P+6i4-a{DIL[ X-Mailer: Mew version 6.5 on Emacs 24.3.50 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, lars.engels@0x20.net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 01:12:45 -0000 Sirs, Thank you very much and now I understood. mk From: Dag-Erling Sm=F8rgrav To: Lars Engels Cc: arch@freebsd.org, moto kawasaki Subject: Re: I'd like to axe some drivers Date:Tue, 25 Nov 2014 13:18:15 +0100 Message-ID: <86a93fxym0.fsf@nine.des.no> des> Lars Engels writes: des> > moto kawasaki writes: des> > > If removed, how can I use those device drivers ? [...] I des> > > personally runs fxp and dc on my home pc, so I am very curious= .= des> > You can usually just load the kernel module with kldload(8). des> = des> or add des> = des> if_dc_load=3Dyes des> if_fxp_load=3Dyes des> = des> to /boot/loader.conf. des> = des> DES des> -- = des> Dag-Erling Sm=F8rgrav - des@des.no des> _______________________________________________ des> freebsd-arch@freebsd.org mailing list des> http://lists.freebsd.org/mailman/listinfo/freebsd-arch des> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd= .org" From owner-freebsd-arch@FreeBSD.ORG Wed Nov 26 21:37:19 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5D5183F for ; Wed, 26 Nov 2014 21:37:18 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C704078A for ; Wed, 26 Nov 2014 21:37:18 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 8F2951928D6 for ; Wed, 26 Nov 2014 21:37:11 +0000 (UTC) Message-ID: <1417037830.4680.4.camel@ignoranthack.me> Subject: How is MACHINE_ARCH dervived by make? From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-arch@freebsd.org Date: Wed, 26 Nov 2014 13:37:10 -0800 Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.7 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 21:37:19 -0000 I have yet to find the magic bit in the build sys that causes ports to go off and think that I'm building for amd64. Building on a real amd64 box inside of an emulated jail via qemu and I still am getting tripped up by something in our system thinking that I want amd64 as the MACHINE_ARCH. ---- emulation jail, showing arm/armv6 ------ root@crack:/usr/share/mk # uname -a FreeBSD crack.ysv.freebsd.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r274799: Fri Nov 21 17:29:42 UTC 2014 sbruno@crack.ysv.freebsd.org:/usr/obj/usr/src/sys/CRACK arm root@crack:/usr/share/mk # sysctl hw.machine_arch hw.machine hw.machine_arch: armv6 hw.machine: arm ---------- e.g. math/fftw3 --> make -DBATCH -dA ------ Global:.CURDIR = /usr/ports/math/fftw3 Caching /usr/ports/math/fftw3 ...done Global:.OBJDIR = /usr/ports/math/fftw3 Caching . ...done Global:delete .PATH (not found) Global:.PATH = . Global:.PATH = . /usr/ports/math/fftw3 Global:.TARGETS = Caching /usr/share/mk ...done Expanding "sys.mk"... /usr/share/mk/sys.mk Internal:MAKEFILE = /usr/share/mk/sys.mk Global:.MAKE.MAKEFILES = /usr/share/mk/sys.mk Parse_SetInput: file /usr/share/mk/sys.mk, line 0, fd -1, nextbuf 0x413210, arg 0x800c5d370 Global:.PARSEDIR = /usr/share/mk Global:.PARSEFILE = sys.mk ParseSetParseFile: ${.PARSEDIR} = `/usr/share/mk' ${.PARSEFILE} = `sys.mk' ParseReadLine (4): 'unix ?= We run FreeBSD, not UNIX.' Global:unix = We run FreeBSD, not UNIX. ParseReadLine (5): '.FreeBSD ?= true' Global:.FreeBSD = true ParseReadLine (16): 'MACHINE_CPUARCH=${MACHINE_ARCH:C/mips(n32| 64)?(el)?/mips/:C/arm(v6)?(eb|hf)?/arm/:C/powerpc64/powerpc/}' Global:MACHINE_CPUARCH = ${MACHINE_ARCH:C/mips(n32| 64)?(el)?/mips/:C/arm(v6)?(eb|hf)?/arm/:C/powerpc64/powerpc/} ParseReadLine (31): '.SUFFIXES: .out .a .ln .o .c .cc .cpp .cxx .C .m .F .f .e .r .y .l .S .asm .s .cl .p .h .sh' ParseDoDependency(.SUFFIXES: .out .a .ln .o .c .cc .cpp .cxx .C .m .F .f .e .r .y .l .S .asm .s .cl .p .h .sh) ParseReadLine (34): 'AR ?= ar' Global:AR = ar ParseReadLine (38): 'ARFLAGS ?= -crD' Global:ARFLAGS = -crD ParseReadLine (40): 'RANLIB ?= ranlib' Global:RANLIB = ranlib ParseReadLine (42): 'RANLIBFLAGS ?= -D' Global:RANLIBFLAGS = -D ParseReadLine (45): 'AS ?= as' Global:AS = as ParseReadLine (46): 'AFLAGS ?=' Global:AFLAGS = ParseReadLine (47): 'ACFLAGS ?=' Global:ACFLAGS = ParseReadLine (53): 'CC ?= cc' Global:CC = cc Applying[MACHINE_ARCH] :C to "amd64" Modifier pattern: "mips(n32|64)?(el)?" Modifier pattern: "mips" Result[MACHINE_ARCH] of :C is "amd64" Applying[MACHINE_ARCH] :C to "amd64" Modifier pattern: "arm(v6)?(eb|hf)?" Modifier pattern: "arm" Result[MACHINE_ARCH] of :C is "amd64" Applying[MACHINE_ARCH] :C to "amd64" Modifier pattern: "powerpc64" Modifier pattern: "powerpc" Result[MACHINE_ARCH] of :C is "amd64" lhs = "amd64", rhs = "arm", op = == Applying[MACHINE_ARCH] :C to "amd64" Modifier pattern: "mips(n32|64)?(el)?" Modifier pattern: "mips" Result[MACHINE_ARCH] of :C is "amd64" Applying[MACHINE_ARCH] :C to "amd64" Modifier pattern: "arm(v6)?(eb|hf)?" Modifier pattern: "arm" From owner-freebsd-arch@FreeBSD.ORG Wed Nov 26 21:41:44 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98F69A95; Wed, 26 Nov 2014 21:41:44 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61628869; Wed, 26 Nov 2014 21:41:44 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id et14so3626178pad.15 for ; Wed, 26 Nov 2014 13:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=tzrQ69qn8AOXwNC8C83AL8+Tu/h7lzUWw3gOJ2tpjh0=; b=LmusdF6m21NrYuOIw+zkp3jHqjesb+Z1/zsyxMe+N5s0wPp7yKw+GkzLwvVdumHu7B yz9fnFwKCUCEmxgnCSoJlD3vlwyl43/ClfKZ7TQ/of61EmOQJ9KLYtJHrcAFxG58cjTz C1T0YVbwVPBLyqt46PjZ8EMyFDFdsBbZhZRhMwC8n0jT/UJpLJy5L72C1VzRohjtuP7G zSQsPZPTb1ms0l7mID63umz0t8/SYc+abgXZ1D9tZ788f1HOUqyGc0Xv8Xy0CUzwgcnE 9py/EA85roOLBwmgb4pjvmbDW2ee2IA+uqo333omO5NvZB4RUpAAYVcA/tNdQ4u9d3xa 4veQ== X-Received: by 10.68.215.100 with SMTP id oh4mr57233177pbc.11.1417038103964; Wed, 26 Nov 2014 13:41:43 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:4cc2:1016:46f0:ad71? ([2601:8:ab80:7d6:4cc2:1016:46f0:ad71]) by mx.google.com with ESMTPSA id u4sm5164054pbs.60.2014.11.26.13.41.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Nov 2014 13:41:43 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_29B07595-81CA-4899-BF74-0EF53F717AE2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: How is MACHINE_ARCH dervived by make? From: Garrett Cooper In-Reply-To: <1417037830.4680.4.camel@ignoranthack.me> Date: Wed, 26 Nov 2014 13:41:39 -0800 Message-Id: <6BCC0757-6BAD-4D3F-A606-414478112143@gmail.com> References: <1417037830.4680.4.camel@ignoranthack.me> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 21:41:44 -0000 --Apple-Mail=_29B07595-81CA-4899-BF74-0EF53F717AE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 26, 2014, at 13:37, Sean Bruno wrote: > I have yet to find the magic bit in the build sys that causes ports to > go off and think that I'm building for amd64. Building on a real = amd64 > box inside of an emulated jail via qemu and I still am getting tripped > up by something in our system thinking that I want amd64 as the > MACHINE_ARCH. It=92s handled in bmake/make. If you need to crossbuild, you=92ll = probably need to tell make what your MACHINE_ARCH/MACHINE is. Please refer to the manpages for more details. Cheers! $ grep -rl MACHINE_ARCH contrib/bmake/ usr.bin/make | grep '\.c$' contrib/bmake/main.c contrib/bmake/arch.c usr.bin/make/main.c --Apple-Mail=_29B07595-81CA-4899-BF74-0EF53F717AE2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUdkkTAAoJEMZr5QU6S73exm8IAJDTlpqKf6mYGdd1/4KovC0S XpvVhF4BMf9pdwsNZiAjfxIU8qUhv+Vio6v22xcHFWampQlUZhTTaUj1t/JN24eh GmC15vA3h6mIfNK31aHS71q7S8Ltuk32xE5SGviV5AVaY5pZne6NWKr4vtznicVa n9RY229JlBESYeXxWXcn1RDHApSU0N8KE3V954JMBJTd+Pp7J6d/13wX63mLgbOZ YGvpmWV15FXxMkQusjGmCaEWudj2Kkw56+YirBqr8wYnlJxbbfPkOUyrPNMOXDVq Y1N3ZofY7HhRhKnwX8IV1RxyI8SrVezmj+6NgsqnD8IjMZ2FU2J0QFgsvCHHPrE= =DhsU -----END PGP SIGNATURE----- --Apple-Mail=_29B07595-81CA-4899-BF74-0EF53F717AE2-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 26 21:56:50 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0BBDFC9; Wed, 26 Nov 2014 21:56:50 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BFA9898E; Wed, 26 Nov 2014 21:56:50 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 464B61928D6; Wed, 26 Nov 2014 21:56:49 +0000 (UTC) Message-ID: <1417039008.4680.6.camel@ignoranthack.me> Subject: Re: How is MACHINE_ARCH dervived by make? From: Sean Bruno Reply-To: sbruno@freebsd.org To: Garrett Cooper Date: Wed, 26 Nov 2014 13:56:48 -0800 In-Reply-To: <6BCC0757-6BAD-4D3F-A606-414478112143@gmail.com> References: <1417037830.4680.4.camel@ignoranthack.me> <6BCC0757-6BAD-4D3F-A606-414478112143@gmail.com> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.12.7 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 21:56:51 -0000 On Wed, 2014-11-26 at 13:41 -0800, Garrett Cooper wrote: > On Nov 26, 2014, at 13:37, Sean Bruno wrote: > > > I have yet to find the magic bit in the build sys that causes ports to > > go off and think that I'm building for amd64. Building on a real amd64 > > box inside of an emulated jail via qemu and I still am getting tripped > > up by something in our system thinking that I want amd64 as the > > MACHINE_ARCH. > > It¢s handled in bmake/make. If you need to crossbuild, you¢ll probably need to tell make what your MACHINE_ARCH/MACHINE is. > Please refer to the manpages for more details. > Cheers! > Hrm, man make doesn't bring up the bmake man page (on current). If it *did* I would have seen the MACHINE_ARCH comments that allow overrides. Odd. > $ grep -rl MACHINE_ARCH contrib/bmake/ usr.bin/make | grep '\.c$' > contrib/bmake/main.c > contrib/bmake/arch.c > usr.bin/make/main.c > Looking now ... it sort of looks like there is some shell script hackery to do this at build time that depends on uname in machine.sh and os.sh sean From owner-freebsd-arch@FreeBSD.ORG Wed Nov 26 22:05:13 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4897219A for ; Wed, 26 Nov 2014 22:05:13 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26E6EA6E for ; Wed, 26 Nov 2014 22:05:12 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 1EF161928D6 for ; Wed, 26 Nov 2014 22:05:12 +0000 (UTC) Message-ID: <1417039511.4680.8.camel@ignoranthack.me> Subject: Re: How is MACHINE_ARCH dervived by make? [SOLVED] From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-arch@freebsd.org Date: Wed, 26 Nov 2014 14:05:11 -0800 In-Reply-To: <1417039008.4680.6.camel@ignoranthack.me> References: <1417037830.4680.4.camel@ignoranthack.me> <6BCC0757-6BAD-4D3F-A606-414478112143@gmail.com> <1417039008.4680.6.camel@ignoranthack.me> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.12.7 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 22:05:13 -0000 On Wed, 2014-11-26 at 13:56 -0800, Sean Bruno wrote: > On Wed, 2014-11-26 at 13:41 -0800, Garrett Cooper wrote: > > On Nov 26, 2014, at 13:37, Sean Bruno wrote: > > > > > I have yet to find the magic bit in the build sys that causes ports to > > > go off and think that I'm building for amd64. Building on a real amd64 > > > box inside of an emulated jail via qemu and I still am getting tripped > > > up by something in our system thinking that I want amd64 as the > > > MACHINE_ARCH. > > > > It¢s handled in bmake/make. If you need to crossbuild, you¢ll probably need to tell make what your MACHINE_ARCH/MACHINE is. > > Please refer to the manpages for more details. > > Cheers! > > > > Hrm, man make doesn't bring up the bmake man page (on current). If it > *did* I would have seen the MACHINE_ARCH comments that allow overrides. > Odd. > > > $ grep -rl MACHINE_ARCH contrib/bmake/ usr.bin/make | grep '\.c$' > > contrib/bmake/main.c > > contrib/bmake/arch.c > > usr.bin/make/main.c > > > > Looking now ... it sort of looks like there is some shell script hackery > to do this at build time that depends on uname in machine.sh and os.sh > > sean > > ____________________ Ok, that gave me the clue-bat I needed. Executing "setenv MACHINE arm; setenv MACHINE_ARCH armv6" was exactly the little bit of magic I was looking for. sean From owner-freebsd-arch@FreeBSD.ORG Wed Nov 26 22:40:16 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE58C882; Wed, 26 Nov 2014 22:40:15 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7270D40; Wed, 26 Nov 2014 22:40:15 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id rd3so3714420pab.21 for ; Wed, 26 Nov 2014 14:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=yBoed2sl77Rp/2sVzBj5rjnIyujbb8rV6ZhQkBQpc9s=; b=btm4nRAiSG6fGUJz6dbwPYrHFIZE3blaugVO9Wc0wIqLvdJQkgF6jUAyLnIioqNnbq GOsr0UCq7VTLGAW+vWgdkp7WkvLjGHC+wwda4K8e5W8pHdVu4BATzL6YwF+1NPpzBbRM 02wmV1nZ6lmrjihpSQEZNWYtHzhdL4853c8QfGEjnz2VBmUk4x9dSYJf5uXxKvqYe61N 0e6uISV46HqGP+6jT3IG5gd04FpcN1BiDrL/7Q6M9PS/doBORk/9KsmjGlx0z+hfatxg yuI+ROoEFgogjmNwox1nvP3oHAnt5WPOdDK0wVG7s1Ye41wI9R72MFFpj0TJ2LlqMWd9 VJ5g== X-Received: by 10.68.130.66 with SMTP id oc2mr57614803pbb.134.1417041615297; Wed, 26 Nov 2014 14:40:15 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:4cc2:1016:46f0:ad71? ([2601:8:ab80:7d6:4cc2:1016:46f0:ad71]) by mx.google.com with ESMTPSA id hc10sm5206742pbd.78.2014.11.26.14.40.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Nov 2014 14:40:14 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C2D0A842-55BA-462C-8A05-8BDA6DB7F09A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: I'd like to axe some drivers From: Garrett Cooper In-Reply-To: <201411201631.27556.jhb@freebsd.org> Date: Wed, 26 Nov 2014 14:40:13 -0800 Message-Id: <99B70734-2E98-4E3D-AB22-583621A20C86@gmail.com> References: <201411201631.27556.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1878.6) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 22:40:16 -0000 --Apple-Mail=_C2D0A842-55BA-462C-8A05-8BDA6DB7F09A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 20, 2014, at 13:31, John Baldwin wrote: > I'm >< close to removing timeout/untimeout from the tree. As part of = this I=20 > have updated several older drivers to use callout(9), but most of = those=20 > patches were untested. Keeping old code around that no one uses does = add=20 > future work as tree-wide API changes are made as well as things like = locking=20 > (note that several of these drivers weren't locked until I recently = changed=20 > them). To that end, here is my short list of things that I think we = can bid=20 > farewell to in 11. Note that many of these are for ISA devices. =85 > si(4): This is a driver for an older ISA/EISA/PCI multiport serial = card. > It doesn't use bus_space. It was hacked up to use new tty, = but > still uses Giant. I have a partial set of outstanding = patches to > this to fix it to use bus_space, but when I sent them out for > testing on current and stable, no one replied. Please remove usr.sbin/sicontrol as well if this gets removed: OLD_FILES+=3Dusr/sbin/sicontrol OLD_FILES+=3Dusr/share/man/man8/sicontrol.8.gz ... > spic(4): At one point the Sony VAIO was "the" cool laptop, and this = driver > controlled the "jogdial" found on it and presented it as a = mouse. > This is a tiny driver and is less invasive in terms of future > maintenance than others perhaps, but my recent calls for = testing > on current@ and stable@ found no takers. It's a fairly = obscure > device and not one that exists on any recently shipped = hardware. Handling of this driver might need to be removed from moused/devd = (there=92s a reference to moused at the bottom of the manpage, but a = cursory grep reveals nothing for =93sony" or "spic"=85 hmm). Thanks! --Apple-Mail=_C2D0A842-55BA-462C-8A05-8BDA6DB7F09A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUdlbNAAoJEMZr5QU6S73ejzsH/A+VA8XAtdELnaVnlaqXRhlj e0/m636UWeHJqVxq+oYyID6ceXE+os9ikQVEN2Uf6Vyx9Q7oekLjSzUBjZ8eV8TD BMHnZVwaAI4SGA78UHVs4CLdPWvrzmV7lqpfSTbKnPCfrf/tivqWhXfJyqYCyu+X lpYMYQ4z1YjvNInx+a3hThpkMllbLCIlbj36SS54qDXZZNUdSlJhGV53LqyCW9Kx hGPeFLC4VLsVRPdsPSZPK5/aAmzI0oj3YXxqfFfMJo7cwswGXDc7nRfsQZmqixev fYtm1V9yJqTsHrs9Sz4bVL4EbDf7/oq0fakN6zH2JSZvSoxJQRC+IM5BktoYBvg= =SGZZ -----END PGP SIGNATURE----- --Apple-Mail=_C2D0A842-55BA-462C-8A05-8BDA6DB7F09A-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 26 23:26:42 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7AAFC3C; Wed, 26 Nov 2014 23:26:42 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bn0103.outbound.protection.outlook.com [157.56.110.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4685D2BB; Wed, 26 Nov 2014 23:26:41 +0000 (UTC) Received: from BLUPR05CA0050.namprd05.prod.outlook.com (10.141.20.20) by BN1PR05MB438.namprd05.prod.outlook.com (10.141.58.12) with Microsoft SMTP Server (TLS) id 15.1.26.15; Wed, 26 Nov 2014 23:26:33 +0000 Received: from BY2FFO11FD021.protection.gbl (2a01:111:f400:7c0c::173) by BLUPR05CA0050.outlook.office365.com (2a01:111:e400:855::20) with Microsoft SMTP Server (TLS) id 15.1.26.15 via Frontend Transport; Wed, 26 Nov 2014 23:26:33 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BY2FFO11FD021.mail.protection.outlook.com (10.1.15.210) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Wed, 26 Nov 2014 23:26:32 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 26 Nov 2014 15:26:32 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sAQNQVR38922; Wed, 26 Nov 2014 15:26:31 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 3ED81580A3; Wed, 26 Nov 2014 15:26:31 -0800 (PST) To: Subject: Re: How is MACHINE_ARCH dervived by make? In-Reply-To: <1417039008.4680.6.camel@ignoranthack.me> References: <1417037830.4680.4.camel@ignoranthack.me> <6BCC0757-6BAD-4D3F-A606-414478112143@gmail.com> <1417039008.4680.6.camel@ignoranthack.me> Comments: In-reply-to: Sean Bruno message dated "Wed, 26 Nov 2014 13:56:48 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.0.3; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 26 Nov 2014 15:26:31 -0800 Message-ID: <9302.1417044391@chaos> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(51704005)(199003)(24454002)(189002)(76176999)(97736003)(57986006)(117636001)(50986999)(76506005)(46102003)(110136001)(86362001)(93916002)(92726001)(92566001)(20776003)(47776003)(64706001)(89996001)(95666004)(87936001)(31966008)(88136002)(69596002)(104166001)(68736004)(107046002)(2351001)(99396003)(120916001)(44976005)(6806004)(19580405001)(19580395003)(81156004)(106466001)(105596002)(21056001)(102836001)(84676001)(33716001)(4396001)(50226001)(48376002)(50466002)(87286001)(62966003)(77156002)(42262002)(62816006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB438; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB438; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB438; X-Forefront-PRVS: 04073E895A Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=sjg@juniper.net; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB438; X-OriginatorOrg: juniper.net Cc: Garrett Cooper , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 23:26:42 -0000 Sean Bruno wrote: > > > I have yet to find the magic bit in the build sys that causes ports to > > > go off and think that I'm building for amd64. Building on a real amd64 When you run make, if MACHINE, MACHINE_ARCH etc are not set in environment make will ask the kernel. > Looking now ... it sort of looks like there is some shell script hackery > to do this at build time that depends on uname in machine.sh and os.sh You can ignore all that - it isn't relevant on BSD. [bmake builds on some pretty weird systems] If built with -DMAKE_NATIVE (it is in FreeBSD), then what ever the kernel provides is used if env vars are missing. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 28 06:51:08 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6799CD29 for ; Fri, 28 Nov 2014 06:51:08 +0000 (UTC) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailuogwprd51.lss.emc.com", Issuer "RSA Corporate Server CA v2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1B45A67 for ; Fri, 28 Nov 2014 06:51:07 +0000 (UTC) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sAS6Ow1E011772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2014 01:24:59 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com sAS6Ow1E011772 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1417155899; bh=rpAz1ks9oUqAj6wm/4AxAHJs/+U=; h=From:To:CC:Date:Subject:Message-ID:Content-Type:MIME-Version; b=QHwbAvvvRLMmFgJTAUqE/mvVi79ht/s8suXv3aXlELwzX5MShZ0uB4gZFfLYtukrI V7EZZeFAviNG64jwAQqmQmWJqNrknFsYSox9M/LsimRbFMsJCCkqvvfk+jCDpKsZGa w6IanDAb4KN7LynBOKM/DsvbpyiafxIiCK9xEm1Q= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com sAS6Ow1E011772 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd55.lss.emc.com (RSA Interceptor); Fri, 28 Nov 2014 01:24:25 -0500 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sAS6OiC4028434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Nov 2014 01:24:45 -0500 Received: from mx18a.corp.emc.com ([169.254.1.2]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Fri, 28 Nov 2014 01:24:43 -0500 From: "Dubey, Rama" To: "freebsd-arch@FreeBSD.org" Date: Fri, 28 Nov 2014 01:24:40 -0500 Subject: EMC SR#67530506 Thread-Topic: EMC SR#67530506 Thread-Index: AdAK08HC7P2d6uFTR4CZrPZ1zSHB0Q== Message-ID: <1EC5119C91E244438CBD17AC7B5F79B926EF8C5C17@MX18A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "backup@datapipe.com" , Gts_india_Symm_Chat , GTS India Symm Mgrs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 06:51:08 -0000 Hello Team Customer has Reached to EMC regarding FreeBSD However EMC do not support FreeBSD Could you please confirm if VMAX10K supports FreeBSD Please use Reply all option while replying . Thanks and Regards Rama Dubey Customer Service, Symmetrix Office #: 1-800-782-4362 ext. 57600 Email: rama.dubey@emc.com Online Support: https://support.emc.com [cid:image001.jpg@01D00B02.17A84C10] Please let us know what you think of the level of service provided by sendi= ng an email to my manager (Raghunath Goud) at raghunath.goud@emc.com. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 28 09:04:23 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C35887AA for ; Fri, 28 Nov 2014 09:04:23 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [74.201.84.155]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A92B88AA for ; Fri, 28 Nov 2014 09:04:23 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=bsdjunk; d=bsdjunk.com; h=date:from:to:cc:message-id:in-reply-to:references:subject:mime-version:content-type:user-agent; b=bglDW7WmVYy6KsJTVC7hd5pk6T8R/EN9jWv4JuiQahbCe4jeX17OGy0XZrwa68hU0AMQGbiZ8MMG QGBV3UUxZhNYB8Fx7oXO0YdHHQ0bPNdI/5VwsH8+UBUEyAIKi5iST1Y0tAlmKvSnO3AshcagxYiE YGe6ZnMDqfCAI+qf1ow= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1417165456404191.52661659396904; Fri, 28 Nov 2014 01:04:16 -0800 (PST) Date: Fri, 28 Nov 2014 03:04:16 -0600 From: chris To: Dubey Message-ID: <149f5a4c3df.10aba861b596938.3981256195208052116@bsdjunk.com> In-Reply-To: <1EC5119C91E244438CBD17AC7B5F79B926EF8C5C17@MX18A.corp.emc.com> References: <1EC5119C91E244438CBD17AC7B5F79B926EF8C5C17@MX18A.corp.emc.com> Subject: Re: EMC SR#67530506 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Cc: Gts_india_Symm_Chat , "backup@datapipe.com" , GTS India Symm Mgrs , "freebsd-arch@FreeBSD.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 09:04:23 -0000 Hi, I can't seem to find any indication that's theirs a driver for FreeBSD using Google. I am sure if there are drivers someone will reply with said info. ------------------------------------- Chris Petrik FreeBSD Developer E on FreeBSD ------ As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie ---- On Fri, 28 Nov 2014 00:24:40 -0600 Dubey wrote ---- > Hello Team > > Customer has Reached to EMC regarding FreeBSD > However EMC do not support FreeBSD > > Could you please confirm if VMAX10K supports FreeBSD > > Please use Reply all option while replying . > > > Thanks and Regards > Rama Dubey > Customer Service, Symmetrix > Office #: 1-800-782-4362 ext. 57600 > Email: rama.dubey@emc.com > Online Support: https://support.emc.com > [cid:image001.jpg@01D00B02.17A84C10] > Please let us know what you think of the level of service provided by sending an email to my manager (Raghunath Goud) at raghunath.goud@emc.com. > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Sat Nov 29 09:28:59 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 169D6AE4; Sat, 29 Nov 2014 09:28:59 +0000 (UTC) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 84E97EDD; Sat, 29 Nov 2014 09:28:58 +0000 (UTC) Received: by mail-la0-f53.google.com with SMTP id gm9so6722193lab.12 for ; Sat, 29 Nov 2014 01:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nOk/8cDzD87G+NOCc1gE5lBPOJzp7QitMiSZ38qjqEM=; b=yygMI2Y6x6B1LeOnyGMIOJYBX/Mm6Yb5TRmVIpsHP0aXzhb/6m1B00Ka57TnbKk30m CVnHTgZ0CtW/0NAzIqeXRcyWNrvV3CjM6dv/3olqLHIgRFfm1Z2KA3jLzxJvZQFIZlxS l4XiZ0yORrlwWnXDQCa57HSgfFS+7nMxY5Wtu2RBeLhKphl8WxvH1jXzd4OtAUmbHH4q iBRAi4yrNfqnS4h20L/lklGcWnhs5Xxt1g6rmx9GvDAwVoAlGlYDqmciMdQKl2F9beAR aVHJyXH7H4gve469BgNErhiVH6dRD+wriX/oNzOp2h4AVdZaxXh4tTN02Awng7nMDXs5 ji1w== MIME-Version: 1.0 X-Received: by 10.152.88.44 with SMTP id bd12mr32125249lab.88.1417253335677; Sat, 29 Nov 2014 01:28:55 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.130.168 with HTTP; Sat, 29 Nov 2014 01:28:55 -0800 (PST) In-Reply-To: <547364EB.7090505@freebsd.org> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> <547364EB.7090505@freebsd.org> Date: Sat, 29 Nov 2014 01:28:55 -0800 X-Google-Sender-Auth: INz4Aba9egH0dYwnkJ6vYYSijMk Message-ID: Subject: Re: RFC: Enabling VIMAGE in GENERIC From: Craig Rodrigues To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 09:28:59 -0000 On Mon, Nov 24, 2014 at 9:03 AM, Julian Elischer wrote: > > > also look at the following: (a little dated) > > http://p4web.freebsd.org/@md=d&cd=//depot/projects/vimage/&cdf=//depot/projects/vimage/porting_to_vimage.txt&c=tO0@//depot/projects/vimage/porting_to_vimage.txt?ac=22 This is a useful document. I put it on the wiki: https://wiki.freebsd.org/VIMAGE/porting-to-vimage -- Craig From owner-freebsd-arch@FreeBSD.ORG Sat Nov 29 20:16:11 2014 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EFDFA20 for ; Sat, 29 Nov 2014 20:16:11 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E93EBFFF for ; Sat, 29 Nov 2014 20:16:10 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id sATKFvlq060213; Sat, 29 Nov 2014 12:16:01 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201411292016.sATKFvlq060213@gw.catspoiler.org> Date: Sat, 29 Nov 2014 12:15:57 -0800 (PST) From: Don Lewis Subject: Re: I'd like to axe some drivers To: imp@bsdimp.com In-Reply-To: <573D346B-3AB8-4EC7-A03F-1B2B1291A5BC@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: arch@FreeBSD.org, jmg@funkthat.com X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 20:16:11 -0000 Catching up ... > The CardBus ones (dc, fxp, rl, re and xl) are less no-brainerish. Older 64-bit > laptops have only CardBus, and some have these built-in. Since these types > of systems are rare, and rarely NFS boot, having them as modules is likely > fine. The re interface is very common on recent consumer-grade AMD motherboards and it would not be good to break network boot and network install on them. FreeBSD 10.1-STABLE #4 r275233: Fri Nov 28 23:50:53 PST 2014 dl@hoover:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: AMD FX(tm)-4100 Quad-Core Processor (3624.26-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x600f12 Family = 0x15 Model = 0x1 Stepping = 2 Features=0x178bfbff Features2=0x1e98220b AMD Features=0x2e500800 AMD Features2=0x1c9bfff TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16573792256 (15806 MB) [SNIP] re0: port 0x8e00-0x8 eff mem 0xfd4ff000-0xfd4fffff,0xfd4f8000-0xfd4fbfff irq 17 at device 0.0 on pci7 re0: Using 1 MSI-X message re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00100000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX , 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX- master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 I've got a pile of fxp PCI cards around here, though only one is in currently in use in an i386 machine (and I do PXE boot that interface). The same machine also has a de card in it. I really need to swap that one out for something more modern because it doesn't handle autonegotiation (well?) as I recall. I've got a pile of ISA hardware around here, but none of it is currently in use. All the motherboards have PCI slots, so I'd use PCI NICs with them, but I think I have some ISA NICs, probably some variety of 3com. From owner-freebsd-arch@FreeBSD.ORG Sat Nov 29 20:52:28 2014 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C1CE963; Sat, 29 Nov 2014 20:52:28 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4111A3F0; Sat, 29 Nov 2014 20:52:27 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xup09-000FuF-18; Sat, 29 Nov 2014 20:52:21 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sATKqJAH001578; Sat, 29 Nov 2014 13:52:19 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX180jlJua7OLtvYER4Csd9c4 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: I'd like to axe some drivers From: Ian Lepore To: Don Lewis In-Reply-To: <201411292016.sATKFvlq060213@gw.catspoiler.org> References: <201411292016.sATKFvlq060213@gw.catspoiler.org> Content-Type: text/plain; charset="us-ascii" Date: Sat, 29 Nov 2014 13:52:19 -0700 Message-ID: <1417294339.87127.12.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, jmg@funkthat.com X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 20:52:28 -0000 On Sat, 2014-11-29 at 12:15 -0800, Don Lewis wrote: > Catching up ... > > > The CardBus ones (dc, fxp, rl, re and xl) are less no-brainerish. Older 64-bit > > laptops have only CardBus, and some have these built-in. Since these types > > of systems are rare, and rarely NFS boot, having them as modules is likely > > fine. > > The re interface is very common on recent consumer-grade AMD > motherboards and it would not be good to break network boot and network > install on them. I'm not sure how re found its way into this discussion, but it wasn't on the original list of proposed deletions, and it wasn't in jmg's list of 100BT nics to leave out of amd64's GENERIC. -- Ian From owner-freebsd-arch@FreeBSD.ORG Sat Nov 29 22:36:06 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2840BFA; Sat, 29 Nov 2014 22:36:05 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8AC78E81; Sat, 29 Nov 2014 22:36:04 +0000 (UTC) Received: from [192.168.225.11] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id sATMZifh045093; Sat, 29 Nov 2014 23:35:53 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <547A4A40.80406@fgznet.ch> Date: Sat, 29 Nov 2014 23:35:44 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Don Lewis , imp@bsdimp.com Subject: Re: I'd like to axe some drivers References: <201411292016.sATKFvlq060213@gw.catspoiler.org> In-Reply-To: <201411292016.sATKFvlq060213@gw.catspoiler.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: arch@freebsd.org, jmg@funkthat.com X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 22:36:06 -0000 On 29.11.14 21:15, Don Lewis wrote: > Catching up ... > >> The CardBus ones (dc, fxp, rl, re and xl) are less no-brainerish. Older 64-bit >> laptops have only CardBus, and some have these built-in. Since these types >> of systems are rare, and rarely NFS boot, having them as modules is likely >> fine. > > The re interface is very common on recent consumer-grade AMD > motherboards and it would not be good to break network boot and network > install on them. +1 CPU: AMD Phenom(tm) 9650 Quad-Core Processor (2299.97-MHz K8-class CPU) re0: port 0xee00-0xeeff mem 0xfdfff000-0xfdffffff irq 19 at device 0.0 on pci2 re1: port 0xce00-0xceff mem 0xfdeff000-0xfdeff0ff irq 21 at device 6.0 on pci3