From owner-freebsd-arm@FreeBSD.ORG Tue Dec 30 01:45:51 2008 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 004CB106566B for ; Tue, 30 Dec 2008 01:45:50 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 938F68FC1D for ; Tue, 30 Dec 2008 01:45:50 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mBU1hUau000112 for ; Mon, 29 Dec 2008 18:43:30 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 29 Dec 2008 18:43:39 -0700 (MST) Message-Id: <20081229.184339.1791045642.imp@bsdimp.com> To: arm@FreeBSD.org From: "M. Warner Losh" X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Dec_29_18_43_39_2008_883)--" Content-Transfer-Encoding: 7bit Cc: Subject: Fw: Cirrus EP93xx MaverickCrunch GCC 4.3.2 patches X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2008 01:45:51 -0000 ----Next_Part(Mon_Dec_29_18_43_39_2008_883)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit FYI. I've not evaluated these patches, but thought people here might be interested in them. Warner ----Next_Part(Mon_Dec_29_18_43_39_2008_883)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Delivery-Date: Mon, 29 Dec 2008 18:06:51 -0700 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on harmony.bsdimp.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=3.5 tests=EMPTY_MESSAGE, MISSING_SUBJECT, NO_RECEIVED autolearn=no version=3.2.5 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mBU14KJ1099767 for ; Mon, 29 Dec 2008 18:04:21 -0700 (MST) (envelope-from bounces-port-arm-owner-imp=bsdimp.com@NetBSD.org) Received: by mail.netbsd.org (Postfix, from userid 0) id 2D1F163B122; Tue, 30 Dec 2008 01:04:17 +0000 (UTC) Delivered-To: port-arm@netbsd.org Received: from mail-ew0-f17.google.com (mail-ew0-f17.google.com [209.85.219.17]) by mail.netbsd.org (Postfix) with ESMTP id 8E8F263B108 for ; Tue, 30 Dec 2008 01:04:15 +0000 (UTC) Received: by ewy10 with SMTP id 10so5275821ewy.13 for ; Mon, 29 Dec 2008 17:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=g8oEvQPnUPgJLJxC2KE2Di19s+1JoqijtD0WZ8POflw=; b=wQPDBT0PDVXMr5H+5GT5lK/XpdHQRbg7cmA4AQBuWk/pIxRmqFhfh4IqzoZTudKyA+ fS00TRa2GmNpFv/6eGraq1TeZPXE8cNgYoqlnAzW0BImabGVcyTJ3IKWZ5xjk4F6QI9V aArcnWZ9SQBEw+yVkF2v64ku1u7ko3/7heZZ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=rp5p6QX7TvZ3t7zBzrMYKfz2tk3wb3ym9egxND1hKm2fdrKeP/lNslezZ2M7zv9hn6 KNSjszOrJVt5CJ/COGxKmmtNhJXMO5py8kkNGaMIcXw4UV61g6mZ6AfFlgWQa5f2gzP2 FDgkcMs8bWw1F8sNjJ8x5cRFoF+rKM7uz+zsI= Received: by 10.210.144.3 with SMTP id r3mr4735300ebd.198.1230599054311; Mon, 29 Dec 2008 17:04:14 -0800 (PST) Received: by 10.210.129.20 with HTTP; Mon, 29 Dec 2008 17:04:14 -0800 (PST) Message-ID: <56d259a00812291704y7fa38d0h26762c221be23a62@mail.gmail.com> Date: Tue, 30 Dec 2008 01:04:14 +0000 From: "Martin Guy" To: "debian-arm@lists.debian.org" , port-arm@NetBSD.org, linux-arm@lists.arm.linux.org.uk Subject: Cirrus EP93xx MaverickCrunch GCC 4.3.2 patches MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: f7184a8d0764ce69 Sender: port-arm-owner@NetBSD.org List-Id: port-arm Precedence: list Hi all Thought I'd broadcast this more widely in the hope of catching more Crunh-weary folks ;) ---------- Forwarded message ---------- From: Martin Guy Date: Dec 18, 2008 2:39 PM Subject: Re: in at the deep end To: linux-cirrus@freelists.org Ok, I have working Maverick patches for gcc-4.3.2. Main differences from the Futaris 4.1.2 and 4.2.0 ones: - no negative impact on speed of regular ARM code - addition of -mieee flag for full IEEE precision at about half of full speed - generated floating point code is about 10% faster See martinwguy.co.uk/martin/crunch for patches, native compiler tarballs and description. While I've compiled and run testsuite of various real programs, the infamous "paranoia" IEEE conformance torture test when testing double precision, fails in bizarre ways (see above web page). This seems to be due to further undocumented subtle timing bugs in the silicon, which only "paranoia" is unlucky enough to tickle. Enjoy; feedback welcome M ----Next_Part(Mon_Dec_29_18_43_39_2008_883)---- From owner-freebsd-arm@FreeBSD.ORG Tue Dec 30 06:59:16 2008 Return-Path: Delivered-To: arm@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1DA21065670 for ; Tue, 30 Dec 2008 06:59:16 +0000 (UTC) (envelope-from support@steampowered.com) Received: from rg5.comporium.net (rg5.comporium.net [208.104.2.25]) by mx1.freebsd.org (Postfix) with ESMTP id A54688FC12 for ; Tue, 30 Dec 2008 06:59:16 +0000 (UTC) (envelope-from support@steampowered.com) Received: from 67-197-55-163.fmdt.2wcm.comporium.net (HELO 192.168.1.109) ([67.197.55.163]) by rg5.comporium.net (MOS 3.8.4-GA FastPath queued) with SMTP id BHV39475; Tue, 30 Dec 2008 01:39:15 -0500 (EST) From: "Steam Support" To: "arm" Date: Tue, 30 Dec 2008 01:39:07 -0500 Organization: Valve Corp. MIME-Version: 1.0 Message-Id: <200812300639.BHV39475@rg5.comporium.net> X-Junkmail-Status: score=10/70, host=rg5.comporium.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A01020A.4959C213.009C,ss=1,fgs=0, ip=67.197.55.163, so=2007-03-13 10:31:19, dmn=5.7.1/2008-09-02 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Steam Account Status X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2008 06:59:17 -0000 Hello Steam user, It has been brought to our attention that multiple IP addresses are accessing your account. The Steam EULA clearly states that there is to be NO SHARING of accounts. If you believe someone has illegally accessed your account, please verify your account information here. In addition to this security breach, a possible cheating infraction may be issued for the following reason(s): VAC has detected an unknown application modifying the following game(s): ------------------------------- Counter Strike: Source ------------------------------- It is strongly recommended that you verify your account so that we can restrict the unauthorized IP addresses. Failure to react may result in your account's termination. You may verify your account at http://support.steampowered.com/verify.htm Regards, The Steam Support Team -Valve This notification has been sent to the e-mail address you provided when you created your Steam account. For information on Valve's privacy policy, please visit http://www.valvesoftware.com/privacy.htm From owner-freebsd-arm@FreeBSD.ORG Wed Dec 31 11:18:48 2008 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 386FE106566C; Wed, 31 Dec 2008 11:18:48 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id ECC058FC0C; Wed, 31 Dec 2008 11:18:47 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id mBVBIk33019336; Wed, 31 Dec 2008 04:18:46 -0700 Message-ID: <495B5531.8040604@semihalf.com> Date: Wed, 31 Dec 2008 12:19:13 +0100 From: Grzegorz Bernacki MIME-Version: 1.0 To: Marcel Moolenaar References: <494BAA90.7000801@semihalf.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, embedded@freebsd.org Subject: Re: Multiple virtual mappings considered harmful on ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2008 11:18:48 -0000 Marcel Moolenaar wrote: > > On Dec 19, 2008, at 6:07 AM, Grzegorz Bernacki wrote: > >> 2. Root cause. >> The root cause of the problem is additional virtual mapping of read/write >> buffers at cluster read/write (sys/kern/vfs_cluster.c, cluster_rbuild(), >> cluster_wbuild(). Buffers for sequential read/write operation are >> concatenated >> and sent to device as one big buffer. Concatenation of buffers uses >> pmap_qenter(), which puts *additional* mapping in the KVA for physical >> area >> already mapped. For each buffer we extract pages it contains and then >> all the >> pages from all the buffers are mapped into new virtual address of new >> buffer. >> So we end up with at least two virtual addresses for each page. > > Could this also affect I-cache coherency by virtue of not > flushing the D-cache properly before synchronizing the > I-cache, as you mention reading? > I am not sure. I can't think of scenario which might lead to I-cache incoherency. Have you experienced any issues with I-cache which might be related described problem? pozdrawiam, Grzesiek From owner-freebsd-arm@FreeBSD.ORG Wed Dec 31 14:32:17 2008 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D3C11065672; Wed, 31 Dec 2008 14:32:17 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3740C8FC17; Wed, 31 Dec 2008 14:32:17 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.2/8.14.2) with ESMTP id mBVEWGGk047500; Wed, 31 Dec 2008 08:32:16 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1230733936; bh=aaaxbB/uAZe2tbfDF3E6dzb3PSd0MV69SrigECO +HqI=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=BtrGC8wg XPdhAhEW7Hw8GWRmLQ1oTbaaHnLFiyylZo5NmjsYexxcj2Ya9CEBZIV5Wau54QXR5QG qDOxujlwhHSB+HZ2ZDaYAVuLpVLOqGCmLipOsLKToWC5HlDaf/mbcqOau0ETwaiw7wZ +wAokuYWQqpRAOOOcACilDkdCRC7M= Received: (from tinguely@localhost) by casselton.net (8.14.2/8.14.2/Submit) id mBVEWF6O047499; Wed, 31 Dec 2008 08:32:15 -0600 (CST) (envelope-from tinguely) Date: Wed, 31 Dec 2008 08:32:15 -0600 (CST) From: Mark Tinguely Message-Id: <200812311432.mBVEWF6O047499@casselton.net> To: gjb@semihalf.com, xcllnt@mac.com In-Reply-To: <495B5531.8040604@semihalf.com> Cc: arm@freebsd.org, embedded@freebsd.org Subject: Re: Multiple virtual mappings considered harmful on ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2008 14:32:18 -0000 > Marcel Moolenaar wrote: > > > > On Dec 19, 2008, at 6:07 AM, Grzegorz Bernacki wrote: > > > >> 2. Root cause. > >> The root cause of the problem is additional virtual mapping of read/write > >> buffers at cluster read/write (sys/kern/vfs_cluster.c, cluster_rbuild(), > >> cluster_wbuild(). Buffers for sequential read/write operation are > >> concatenated > >> and sent to device as one big buffer. Concatenation of buffers uses > >> pmap_qenter(), which puts *additional* mapping in the KVA for physical > >> area > >> already mapped. For each buffer we extract pages it contains and then > >> all the > >> pages from all the buffers are mapped into new virtual address of new > >> buffer. > >> So we end up with at least two virtual addresses for each page. > > > > Could this also affect I-cache coherency by virtue of not > > flushing the D-cache properly before synchronizing the > > I-cache, as you mention reading? > > > > I am not sure. I can't think of scenario which might lead to I-cache incoherency. > Have you experienced any issues with I-cache which might be related described problem? > > pozdrawiam, > Grzesiek If would be surprised for you to see an I-cache problems. pmap_qenter() writes back any managed cache pages (already under the control of a pv_entry) and then calls pmap_kenter_internal(), which tries to writeback and invalid any previously mapped pages. At the end of the pmap_qenter() the caches are clean. The problem is the new mapping is added with cache turned on, and the old mapping's page table caching is not modified either, so if either side modifies the page, there can be this caching problem. I think that the pmap_kenter_internal() should become a special kind of managed page (controlled by a pv_entry and a special flag, (I called PVF_UNMAN) that runs through the pmap_fix_cache(), so the mappings for the shared page should have the cache turned off. There are special checks The less obvious question is should PG_UNMANAGED pages be simularly managed? Or put another way, could the PG_UNMANAGED page be remapped by the I/O caching programs? My guts says yes. Doing so also forces BUS_DMA_COHERENT pages to turn off the caches on the share page. I have a crude workup of my idea, but I have to admit, I don't have the equipment to even try to compile it. There concerns about pv_entry use increase, there is lock issues, performance, and even could we cause a problem trying get a pv_entry at the wrong time, such as interrupt. Maybe the kernel pv_entrys need to come from a special pool. I have some crude ideas to flush the caches less often in the ARM11's virtual index / physical tag caches and ideas for the multicore physical index / physical tag cache. --Mark Tinguely