From owner-freebsd-mips@FreeBSD.ORG Sun Jun 6 22:19:47 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AC501065679 for ; Sun, 6 Jun 2010 22:19:47 +0000 (UTC) (envelope-from phcoder@gmail.com) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by mx1.freebsd.org (Postfix) with ESMTP id F2C128FC15 for ; Sun, 6 Jun 2010 22:19:46 +0000 (UTC) Received: by ewy1 with SMTP id 1so379952ewy.33 for ; Sun, 06 Jun 2010 15:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type; bh=DaK0XcUhh5eU9aPDUA3PGPwGaMp1jN4aoeUkQlYHlgI=; b=rYHeZ73PDFpaCcCR3WYs1qjsnkDyuejHxmjbaXze3rqe+veDRM0kOw1HF3mSBx9xzQ Wipzrk9coIjZHDMVQ3o+wr7zejKsBAoa1llOr6UbJHBetczpUbxDRrz7zDhPxJk46z5N H3Xvceg+QHigx6FD13rCIqPxSWPdJlcjT7gKs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type; b=RHVE3DRJJ5SOCE42ywRh4wxERJJV1nQ+cFsr8C4SV7tp1opdr7E0ZqvxN4yH0fVdf3 re3mIpGb6CLwyClzJplWB99VVSmPVni9erIqAEvJMJMbE/WsH1EJM9nelVfydQR89+Y/ cPQBVCPeQ08kBsEsO6y+E4N5UkWD9lboSbh4s= Received: by 10.213.14.71 with SMTP id f7mr447271eba.82.1275862785753; Sun, 06 Jun 2010 15:19:45 -0700 (PDT) Received: from debian.bg45.phnet (gprs49.swisscom-mobile.ch [193.247.250.49]) by mx.google.com with ESMTPS id 15sm2240960ewy.8.2010.06.06.15.19.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 06 Jun 2010 15:19:44 -0700 (PDT) Message-ID: <4C0C1EF4.9070609@gmail.com> Date: Mon, 07 Jun 2010 00:19:32 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4 MIME-Version: 1.0 To: soc-students@freebsd.org, freebsd-mips@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3F402118708BE6723D2877D9" Cc: Subject: Weekly report on Yeeloong progress X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2010 22:19:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3F402118708BE6723D2877D9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, as my duty I report the current progress. Serial console is working Debugger including backtrace is apparently working Now it's based on octeon branch which has greatly improved 64-bit suppor= t. I'm striken by floating bugs of which I don't know the cause yet. What I tried (very incomplete list): - Disabling DMA on I/O controller by writing 0 into hit registers - Checking TLB format. TLB format on loongson is slightly different than on mips FreeBSD works on but it shouldn't have been a problem. After fixing TLB entries nothing changed - Filling cache info completely in appropriate structures When debugging it's almost always is a TLB miss. Either when accessing an address which is supposed to be ok or a wrong pointer. I'm investigati= ng. --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig3F402118708BE6723D2877D9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAkwMHvQACgkQNak7dOguQgnd+gEArj2nssElrEJOZ8rA6tJz3+Kf kcKGsXMTyZ+lbNlyCSwA/3zA4B4OeuZf7NGkOdrN8vn5SECjzlHccouI5Z66BL3a =gKat -----END PGP SIGNATURE----- --------------enig3F402118708BE6723D2877D9-- From owner-freebsd-mips@FreeBSD.ORG Sun Jun 6 22:31:00 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 954B5106566C for ; Sun, 6 Jun 2010 22:31:00 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4AFF08FC08 for ; Sun, 6 Jun 2010 22:31:00 +0000 (UTC) Received: by vws4 with SMTP id 4so834444vws.13 for ; Sun, 06 Jun 2010 15:30:59 -0700 (PDT) Received: by 10.224.96.78 with SMTP id g14mr7989383qan.117.1275863458786; Sun, 06 Jun 2010 15:30:58 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.220.180.9 with HTTP; Sun, 6 Jun 2010 15:30:37 -0700 (PDT) In-Reply-To: <4C0C1EF4.9070609@gmail.com> References: <4C0C1EF4.9070609@gmail.com> From: Juli Mallett Date: Sun, 6 Jun 2010 15:30:37 -0700 X-Google-Sender-Auth: -LDi4mM2Mvbcd7N3AIqv636gbjs Message-ID: To: =?ISO-8859-7?Q?Vladimir_=27=F6=2Dcoder=2Fphcoder=27_Serbinenko?= Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Cc: soc-students@freebsd.org, freebsd-mips@freebsd.org Subject: Re: Weekly report on Yeeloong progress X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2010 22:31:00 -0000 2010/6/6 Vladimir '=F6-coder/phcoder' Serbinenko : > Hello, as my duty I report the current progress. > Serial console is working > Debugger including backtrace is apparently working > Now it's based on octeon branch which has greatly improved =A064-bit supp= ort. Great stuff! Keep up the good work. > - Checking TLB format. TLB format on loongson is slightly different than > on mips FreeBSD works on but it shouldn't have been a problem. After > fixing TLB entries nothing changed How is it different? Do you mean that you need to use 64-bit PTEs (did you get my E-Mail about that?) or something else? Juli. From owner-freebsd-mips@FreeBSD.ORG Mon Jun 7 01:56:23 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A27051065670; Mon, 7 Jun 2010 01:56:23 +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 3E2288FC1F; Mon, 7 Jun 2010 01:56:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o571pda4099706; Sun, 6 Jun 2010 19:51:39 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 06 Jun 2010 19:51:47 -0600 (MDT) Message-Id: <20100606.195147.177916662653410057.imp@bsdimp.com> To: phcoder@gmail.com From: "M. Warner Losh" In-Reply-To: <4C0C1EF4.9070609@gmail.com> References: <4C0C1EF4.9070609@gmail.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: soc-students@FreeBSD.org, freebsd-mips@FreeBSD.org Subject: Re: Weekly report on Yeeloong progress X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 01:56:23 -0000 SW4gbWVzc2FnZTogPDRDMEMxRUY0LjkwNzA2MDlAZ21haWwuY29tPg0KICAgICAgICAgICAgVmxh ZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28gPHBoY29kZXJAZ21haWwuY29tPiB3 cml0ZXM6DQo6IEhlbGxvLCBhcyBteSBkdXR5IEkgcmVwb3J0IHRoZSBjdXJyZW50IHByb2dyZXNz Lg0KOiBTZXJpYWwgY29uc29sZSBpcyB3b3JraW5nDQo6IERlYnVnZ2VyIGluY2x1ZGluZyBiYWNr dHJhY2UgaXMgYXBwYXJlbnRseSB3b3JraW5nDQo6IE5vdyBpdCdzIGJhc2VkIG9uIG9jdGVvbiBi cmFuY2ggd2hpY2ggaGFzIGdyZWF0bHkgaW1wcm92ZWQgIDY0LWJpdCBzdXBwb3J0Lg0KOiANCjog SSdtIHN0cmlrZW4gYnkgZmxvYXRpbmcgYnVncyBvZiB3aGljaCBJIGRvbid0IGtub3cgdGhlIGNh dXNlIHlldC4gV2hhdCBJDQo6IHRyaWVkICh2ZXJ5IGluY29tcGxldGUgbGlzdCk6DQo6IC0gRGlz YWJsaW5nIERNQSBvbiBJL08gY29udHJvbGxlciBieSB3cml0aW5nIDAgaW50byBoaXQgcmVnaXN0 ZXJzDQo6IC0gQ2hlY2tpbmcgVExCIGZvcm1hdC4gVExCIGZvcm1hdCBvbiBsb29uZ3NvbiBpcyBz bGlnaHRseSBkaWZmZXJlbnQgdGhhbg0KOiBvbiBtaXBzIEZyZWVCU0Qgd29ya3Mgb24gYnV0IGl0 IHNob3VsZG4ndCBoYXZlIGJlZW4gYSBwcm9ibGVtLiBBZnRlcg0KOiBmaXhpbmcgVExCIGVudHJp ZXMgbm90aGluZyBjaGFuZ2VkDQoNCkNhbiB5b3Ugc3VtbWFyaXplIHRoZSBkaWZmZXJlbmNlIGhl cmU/ICBBbGwgdGhlIE1JUFMgcGxhdGZvcm1zIGhhdmUNCnRoZSBzYW1lIGJhc2ljIGZvcm1hdCwg YWx0aG91Z2ggdGhlcmUgYXJlIGEgZmV3IGZpZWxkcyB0aGF0IGhhdmUNCmRpdmVyZ2VudCBlbmNv ZGluZ3MuICBXZSBuZWVkIHRvIGhhdmUgdGhpcyBzdHVmZiB2ZXJ5IGNhcmVmdWxseQ0KZG9jdW1l bnRlZC4uLg0KDQo6IC0gRmlsbGluZyBjYWNoZSBpbmZvIGNvbXBsZXRlbHkgaW4gYXBwcm9wcmlh dGUgc3RydWN0dXJlcw0KOiBXaGVuIGRlYnVnZ2luZyBpdCdzIGFsbW9zdCBhbHdheXMgaXMgYSBU TEIgbWlzcy4gRWl0aGVyIHdoZW4gYWNjZXNzaW5nDQo6IGFuIGFkZHJlc3Mgd2hpY2ggaXMgc3Vw cG9zZWQgdG8gYmUgb2sgb3IgYSB3cm9uZyBwb2ludGVyLiBJJ20gaW52ZXN0aWdhdGluZy4NCg0K R29vZCBsdWNrLi4uDQoNCndhcm5lcg0K From owner-freebsd-mips@FreeBSD.ORG Mon Jun 7 11:06:59 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D098A1065670 for ; Mon, 7 Jun 2010 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A4DF18FC18 for ; Mon, 7 Jun 2010 11:06:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o57B6xa9008705 for ; Mon, 7 Jun 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o57B6xuq008703 for freebsd-mips@FreeBSD.org; Mon, 7 Jun 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Jun 2010 11:06:59 GMT Message-Id: <201006071106.o57B6xuq008703@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-mips@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-mips@FreeBSD.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 11:06:59 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o misc/147471 mips [includes] [patch] whitespace discrepancy in sys/mips/ 1 problem total. From owner-freebsd-mips@FreeBSD.ORG Mon Jun 7 17:09:37 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE6521065670 for ; Mon, 7 Jun 2010 17:09:37 +0000 (UTC) (envelope-from waynegong83@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 929ED8FC1E for ; Mon, 7 Jun 2010 17:09:37 +0000 (UTC) Received: by gwj20 with SMTP id 20so721187gwj.13 for ; Mon, 07 Jun 2010 10:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=oPYnJ7jRRymy3fdBM7J3jJIbxtOLHD90oT5or1Gj9xE=; b=xDHN83cmZ7MaYkPAQxh30/+R8zAKpzyNibvRpe4H0j+EM9NxfOpeCj73ue55n2Ggtn XOQra6cGk/rST6DS/yKPDWzu+lG9MgnuhpkvXZZ/5EavxtxiNAureLYfgUgezDavVLSZ d69D5MRoGyQJCa1So25WJbWmXSD+3ZXBSfOAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=i4ExEkdSQCeEVOkA6uES/dmkMKV8Kqh1uJFBs6n6Axkz8zy7kuRTZ3jsUKKrUwc4Uw 2p7PynpzJgt4UVaqBnhDFILm4sZmfIXJDzUVnOTjuXQG8ONRpMAmb3wHtShLHmOA1OCY 3KYKh32ZlJpsda9+78JL6Mfmk6WdhhBJem/IQ= MIME-Version: 1.0 Received: by 10.229.186.211 with SMTP id ct19mr2487546qcb.206.1275929156588; Mon, 07 Jun 2010 09:45:56 -0700 (PDT) Received: by 10.220.194.4 with HTTP; Mon, 7 Jun 2010 09:45:56 -0700 (PDT) Date: Mon, 7 Jun 2010 22:15:56 +0530 Message-ID: From: waynegong L To: freebsd-mips@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: build world breaks for n64 ABI X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:09:37 -0000 Hi All, Today I tried to build the toolchain/kernel for n64ABI with the toolchain patch submitted by julie on revision 208685 The tool chain and the kernel build were successful, but 'make buildworld' failed as below. cc1: warnings being treated as errors /usr/src/lib/libc/quad/fixunsdfdi.c: In function '__fixundfdi': /usr/src/lib/libc/quad/fixunsdfdi.c:72: warning: left shift count >= width of type /usr/src/lib/libc/quad/fixunsdfdi.c:72: warning: left shift count >= width of type A cursory look at the above file got me to the below line. Is this the reason for the above issue or some thing else? #define ONE_FOURTH (1 << (LONG_BITS -2)) Before doing the above, i had set my environment as below. setenv TARGET mips setenv TARGET_BIG_ENDIAN t setenv TARGET_CPUTYPE mips64 setenv TARGET_ABI n64 and then built the tool chain and kernel with OCTEON1 config file. Thanks, Wayne. From owner-freebsd-mips@FreeBSD.ORG Mon Jun 7 17:27:16 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86ED01065678; Mon, 7 Jun 2010 17:27:16 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 462A88FC1B; Mon, 7 Jun 2010 17:27:16 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id C998D2C2ACA; Mon, 7 Jun 2010 12:27:15 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HFo-V132Yu2v; Mon, 7 Jun 2010 12:27:08 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 2B36B2C2A63; Mon, 7 Jun 2010 12:27:07 -0500 (CDT) Message-ID: <4C0D2BEA.6060103@cs.rice.edu> Date: Mon, 07 Jun 2010 12:27:06 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100501) MIME-Version: 1.0 To: "C. Jayachandran" References: <201005271005.o4RA5eVu032269@svn.freebsd.org> <4C058145.3000707@cs.rice.edu> <4C05F9BC.40409@cs.rice.edu> <4C0731A5.7090301@cs.rice.edu> <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Jayachandran C." , Konstantin Belousov , Alan Cox , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:27:16 -0000 C. Jayachandran wrote: > On Fri, Jun 4, 2010 at 10:44 PM, Alan Cox wrote: > >> C. Jayachandran wrote: >> >>> On Thu, Jun 3, 2010 at 10:33 PM, Alan Cox wrote: >>> >>> >> [snip] >> >>>> Add a static counter to pmap_ptpgzone_allocf(). When the counter reaches >>>> some not-too-small prime number, don't call vm_phys_alloc_contig(), >>>> instead >>>> set "m" to NULL and reset the counter to zero. Setting "m" to NULL >>>> should >>>> then trigger the vm_contig_grow_cache() call. Make sense? >>>> >>>> >>> Is this to move the vm_contig_grow_cache() out of the >>> pmap_ptpgzone_allocf() and into the function calling uma_zalloc()? I >>> am wondering why the prime number is needed. >>> >>> Another implementation I had thought about was to have a kernel >>> process maintain a pool of direct mapped pages for MIPS. This will be >>> woken up if the pool goes below a low water mark - any comments on >>> this? >>> >>> >>> >> Here is how the page table page allocation should be done. It's not much >> harder than the vm_contig_grow_cache() change. >> >> 1. Look at vm/vm_phys.c, in particular, vm_phys_init(). Create a new >> freelist, like VM_FREELIST_ISADMA, for the direct-mapped memory on >> MIPS. Perhaps, call it VM_FREELIST_LOWMEM. The controlling macros should >> be defined in mips/include/vmparam.h. >> >> 2. Trivially refactor vm_phys_alloc_pages(). Specifically, take the body of >> the outer for loop and make it a new function, vm_phys_alloc_freelist(), >> that takes the variable "flind" as a parameter. >> >> 3. Eliminate the UMA zone for page table pages. In place of >> vm_phys_alloc_contig() call your new function with VM_FREELIST_LOWMEM. (The >> vm_contig_grow_cache() remains unchanged.) Go back to calling >> vm_page_free() to release page table pages. >> >> For the record, the changes that you made to start using a zone for page >> table page allocation introduced at least one possible race condition >> between pmap_remove_pages() and pmap_remove_all(). Specifically, by >> dropping and reacquiring the page queues and pmap lock when you free a page >> table page, you allow a pmap_remove_all() call while pmap_remove_pages() is >> running to leave the variable "npv" in pmap_remove_pages() pointing at a >> freed pv entry. >> > > My first attempt is attached, it comes up multiuser but crashes if I > stress it a bit (panic: Bad link elm 0xc0078f00 prev->next != elm). > Will look at this tomorrow, and see if I can find the cause. > > Where exactly is this occurring? > In the meantime, it may be worth looking at the patch to see if this > is in line with the approach you had suggested. I have tried to use > VM_FREELIST_HIGHMEM which is already there, instead of adding > VM_FREELIST_LOWMEM. > > Basically, yes. At first, I was taken aback by defining VM_FREELIST_DEFAULT as other than zero, but it shouldn't break anything. The one issue that I see with the patch is that you'll need to release and reacquire the pmap and page queues locks around the call to vm_contig_grow_cache(). However, if you release these locks, you need to restart the pmap_allocpte(), i.e., perform the "goto retry;", because while you slept another processor/thread might have already allocated and installed the page table page that you are trying to allocate into the page table. For what it's worth, this same race condition exists in the current code in subversion using an UMA zone, but not in the code that predates use of an UMA zone. Alan From owner-freebsd-mips@FreeBSD.ORG Mon Jun 7 18:17:49 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 193F1106567D; Mon, 7 Jun 2010 18:17:49 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id A69618FC1B; Mon, 7 Jun 2010 18:17:48 +0000 (UTC) Received: by gwj20 with SMTP id 20so806057gwj.13 for ; Mon, 07 Jun 2010 11:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JVqdRsA4Ne82HDGbhEmCRtKT9o0/FcRdaKS/rcqV/uU=; b=hWkyyRx4dD9R84AhZfL4dxW6V1HExRr7j7d76jdQiDDKvPqJVoUuEVTSrIeS3P0N33 RgA9O68vbLUnSpPqmxfCsgvK/lNXYhOXHJ7gnD5m+jZy7/Ph08jbYAUTKo2/xLMTzRvR OPkCH/Zt2gwdyaDRLSOTJ6GqCnswTs0xzz23k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dJ0Oe0SFQ0mteqhZmL/h3fiUe787L6BwEaUJjnFFVEpxZd4fAi8SI7nr+8cQgoLw0z +4FEjYLh9KiGW4mDUAkcSUs79tYYYSLU430IfVuaSmZIglOgmse1GV8hsgONs2cL3MOa zHjl35OUhQwPtcW4a8MYBqiTffbA5bQrZd1qY= MIME-Version: 1.0 Received: by 10.229.97.5 with SMTP id j5mr5009350qcn.133.1275934667335; Mon, 07 Jun 2010 11:17:47 -0700 (PDT) Received: by 10.220.189.13 with HTTP; Mon, 7 Jun 2010 11:17:47 -0700 (PDT) In-Reply-To: <4C0D2BEA.6060103@cs.rice.edu> References: <201005271005.o4RA5eVu032269@svn.freebsd.org> <4C058145.3000707@cs.rice.edu> <4C05F9BC.40409@cs.rice.edu> <4C0731A5.7090301@cs.rice.edu> <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> Date: Mon, 7 Jun 2010 23:47:47 +0530 Message-ID: From: "C. Jayachandran" To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Jayachandran C." , Konstantin Belousov , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 18:17:49 -0000 On Mon, Jun 7, 2010 at 10:57 PM, Alan Cox wrote: > C. Jayachandran wrote: >> >> On Fri, Jun 4, 2010 at 10:44 PM, Alan Cox wrote: >> >>> >>> C. Jayachandran wrote: >>> >>>> >>>> On Thu, Jun 3, 2010 at 10:33 PM, Alan Cox wrote: >>>> >>>> >>> >>> [snip] >>> >>>>> >>>>> Add a static counter to pmap_ptpgzone_allocf(). =A0When the counter >>>>> reaches >>>>> some not-too-small prime number, don't call vm_phys_alloc_contig(), >>>>> instead >>>>> set "m" to NULL and reset the counter to zero. =A0Setting "m" to NULL >>>>> should >>>>> then trigger the vm_contig_grow_cache() call. =A0Make sense? >>>>> >>>>> >>>> >>>> Is this to move the vm_contig_grow_cache() out of the >>>> pmap_ptpgzone_allocf() and into the function calling uma_zalloc()? =A0= I >>>> am wondering why the prime number is needed. >>>> >>>> Another implementation I had thought about was to have a kernel >>>> process maintain a pool of direct mapped pages for MIPS. This will be >>>> woken up if the pool goes below a low water mark - any comments on >>>> this? >>>> >>>> >>>> >>> >>> Here is how the page table page allocation should be done. =A0It's not = much >>> harder than the vm_contig_grow_cache() change. >>> >>> 1. Look at vm/vm_phys.c, in particular, vm_phys_init(). =A0Create a new >>> freelist, like =A0 =A0 =A0VM_FREELIST_ISADMA, for the direct-mapped mem= ory on >>> MIPS. =A0Perhaps, call it VM_FREELIST_LOWMEM. =A0The controlling macros >>> should >>> be defined in mips/include/vmparam.h. >>> >>> 2. Trivially refactor vm_phys_alloc_pages(). =A0Specifically, take the = body >>> of >>> the outer for loop and make it a new function, vm_phys_alloc_freelist()= , >>> =A0that takes the variable "flind" as a parameter. >>> >>> 3. Eliminate the UMA zone for page table pages. =A0In place of >>> vm_phys_alloc_contig() call your new function with VM_FREELIST_LOWMEM. >>> =A0(The >>> vm_contig_grow_cache() remains unchanged.) =A0Go back to calling >>> vm_page_free() to release page table pages. >>> >>> For the record, the changes that you made to start using a zone for pag= e >>> table page allocation introduced at least one possible race condition >>> between pmap_remove_pages() and pmap_remove_all(). =A0Specifically, by >>> dropping and reacquiring the page queues and pmap lock when you free a >>> page >>> table page, you allow a pmap_remove_all() call while pmap_remove_pages(= ) >>> is >>> running to leave the variable "npv" in pmap_remove_pages() pointing at = a >>> freed pv entry. >>> >> >> My first attempt is attached, it comes up multiuser but crashes if I >> stress it a bit (panic: Bad link elm 0xc0078f00 prev->next !=3D elm). >> Will look at this tomorrow, and see if I can find the cause. >> >> > > Where exactly is this occurring? > >> In the meantime, it may be worth looking at the patch to see if this >> is in line with the approach you had suggested. I have tried to =A0use >> VM_FREELIST_HIGHMEM which is already there, instead of adding >> VM_FREELIST_LOWMEM. >> >> > > Basically, yes. =A0At first, I was taken aback by defining VM_FREELIST_DE= FAULT > as other than zero, but it shouldn't break anything. I can change this to add VM_FREELIST_LOWMEM. This works okay so far, even though I haven't really checked the code to see if it works when there is no memory in HIGHMEM. > The one issue that I see with the patch is that you'll need to release an= d > reacquire the pmap and page queues locks around the call to > vm_contig_grow_cache(). =A0However, if you release these locks, you need = to > restart the pmap_allocpte(), i.e., perform the "goto retry;", because whi= le > you slept another processor/thread might have already allocated and > installed the page table page that you are trying to allocate into the pa= ge > table. > > For what it's worth, this same race condition exists in the current code = in > subversion using an UMA zone, but not in the code that predates use of an > UMA zone. I have been testing with an updated version of the patch - my -j128 buildworld works on this. The sys/vm side changes are simple enough, but the he page table page allocation part is still not complete. The version I have now is (with gmail whitespace damage): --- static vm_page_t pmap_alloc_pte_page(pmap_t pmap, unsigned int index, int wait, vm_offset_t = *vap) { =A0 =A0 =A0 =A0vm_paddr_t paddr; =A0 =A0 =A0 =A0vm_page_t m; =A0 =A0 =A0 =A0int tries, flags; =A0 =A0 =A0 =A0tries =3D 0; retry: =A0 =A0 =A0 =A0mtx_lock(&vm_page_queue_free_mtx); =A0 =A0 =A0 =A0m =3D vm_phys_alloc_freelist_pages(VM_FREELIST_DEFAULT, =A0 =A0 =A0 =A0 =A0 =A0VM_FREEPOOL_DEFAULT, 0); =A0 =A0 =A0 =A0if (m =3D=3D NULL) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mtx_unlock(&vm_page_queue_free_mtx); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (tries < ((wait & M_NOWAIT) !=3D 0 ? 1 : = 3)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_contig_grow_cache(tries, = 0, MIPS_KSEG0_LARGEST_PHYS); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tries++; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto retry; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("[%d] %s wait %x, fai= l!\n", tries, __func__, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wait); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (NULL); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0m->pindex =3D index; =A0 =A0 =A0 =A0m->valid =3D VM_PAGE_BITS_ALL; =A0 =A0 =A0 =A0atomic_add_int(&cnt.v_wire_count, 1); =A0 =A0 =A0 =A0m->wire_count =3D 1; =A0 =A0 =A0 =A0if (m->flags & PG_ZERO) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vm_page_zero_count--; =A0 =A0 =A0 =A0else =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pmap_zero_page(m); =A0 =A0 =A0 =A0flags =3D PG_ZERO | PG_UNMANAGED; =A0 =A0 =A0 =A0m->flags =3D flags; =A0 =A0 =A0 =A0m->oflags =3D 0; =A0 =A0 =A0 =A0m->act_count =3D 0; =A0 =A0 =A0 =A0if ((m->flags & PG_CACHED) !=3D 0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("Not yet! handle cached =A0page %p fl= ags 0x%x\n", m, m->flags); =A0 =A0 =A0 =A0else =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cnt.v_free_count--; =A0 =A0 =A0 =A0m->act_count =3D 0; =A0 =A0 =A0 =A0mtx_unlock(&vm_page_queue_free_mtx); } ---- I tried to match the vm_page_alloc() code here. I'm not sure if I have to handle the PG_CACHED case, and if it is okay to change the VM counters here. Also, I will change the code to return NULL all the way and retry allocation (similar to the old code which called VM_WAIT and then returned NULL). Probably I should get the whole code in line with the old code, replacing the old vm_page_alloc() call with the function above without retry, and the VM_WAIT with a new function which does the vm_contig_grow_cache(). Thanks, JC. From owner-freebsd-mips@FreeBSD.ORG Mon Jun 7 18:49:47 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19B471065679; Mon, 7 Jun 2010 18:49:47 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id CCD678FC16; Mon, 7 Jun 2010 18:49:46 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 578C22C2ACA; Mon, 7 Jun 2010 13:49:46 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JpwGxz+w3Agl; Mon, 7 Jun 2010 13:49:38 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 9D0662C2A02; Mon, 7 Jun 2010 13:49:37 -0500 (CDT) Message-ID: <4C0D3F40.2070101@cs.rice.edu> Date: Mon, 07 Jun 2010 13:49:36 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100501) MIME-Version: 1.0 To: "C. Jayachandran" References: <201005271005.o4RA5eVu032269@svn.freebsd.org> <4C058145.3000707@cs.rice.edu> <4C05F9BC.40409@cs.rice.edu> <4C0731A5.7090301@cs.rice.edu> <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Jayachandran C." , Konstantin Belousov , Alan Cox , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 18:49:47 -0000 C. Jayachandran wrote: > On Mon, Jun 7, 2010 at 10:57 PM, Alan Cox wrote: > >> C. Jayachandran wrote: >> >>> On Fri, Jun 4, 2010 at 10:44 PM, Alan Cox wrote: >>> >>> >>>> C. Jayachandran wrote: >>>> >>>> >>>>> On Thu, Jun 3, 2010 at 10:33 PM, Alan Cox wrote: >>>>> >>>>> >>>>> >>>> [snip] >>>> >>>> >>>>>> Add a static counter to pmap_ptpgzone_allocf(). When the counter >>>>>> reaches >>>>>> some not-too-small prime number, don't call vm_phys_alloc_contig(), >>>>>> instead >>>>>> set "m" to NULL and reset the counter to zero. Setting "m" to NULL >>>>>> should >>>>>> then trigger the vm_contig_grow_cache() call. Make sense? >>>>>> >>>>>> >>>>>> >>>>> Is this to move the vm_contig_grow_cache() out of the >>>>> pmap_ptpgzone_allocf() and into the function calling uma_zalloc()? I >>>>> am wondering why the prime number is needed. >>>>> >>>>> Another implementation I had thought about was to have a kernel >>>>> process maintain a pool of direct mapped pages for MIPS. This will be >>>>> woken up if the pool goes below a low water mark - any comments on >>>>> this? >>>>> >>>>> >>>>> >>>>> >>>> Here is how the page table page allocation should be done. It's not much >>>> harder than the vm_contig_grow_cache() change. >>>> >>>> 1. Look at vm/vm_phys.c, in particular, vm_phys_init(). Create a new >>>> freelist, like VM_FREELIST_ISADMA, for the direct-mapped memory on >>>> MIPS. Perhaps, call it VM_FREELIST_LOWMEM. The controlling macros >>>> should >>>> be defined in mips/include/vmparam.h. >>>> >>>> 2. Trivially refactor vm_phys_alloc_pages(). Specifically, take the body >>>> of >>>> the outer for loop and make it a new function, vm_phys_alloc_freelist(), >>>> that takes the variable "flind" as a parameter. >>>> >>>> 3. Eliminate the UMA zone for page table pages. In place of >>>> vm_phys_alloc_contig() call your new function with VM_FREELIST_LOWMEM. >>>> (The >>>> vm_contig_grow_cache() remains unchanged.) Go back to calling >>>> vm_page_free() to release page table pages. >>>> >>>> For the record, the changes that you made to start using a zone for page >>>> table page allocation introduced at least one possible race condition >>>> between pmap_remove_pages() and pmap_remove_all(). Specifically, by >>>> dropping and reacquiring the page queues and pmap lock when you free a >>>> page >>>> table page, you allow a pmap_remove_all() call while pmap_remove_pages() >>>> is >>>> running to leave the variable "npv" in pmap_remove_pages() pointing at a >>>> freed pv entry. >>>> >>>> >>> My first attempt is attached, it comes up multiuser but crashes if I >>> stress it a bit (panic: Bad link elm 0xc0078f00 prev->next != elm). >>> Will look at this tomorrow, and see if I can find the cause. >>> >>> >>> >> Where exactly is this occurring? >> >> >>> In the meantime, it may be worth looking at the patch to see if this >>> is in line with the approach you had suggested. I have tried to use >>> VM_FREELIST_HIGHMEM which is already there, instead of adding >>> VM_FREELIST_LOWMEM. >>> >>> >>> >> Basically, yes. At first, I was taken aback by defining VM_FREELIST_DEFAULT >> as other than zero, but it shouldn't break anything. >> > > I can change this to add VM_FREELIST_LOWMEM. This works okay so far, > even though I haven't really checked the code to see if it works when > there is no memory in HIGHMEM. > > I think that it will. It will just waste a little time looking at empty queues. >> The one issue that I see with the patch is that you'll need to release and >> reacquire the pmap and page queues locks around the call to >> vm_contig_grow_cache(). However, if you release these locks, you need to >> restart the pmap_allocpte(), i.e., perform the "goto retry;", because while >> you slept another processor/thread might have already allocated and >> installed the page table page that you are trying to allocate into the page >> table. >> >> For what it's worth, this same race condition exists in the current code in >> subversion using an UMA zone, but not in the code that predates use of an >> UMA zone. >> > > I have been testing with an updated version of the patch - my -j128 > buildworld works on this. The sys/vm side changes are simple enough, > but the he page table page allocation part is still not complete. The > version I have now is (with gmail whitespace damage): > > --- > static vm_page_t > pmap_alloc_pte_page(pmap_t pmap, unsigned int index, int wait, vm_offset_t *vap) > { > vm_paddr_t paddr; > vm_page_t m; > int tries, flags; > > tries = 0; > retry: > mtx_lock(&vm_page_queue_free_mtx); > m = vm_phys_alloc_freelist_pages(VM_FREELIST_DEFAULT, > VM_FREEPOOL_DEFAULT, 0); > if (m == NULL) { > mtx_unlock(&vm_page_queue_free_mtx); > if (tries < ((wait & M_NOWAIT) != 0 ? 1 : 3)) { > vm_contig_grow_cache(tries, 0, MIPS_KSEG0_LARGEST_PHYS); > tries++; > goto retry; > } else { > printf("[%d] %s wait %x, fail!\n", tries, __func__, > wait); > return (NULL); > } > } > > m->pindex = index; > m->valid = VM_PAGE_BITS_ALL; > atomic_add_int(&cnt.v_wire_count, 1); > m->wire_count = 1; > if (m->flags & PG_ZERO) > vm_page_zero_count--; > else > pmap_zero_page(m); > flags = PG_ZERO | PG_UNMANAGED; > m->flags = flags; > m->oflags = 0; > m->act_count = 0; > if ((m->flags & PG_CACHED) != 0) > printf("Not yet! handle cached page %p flags 0x%x\n", > m, m->flags); > else > cnt.v_free_count--; > > m->act_count = 0; > mtx_unlock(&vm_page_queue_free_mtx); > } > > > ---- > > I tried to match the vm_page_alloc() code here. I'm not sure if I have > to handle the PG_CACHED case, and if it is okay to change the VM > counters here. > > You do. In the end, I suspect that this function will be added to the machine-independent layer. > Also, I will change the code to return NULL all the way and retry > allocation (similar to the old code which called VM_WAIT and then > returned NULL). > > Probably I should get the whole code in line with the old code, > replacing the old vm_page_alloc() call with the function above without > retry, and the VM_WAIT with a new function which does the > vm_contig_grow_cache(). > > You may find it easier if you move the call to vm_contig_grow_cache() to pmap_allocpte(). Alan From owner-freebsd-mips@FreeBSD.ORG Mon Jun 7 18:56:21 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE9DB1065670; Mon, 7 Jun 2010 18:56:21 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 7B0F88FC19; Mon, 7 Jun 2010 18:56:21 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 3E24C2C2BF0; Mon, 7 Jun 2010 13:56:21 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lboFigkrZe-z; Mon, 7 Jun 2010 13:56:13 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 1113C2C2A02; Mon, 7 Jun 2010 13:56:13 -0500 (CDT) Message-ID: <4C0D40CC.5090408@cs.rice.edu> Date: Mon, 07 Jun 2010 13:56:12 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100501) MIME-Version: 1.0 To: "C. Jayachandran" References: <201005271005.o4RA5eVu032269@svn.freebsd.org> <4C058145.3000707@cs.rice.edu> <4C05F9BC.40409@cs.rice.edu> <4C0731A5.7090301@cs.rice.edu> <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Jayachandran C." , Konstantin Belousov , Alan Cox , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 18:56:21 -0000 C. Jayachandran wrote: [snip] > I tried to match the vm_page_alloc() code here. I'm not sure if I have > to handle the PG_CACHED case, and if it is okay to change the VM > counters here. > > Sorry, I overlooked one of your questions before. Yes, accesses to those counters are synchronized by the free queues lock. From owner-freebsd-mips@FreeBSD.ORG Mon Jun 7 19:20:42 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 987D3106568D for ; Mon, 7 Jun 2010 19:20:42 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5F4158FC12 for ; Mon, 7 Jun 2010 19:20:42 +0000 (UTC) Received: by gyh20 with SMTP id 20so3379014gyh.13 for ; Mon, 07 Jun 2010 12:20:41 -0700 (PDT) Received: by 10.229.28.74 with SMTP id l10mr5291932qcc.142.1275938441523; Mon, 07 Jun 2010 12:20:41 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.220.180.9 with HTTP; Mon, 7 Jun 2010 12:20:21 -0700 (PDT) In-Reply-To: References: From: Juli Mallett Date: Mon, 7 Jun 2010 12:20:21 -0700 X-Google-Sender-Auth: lOPDnOdXgkM63-euNzMsVtwCYAc Message-ID: To: waynegong L Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: build world breaks for n64 ABI X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 19:20:42 -0000 Hi Wayne, On Mon, Jun 7, 2010 at 09:45, waynegong L wrote: > Hi All, > > Today I tried to build the toolchain/kernel for n64ABI with the toolchain > patch submitted by julie on revision 208685 > The tool chain and the kernel build were successful, but 'make buildworld' > failed as below. Alas, the only changes I have merged so far are toolchain support bits. There are also non-trivial libc and kernel changes that are necessary. You can try my branch, which is /user/jmallett/octeon in Subversion, or extract patches from it if you like. I'll try to get the rest of the ABI support patches committed to -CURRENT in the near future. Thanks, Juli. From owner-freebsd-mips@FreeBSD.ORG Mon Jun 7 20:46:36 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E16E4106570A for ; Mon, 7 Jun 2010 20:46:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 47C198FC14 for ; Mon, 7 Jun 2010 20:46:35 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o57KSwgI095528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2010 23:28:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o57KSiEH084484; Mon, 7 Jun 2010 23:28:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o57KSiet084483; Mon, 7 Jun 2010 23:28:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 7 Jun 2010 23:28:44 +0300 From: Kostik Belousov To: Alan Cox Message-ID: <20100607202844.GU83316@deviant.kiev.zoral.com.ua> References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eM1qf7WYQBf+P1UJ" Content-Disposition: inline In-Reply-To: <4C0D3F40.2070101@cs.rice.edu> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "Jayachandran C." , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 20:46:37 -0000 --eM1qf7WYQBf+P1UJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 07, 2010 at 01:49:36PM -0500, Alan Cox wrote: > C. Jayachandran wrote: > >On Mon, Jun 7, 2010 at 10:57 PM, Alan Cox wrote: > > =20 > >>C. Jayachandran wrote: > >> =20 > >>>On Fri, Jun 4, 2010 at 10:44 PM, Alan Cox wrote: > >>> > >>> =20 > >>>>C. Jayachandran wrote: > >>>> > >>>> =20 > >>>>>On Thu, Jun 3, 2010 at 10:33 PM, Alan Cox wrote: > >>>>> > >>>>> > >>>>> =20 > >>>>[snip] > >>>> > >>>> =20 > >>>>>>Add a static counter to pmap_ptpgzone_allocf(). When the counter > >>>>>>reaches > >>>>>>some not-too-small prime number, don't call vm_phys_alloc_contig(), > >>>>>>instead > >>>>>>set "m" to NULL and reset the counter to zero. Setting "m" to NULL > >>>>>>should > >>>>>>then trigger the vm_contig_grow_cache() call. Make sense? > >>>>>> > >>>>>> > >>>>>> =20 > >>>>>Is this to move the vm_contig_grow_cache() out of the > >>>>>pmap_ptpgzone_allocf() and into the function calling uma_zalloc()? I > >>>>>am wondering why the prime number is needed. > >>>>> > >>>>>Another implementation I had thought about was to have a kernel > >>>>>process maintain a pool of direct mapped pages for MIPS. This will be > >>>>>woken up if the pool goes below a low water mark - any comments on > >>>>>this? > >>>>> > >>>>> > >>>>> > >>>>> =20 > >>>>Here is how the page table page allocation should be done. It's not= =20 > >>>>much > >>>>harder than the vm_contig_grow_cache() change. > >>>> > >>>>1. Look at vm/vm_phys.c, in particular, vm_phys_init(). Create a new > >>>>freelist, like VM_FREELIST_ISADMA, for the direct-mapped memory = on > >>>>MIPS. Perhaps, call it VM_FREELIST_LOWMEM. The controlling macros > >>>>should > >>>>be defined in mips/include/vmparam.h. > >>>> > >>>>2. Trivially refactor vm_phys_alloc_pages(). Specifically, take the= =20 > >>>>body > >>>>of > >>>>the outer for loop and make it a new function, vm_phys_alloc_freelist= (), > >>>> that takes the variable "flind" as a parameter. > >>>> > >>>>3. Eliminate the UMA zone for page table pages. In place of > >>>>vm_phys_alloc_contig() call your new function with VM_FREELIST_LOWMEM. > >>>> (The > >>>>vm_contig_grow_cache() remains unchanged.) Go back to calling > >>>>vm_page_free() to release page table pages. > >>>> > >>>>For the record, the changes that you made to start using a zone for p= age > >>>>table page allocation introduced at least one possible race condition > >>>>between pmap_remove_pages() and pmap_remove_all(). Specifically, by > >>>>dropping and reacquiring the page queues and pmap lock when you free a > >>>>page > >>>>table page, you allow a pmap_remove_all() call while pmap_remove_page= s() > >>>>is > >>>>running to leave the variable "npv" in pmap_remove_pages() pointing a= t a > >>>>freed pv entry. > >>>> > >>>> =20 > >>>My first attempt is attached, it comes up multiuser but crashes if I > >>>stress it a bit (panic: Bad link elm 0xc0078f00 prev->next !=3D elm). > >>>Will look at this tomorrow, and see if I can find the cause. > >>> > >>> > >>> =20 > >>Where exactly is this occurring? > >> > >> =20 > >>>In the meantime, it may be worth looking at the patch to see if this > >>>is in line with the approach you had suggested. I have tried to use > >>>VM_FREELIST_HIGHMEM which is already there, instead of adding > >>>VM_FREELIST_LOWMEM. > >>> > >>> > >>> =20 > >>Basically, yes. At first, I was taken aback by defining=20 > >>VM_FREELIST_DEFAULT > >>as other than zero, but it shouldn't break anything. > >> =20 > > > >I can change this to add VM_FREELIST_LOWMEM. This works okay so far, > >even though I haven't really checked the code to see if it works when > >there is no memory in HIGHMEM. > > > > =20 >=20 > I think that it will. It will just waste a little time looking at empty= =20 > queues. >=20 > >>The one issue that I see with the patch is that you'll need to release = and > >>reacquire the pmap and page queues locks around the call to > >>vm_contig_grow_cache(). However, if you release these locks, you need = to > >>restart the pmap_allocpte(), i.e., perform the "goto retry;", because= =20 > >>while > >>you slept another processor/thread might have already allocated and > >>installed the page table page that you are trying to allocate into the= =20 > >>page > >>table. > >> > >>For what it's worth, this same race condition exists in the current cod= e=20 > >>in > >>subversion using an UMA zone, but not in the code that predates use of = an > >>UMA zone. > >> =20 > > > >I have been testing with an updated version of the patch - my -j128 > >buildworld works on this. The sys/vm side changes are simple enough, > >but the he page table page allocation part is still not complete. The > >version I have now is (with gmail whitespace damage): > > > >--- > >static vm_page_t > >pmap_alloc_pte_page(pmap_t pmap, unsigned int index, int wait, vm_offset= _t=20 > >*vap) > >{ > > vm_paddr_t paddr; > > vm_page_t m; > > int tries, flags; > > > > tries =3D 0; > >retry: > > mtx_lock(&vm_page_queue_free_mtx); > > m =3D vm_phys_alloc_freelist_pages(VM_FREELIST_DEFAULT, > > VM_FREEPOOL_DEFAULT, 0); > > if (m =3D=3D NULL) { > > mtx_unlock(&vm_page_queue_free_mtx); > > if (tries < ((wait & M_NOWAIT) !=3D 0 ? 1 : 3)) { > > vm_contig_grow_cache(tries, 0,=20 > > MIPS_KSEG0_LARGEST_PHYS); > > tries++; > > goto retry; > > } else { > > printf("[%d] %s wait %x, fail!\n", tries, __func_= _, > > wait); > > return (NULL); > > } > > } > > > > m->pindex =3D index; > > m->valid =3D VM_PAGE_BITS_ALL; > > atomic_add_int(&cnt.v_wire_count, 1); > > m->wire_count =3D 1; > > if (m->flags & PG_ZERO) > > vm_page_zero_count--; > > else > > pmap_zero_page(m); > > flags =3D PG_ZERO | PG_UNMANAGED; > > m->flags =3D flags; > > m->oflags =3D 0; > > m->act_count =3D 0; > > if ((m->flags & PG_CACHED) !=3D 0) > > printf("Not yet! handle cached page %p flags 0x%x\n", > >m, m->flags); > > else > > cnt.v_free_count--; > > > > m->act_count =3D 0; > > mtx_unlock(&vm_page_queue_free_mtx); > >} > > > > > >---- > > > >I tried to match the vm_page_alloc() code here. I'm not sure if I have > >to handle the PG_CACHED case, and if it is okay to change the VM > >counters here. > > > > =20 >=20 > You do. In the end, I suspect that this function will be added to the=20 > machine-independent layer. >=20 > >Also, I will change the code to return NULL all the way and retry > >allocation (similar to the old code which called VM_WAIT and then > >returned NULL). > > > >Probably I should get the whole code in line with the old code, > >replacing the old vm_page_alloc() call with the function above without > >retry, and the VM_WAIT with a new function which does the > >vm_contig_grow_cache(). > > > > =20 >=20 > You may find it easier if you move the call to vm_contig_grow_cache() to= =20 > pmap_allocpte(). Selecting a random message in the thread to ask my question. Is the issue that page table pages should be allocated from the specific physical region of the memory ? If yes, doesn't i386 PAE has similar issue with page directory pointer table ? I see a KASSERT in i386 pmap that verifies that the allocated table is below 4G, but I do not understand how uma ensures the constraint (I suspect that it does not). --eM1qf7WYQBf+P1UJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwNVnsACgkQC3+MBN1Mb4gM3QCdHNkTwnwGd8Yb3M3XdZDpUtHb ACgAn0DBpuImieTVCYtqMtGuZO0HWiha =Ji95 -----END PGP SIGNATURE----- --eM1qf7WYQBf+P1UJ-- From owner-freebsd-mips@FreeBSD.ORG Mon Jun 7 21:29:55 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E50AF106564A; Mon, 7 Jun 2010 21:29:55 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id B5E7B8FC13; Mon, 7 Jun 2010 21:29:55 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 20DFB2C2A92; Mon, 7 Jun 2010 16:29:55 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HYr-fJbuLscl; Mon, 7 Jun 2010 16:29:47 -0500 (CDT) Received: from [10.209.194.87] (unknown [10.209.194.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 67A612C2A63; Mon, 7 Jun 2010 16:29:47 -0500 (CDT) Message-ID: <4C0D64B7.7060604@cs.rice.edu> Date: Mon, 07 Jun 2010 16:29:27 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Kostik Belousov References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> In-Reply-To: <20100607202844.GU83316@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Jayachandran C." , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 21:29:56 -0000 On 6/7/2010 3:28 PM, Kostik Belousov wrote: > Selecting a random message in the thread to ask my question. > Is the issue that page table pages should be allocated from the specific > physical region of the memory ? If yes, doesn't i386 PAE has similar > issue with page directory pointer table ? I see a KASSERT in i386 > pmap that verifies that the allocated table is below 4G, but I do not > understand how uma ensures the constraint (I suspect that it does not). > For i386 PAE, the UMA backend allocator uses kmem_alloc_contig() to ensure that the memory is below 4G. The crucial difference between i386 PAE and MIPS is that for i386 PAE only the top-level table needs to be below a specific address threshold. Moreover, this level is allocated in a place, pmap_pinit(), where we are allowed to sleep. Alan From owner-freebsd-mips@FreeBSD.ORG Tue Jun 8 04:07:30 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C694B1065676; Tue, 8 Jun 2010 04:07:30 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 56AFF8FC08; Tue, 8 Jun 2010 04:07:30 +0000 (UTC) Received: by vws4 with SMTP id 4so3052837vws.13 for ; Mon, 07 Jun 2010 21:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=o012yGSwoqZdSldTKjmi3vo06v9wTC8YW22yZmdJX/U=; b=czE985MbNSVXZ5WtP3XxBr3crx+Rg8zGNn+Qk7cr6xngE3CBFAfwaN7SVfbwGXuZAu /snM4DqliUIbjDW1dYGQvB0ylM7FvF+E7ma1qJFnjP34TMc/PWx8FyCuKP8TzxUaEvCm pB0fO2kTxxVFA8zDBWolTUSPjhe2X91hWexaw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=o1uti1jNuLKgz4/Qtcyq9l1lOUnbpYouwfL7xPo+RdZw4f7OubWVthdp9GqMScrOCi yxQvr3RRi6NF9ttA9plSdWmrw8kS1JDHTo1uohoZqd7h/9GWN2YIBScfF6z+SZ/3SQjI SdJXyKm+UOqBBdvF78C2Ge3X4F+vLfcMkgBl8= MIME-Version: 1.0 Received: by 10.224.87.169 with SMTP id w41mr9572124qal.292.1275970049603; Mon, 07 Jun 2010 21:07:29 -0700 (PDT) Received: by 10.220.189.13 with HTTP; Mon, 7 Jun 2010 21:07:29 -0700 (PDT) In-Reply-To: <4C0D64B7.7060604@cs.rice.edu> References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> Date: Tue, 8 Jun 2010 09:37:29 +0530 Message-ID: From: "C. Jayachandran" To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , "Jayachandran C." , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 04:07:30 -0000 On Tue, Jun 8, 2010 at 2:59 AM, Alan Cox wrote: > On 6/7/2010 3:28 PM, Kostik Belousov wrote: >> >> Selecting a random message in the thread to ask my question. >> Is the issue that page table pages should be allocated from the specific >> physical region of the memory ? If yes, doesn't i386 PAE has similar >> issue with page directory pointer table ? I see a KASSERT in i386 >> pmap that verifies that the allocated table is below 4G, but I do not >> understand how uma ensures the constraint (I suspect that it does not). >> > > For i386 PAE, the UMA backend allocator uses kmem_alloc_contig() to ensur= e > that the memory is below 4G. =A0The crucial difference between i386 PAE a= nd > MIPS is that for i386 PAE only the top-level table needs to be below a > specific address threshold. =A0Moreover, this level is allocated in a pla= ce, > pmap_pinit(), where we are allowed to sleep. Yes. I saw the PAE top level page table code and thought I could use that mechanism for allocating MIPS page table pages in the direct mapped memory. The other reference I used was pmap_alloc_zeroed_contig_pages() function in sun4v/sun4v/pmap.c which uses the vm_phys_alloc_contig() and VM_WAIT. I had also thought of using the VM_FREEPOOL_DIRECT which seemed to be for a similar purpose, but could find see any usage in the kernel. JC. From owner-freebsd-mips@FreeBSD.ORG Tue Jun 8 04:14:03 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2974C106564A for ; Tue, 8 Jun 2010 04:14:03 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 01EA98FC16 for ; Tue, 8 Jun 2010 04:14:02 +0000 (UTC) Received: by pwj1 with SMTP id 1so2257032pwj.13 for ; Mon, 07 Jun 2010 21:14:02 -0700 (PDT) Received: by 10.114.165.18 with SMTP id n18mr12429011wae.3.1275970442259; Mon, 07 Jun 2010 21:14:02 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.114.241.2 with HTTP; Mon, 7 Jun 2010 21:13:42 -0700 (PDT) In-Reply-To: References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> From: Juli Mallett Date: Mon, 7 Jun 2010 21:13:42 -0700 X-Google-Sender-Auth: BEFZU6i7mf27n3bQxP8LG9zig28 Message-ID: To: "C. Jayachandran" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 04:14:03 -0000 Hey JC, On Mon, Jun 7, 2010 at 21:07, C. Jayachandran wr= ote: > Yes. I saw the PAE top level page table code and thought I could use > that mechanism for allocating MIPS page table pages in the direct > mapped memory. The other reference I used was > pmap_alloc_zeroed_contig_pages() function in sun4v/sun4v/pmap.c which > uses the vm_phys_alloc_contig() and VM_WAIT. =A0I had also thought of > using the VM_FREEPOOL_DIRECT which seemed to be for a similar purpose, > but could find see any usage in the kernel. Do you intend to support o32 kernels in your port indefinitely? I wonder whether this work is just stopgap until the systems which have large amounts of RAM can just use n64 kernels. At least on Octeon it seems to me that n64-only is the right answer if at all possible, since there are really a lot of parts of the kernel that just can't reasonably work otherwise (use of rman_get_virtual with io ports, for instance.) Thanks, Juli. From owner-freebsd-mips@FreeBSD.ORG Tue Jun 8 06:13:55 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4794F106566C; Tue, 8 Jun 2010 06:13:55 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D0CDD8FC08; Tue, 8 Jun 2010 06:13:54 +0000 (UTC) Received: by vws4 with SMTP id 4so3215745vws.13 for ; Mon, 07 Jun 2010 23:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=okgM1HjDBHjO/A/xm+Wz9eyCrejOr8muCUP6OhZoHYw=; b=SnA8Fd24FkBbKXMO+Rmh4Qtdq11U5UWMeHF/ssG46k4n+KvvRcVz4x9zxzmdbNmZON VElevgsHM0eRJ+61kTc1UYbvPRdo5qbwKW0JAj4BaZRmgh5SIOgeTn98kN3NPPTWQL5X t1WFhx0ZHm0C5/46Pi6kQ/wtDHtiGMAmd+xVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rVpQWPW3Ceeiv/yzwYCfZfNX21WECjcJUfTFo+Yd/MyjpMZMp5Hitzjb3UkvdD9j4a dG+g3rGlSk2W1PfifpvrymZcWP5NyI1IGhCkAUZu0qacpX3HR0O9SDYP+b27BnNIubxh +GhIRgmkxRI/bYtO/TssLFXZ1zF3NPRcPS+bQ= MIME-Version: 1.0 Received: by 10.224.96.89 with SMTP id g25mr9356690qan.42.1275977633247; Mon, 07 Jun 2010 23:13:53 -0700 (PDT) Received: by 10.220.189.13 with HTTP; Mon, 7 Jun 2010 23:13:53 -0700 (PDT) In-Reply-To: References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> Date: Tue, 8 Jun 2010 11:43:53 +0530 Message-ID: From: "C. Jayachandran" To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 06:13:55 -0000 On Tue, Jun 8, 2010 at 9:43 AM, Juli Mallett wrote: > Hey JC, > > On Mon, Jun 7, 2010 at 21:07, C. Jayachandran = wrote: >> Yes. I saw the PAE top level page table code and thought I could use >> that mechanism for allocating MIPS page table pages in the direct >> mapped memory. The other reference I used was >> pmap_alloc_zeroed_contig_pages() function in sun4v/sun4v/pmap.c which >> uses the vm_phys_alloc_contig() and VM_WAIT. =A0I had also thought of >> using the VM_FREEPOOL_DIRECT which seemed to be for a similar purpose, >> but could find see any usage in the kernel. > > Do you intend to support o32 kernels in your port indefinitely? =A0I > wonder whether this work is just stopgap until the systems which have > large amounts of RAM can just use n64 kernels. I think the page table work will be needed for o32 and n32, and I would like to support one of them as the preferred 32bit mode for our port. BTW, n32 with >4GB RAM can be supported with XKPHYS for page table entries. The options there would be either special allocator for the segtab (11+9+12 addr space split), or to use special allocator for all the page table pages (10+10+12 split). >=A0At least on Octeon it > seems to me that n64-only is the right answer if at all possible, > since there are really a lot of parts of the kernel that just can't > reasonably work otherwise (use of rman_get_virtual with io ports, for > instance.) Not sure I understand this part - I thought pmap_mapdev() would handle these - but I may be mistaken. JC. From owner-freebsd-mips@FreeBSD.ORG Tue Jun 8 06:27:11 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6422C1065672 for ; Tue, 8 Jun 2010 06:27:11 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-pz0-f183.google.com (mail-pz0-f183.google.com [209.85.222.183]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB198FC13 for ; Tue, 8 Jun 2010 06:27:11 +0000 (UTC) Received: by pzk13 with SMTP id 13so125296pzk.13 for ; Mon, 07 Jun 2010 23:27:10 -0700 (PDT) Received: by 10.115.67.11 with SMTP id u11mr12391393wak.196.1275978429460; Mon, 07 Jun 2010 23:27:09 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.114.241.2 with HTTP; Mon, 7 Jun 2010 23:26:49 -0700 (PDT) In-Reply-To: References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> From: Juli Mallett Date: Mon, 7 Jun 2010 23:26:49 -0700 X-Google-Sender-Auth: 6pDhNxRUj1yqPWlFlFNvBJkE49Q Message-ID: To: "C. Jayachandran" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 06:27:11 -0000 On Mon, Jun 7, 2010 at 23:13, C. Jayachandran wr= ote: > On Tue, Jun 8, 2010 at 9:43 AM, Juli Mallett wrote= : >> Do you intend to support o32 kernels in your port indefinitely? =A0I >> wonder whether this work is just stopgap until the systems which have >> large amounts of RAM can just use n64 kernels. > > I think the page table work will be needed for o32 and n32, and I > would like to support one of them as the preferred 32bit mode for our > port. OK. > BTW, n32 with >4GB RAM can be supported with XKPHYS for page table > entries. The options there would be either special allocator for the > segtab (11+9+12 addr space split), or to use special allocator for all > the page table pages (10+10+12 split). Yeah, but we have a disinterest in supporting n32 kernels in base because it breaks assumptions in so many parts of the kernel, so I think the most reasonable expectation for base is to support o32 and n64, and to strongly prefer n64 for systems where it's more appropriate. >>=A0At least on Octeon it >> seems to me that n64-only is the right answer if at all possible, >> since there are really a lot of parts of the kernel that just can't >> reasonably work otherwise (use of rman_get_virtual with io ports, for >> instance.) > > Not sure I understand this part - I thought pmap_mapdev() would handle > these - but I may be mistaken. There's nothing pmap_mapdev can do on an o32 kernel with 32-bit PTEs for a physical address >2^36. (There are rather a lot of those on Octeon.) Juli. From owner-freebsd-mips@FreeBSD.ORG Tue Jun 8 06:33:18 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F72C106567A; Tue, 8 Jun 2010 06:33:18 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 301BC8FC22; Tue, 8 Jun 2010 06:33:17 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 83BAA2C2D0A; Tue, 8 Jun 2010 01:33:17 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XMHGj+ApzUmh; Tue, 8 Jun 2010 01:33:09 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 269672C2A92; Tue, 8 Jun 2010 01:33:09 -0500 (CDT) Message-ID: <4C0DE424.9080601@cs.rice.edu> Date: Tue, 08 Jun 2010 01:33:08 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100501) MIME-Version: 1.0 To: "C. Jayachandran" References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , "Jayachandran C." , Alan Cox , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 06:33:18 -0000 C. Jayachandran wrote: > On Tue, Jun 8, 2010 at 2:59 AM, Alan Cox wrote: > >> On 6/7/2010 3:28 PM, Kostik Belousov wrote: >> >>> Selecting a random message in the thread to ask my question. >>> Is the issue that page table pages should be allocated from the specific >>> physical region of the memory ? If yes, doesn't i386 PAE has similar >>> issue with page directory pointer table ? I see a KASSERT in i386 >>> pmap that verifies that the allocated table is below 4G, but I do not >>> understand how uma ensures the constraint (I suspect that it does not). >>> >>> >> For i386 PAE, the UMA backend allocator uses kmem_alloc_contig() to ensure >> that the memory is below 4G. The crucial difference between i386 PAE and >> MIPS is that for i386 PAE only the top-level table needs to be below a >> specific address threshold. Moreover, this level is allocated in a place, >> pmap_pinit(), where we are allowed to sleep. >> > > Yes. I saw the PAE top level page table code and thought I could use > that mechanism for allocating MIPS page table pages in the direct > mapped memory. The other reference I used was > pmap_alloc_zeroed_contig_pages() function in sun4v/sun4v/pmap.c which > uses the vm_phys_alloc_contig() and VM_WAIT. That's unfortunate. :-( Since sun4v is essentially dead code, I've never spent much time thinking about its pmap implementation. I'll mechanically apply changes to it, but that's about it. I wouldn't recommend using it as a reference. > ... I had also thought of > using the VM_FREEPOOL_DIRECT which seemed to be for a similar purpose, > but could find see any usage in the kernel. > > VM_FREEPOOL_DIRECT is used by at least amd64 and ia64 for page table pages and small kernel memory allocations. Unlike mips, these machines don't have MMU support for a direct map. Their direct maps are just a range of mappings in the regular (kernel) page table. So, unlike mips, accesses through their direct map may still miss in the TLB and require a page table walk. VM_FREEPOOL_* is a way to increase the physical locality (or clustering) of page allocations, so that, for example, page table page accesses by the pmap on amd64 are less likely to miss in the TLB. However, it doesn't place a hard restriction on the range of physical addresses that will be used, which you need for mips. The impact of this clustering can be significant. For example, on amd64 we use 2MB page mappings to implement the direct map. However, old Opterons only had 8 data TLB entries for 2MB page mappings. For a uniprocessor kernel running on such an Opteron, I measured an 18% reduction in system time during a buildworld with the introduction of VM_FREEPOOL_DIRECT. (See the commit logs for vm/vm_phys.c and the comment that precedes the VM_NFREEORDER definition on amd64.) Until such time as superpage support is ported to mips from the amd64/i386 pmaps, I don't think there is a point in having more than one VM_FREEPOOL_* on mips. And then, the point would be to reduce fragmentation of the physical memory that could be caused by small allocations, such as page table pages. Alan From owner-freebsd-mips@FreeBSD.ORG Tue Jun 8 06:42:35 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 809B71065675; Tue, 8 Jun 2010 06:42:35 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 10E128FC08; Tue, 8 Jun 2010 06:42:34 +0000 (UTC) Received: by vws4 with SMTP id 4so3253413vws.13 for ; Mon, 07 Jun 2010 23:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2ce52xBgRmc9cKitnuJFIAcncEpdaUJX4pmgs/VN9Ns=; b=VNPaieL4KiMoxcQf/YFb9sev4mD1JxgGmLvW+jMSrgKMDtgtNDfaBdD1haGEI9fnDQ qPtKNPhiHGTJWERR7K7rsmWOsAXDTwCmHO2tyoeqXCPXZPSTHFMxhKvHg0y1Ud+H5V0W WCDPK9nmJL/pEJv1KjZ2XKIhoINV/7oYH/seA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eL1iBrdokZXDMWaxcQD/CfWKH7NUAC9F+vNMdG22prIO8WSGuRMz3DCW6obGl41OWs mHzuMNioSJwl3G2s/E60ouCcAYDv/ikEFJW91jlET6/BoRvsmKe/6zURQUUhT+vIuiBX jPJf4JGQOQAiDPBqW0s9a0rAFkHVAI7BLPS2g= MIME-Version: 1.0 Received: by 10.229.234.3 with SMTP id ka3mr3027702qcb.261.1275979354006; Mon, 07 Jun 2010 23:42:34 -0700 (PDT) Received: by 10.220.189.13 with HTTP; Mon, 7 Jun 2010 23:42:33 -0700 (PDT) In-Reply-To: References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> Date: Tue, 8 Jun 2010 12:12:33 +0530 Message-ID: From: "C. Jayachandran" To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 06:42:35 -0000 On Tue, Jun 8, 2010 at 11:56 AM, Juli Mallett wrote: > On Mon, Jun 7, 2010 at 23:13, C. Jayachandran = wrote: >> On Tue, Jun 8, 2010 at 9:43 AM, Juli Mallett wrot= e: >>> Do you intend to support o32 kernels in your port indefinitely? =A0I >>> wonder whether this work is just stopgap until the systems which have >>> large amounts of RAM can just use n64 kernels. >> >> I think the page table work will be needed for o32 and n32, and I >> would like to support one of them as the preferred 32bit mode for our >> port. > > OK. > >> BTW, n32 with >4GB RAM can be supported with XKPHYS for page table >> entries. The options there would be either special allocator for the >> segtab (11+9+12 addr space split), or to use special allocator for all >> the page table pages (10+10+12 split). > > Yeah, but we have a disinterest in supporting n32 kernels in base > because it breaks assumptions in so many parts of the kernel, so I > think the most reasonable expectation for base is to support o32 and > n64, and to strongly prefer n64 for systems where it's more > appropriate. I've been maintaining a version of n32 kernel (completely based on on your patches) against CURRENT, which boots into multi-user. I would like to compare the performance with n64 before ruling it out fully. >>>=A0At least on Octeon it >>> seems to me that n64-only is the right answer if at all possible, >>> since there are really a lot of parts of the kernel that just can't >>> reasonably work otherwise (use of rman_get_virtual with io ports, for >>> instance.) >> >> Not sure I understand this part - I thought pmap_mapdev() would handle >> these - but I may be mistaken. > > There's nothing pmap_mapdev can do on an o32 kernel with 32-bit PTEs > for a physical address >2^36. =A0(There are rather a lot of those on > Octeon.) In XLR the boot-loader sets up the base registers to fall within 2^32. It even sets up some of the SoC, FLASH and PCI memory areas in KSEG0, so we end up with 256MB usable in KSEG0. These can be easily re-mapped, but I'd rather not change the boot loader settings just for FreeBSD. JC. From owner-freebsd-mips@FreeBSD.ORG Tue Jun 8 21:31:14 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F1BF1065689; Tue, 8 Jun 2010 21:31:14 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id D64BB8FC21; Tue, 8 Jun 2010 21:31:13 +0000 (UTC) Received: by pvb32 with SMTP id 32so114359pvb.13 for ; Tue, 08 Jun 2010 14:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UgCjRjZuaQR5dxbAkQreZjwubz2NqqHOpk+ZsRESzmw=; b=AxRPF5a8QwsZHBq7Bn+iB7HSRNqDKJllxu0wmGxIgJBWX8FxnMUZiIIBoRmgldFgpN KPYeYMiB61/hFHIkaII9CryIIbFU1bMFXG1fvohUt0ph+HzuycRkUINcZmscFPQq9dHs xM+Ul2N3HWtUeIYHa7TAKcSZ8HDoO9euEaEoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CcgcMAsAyy14OPN/aOAfqdTM+cBMNRAtdtXLNGgXE711Tj4auX40z2PDW5gDgYhHTD nWLkOv0Vun85zkeO+CS8P6AZmuyiujYFgfi4p3RDiJYJpZ5eUazeC+ODUJgfC35XpIKM PDPYnneAhu4nZ8tlbccJCzCl8L+0qq1eUlLYM= MIME-Version: 1.0 Received: by 10.229.186.211 with SMTP id ct19mr3847153qcb.206.1276032672738; Tue, 08 Jun 2010 14:31:12 -0700 (PDT) Received: by 10.220.189.13 with HTTP; Tue, 8 Jun 2010 14:31:12 -0700 (PDT) In-Reply-To: <4C0DE424.9080601@cs.rice.edu> References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> <4C0DE424.9080601@cs.rice.edu> Date: Wed, 9 Jun 2010 03:01:12 +0530 Message-ID: From: "Jayachandran C." To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , "Jayachandran C." , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 21:31:14 -0000 On Tue, Jun 8, 2010 at 12:03 PM, Alan Cox wrote: > C. Jayachandran wrote: >> >> On Tue, Jun 8, 2010 at 2:59 AM, Alan Cox wrote: >> >>> >>> On 6/7/2010 3:28 PM, Kostik Belousov wrote: >>> >>>> >>>> Selecting a random message in the thread to ask my question. >>>> Is the issue that page table pages should be allocated from the specif= ic >>>> physical region of the memory ? If yes, doesn't i386 PAE has similar >>>> issue with page directory pointer table ? I see a KASSERT in i386 >>>> pmap that verifies that the allocated table is below 4G, but I do not >>>> understand how uma ensures the constraint (I suspect that it does not)= . >>>> >>>> >>> >>> For i386 PAE, the UMA backend allocator uses kmem_alloc_contig() to >>> ensure >>> that the memory is below 4G. =A0The crucial difference between i386 PAE= and >>> MIPS is that for i386 PAE only the top-level table needs to be below a >>> specific address threshold. =A0Moreover, this level is allocated in a >>> place, >>> pmap_pinit(), where we are allowed to sleep. >>> >> >> Yes. I saw the PAE top level page table code and thought I could use >> that mechanism for allocating MIPS page table pages in the direct >> mapped memory. The other reference I used was >> pmap_alloc_zeroed_contig_pages() function in sun4v/sun4v/pmap.c which >> uses the vm_phys_alloc_contig() and VM_WAIT. > > That's unfortunate. =A0:-( =A0Since sun4v is essentially dead code, I've = never > spent much time thinking about its pmap implementation. =A0I'll mechanica= lly > apply changes to it, but that's about it. =A0I wouldn't recommend using i= t as > a reference. > >> ... =A0I had also thought of >> using the VM_FREEPOOL_DIRECT which seemed to be for a similar purpose, >> but could find see any usage in the kernel. >> >> > > VM_FREEPOOL_DIRECT is used by at least amd64 and ia64 for page table page= s > and small kernel memory allocations. =A0Unlike mips, these machines don't= have > MMU support for a direct map. =A0Their direct maps are just a range of > mappings in the regular (kernel) page table. =A0So, unlike mips, accesses > through their direct map may still miss in the TLB and require a page tab= le > walk. =A0VM_FREEPOOL_* is a way to increase the physical locality (or > clustering) of page allocations, so that, for example, page table page > accesses by the pmap on amd64 are less likely to miss in the TLB. =A0Howe= ver, > it doesn't place a hard restriction on the range of physical addresses th= at > will be used, which you need for mips. > > The impact of this clustering can be significant. =A0For example, on amd6= 4 we > use 2MB page mappings to implement the direct map. =A0However, old Optero= ns > only had 8 data TLB entries for 2MB page mappings. =A0For a uniprocessor > kernel running on such an Opteron, I measured an 18% reduction in system > time during a buildworld with the introduction of VM_FREEPOOL_DIRECT. =A0= (See > the commit logs for vm/vm_phys.c and the comment that precedes the > VM_NFREEORDER definition on amd64.) > > Until such time as superpage support is ported to mips from the amd64/i38= 6 > pmaps, I don't think there is a point in having more than one VM_FREEPOOL= _* > on mips. =A0And then, the point would be to reduce fragmentation of the > physical memory that could be caused by small allocations, such as page > table pages. Thanks for the detailed explanation. Also, after looking at the code again, I think vm_phys_alloc_contig() can optimized not to look into segments which lie outside the area of interest. The patch is: Index: sys/vm/vm_phys.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/vm/vm_phys.c (revision 208890) +++ sys/vm/vm_phys.c (working copy) @@ -595,7 +595,7 @@ vm_object_t m_object; vm_paddr_t pa, pa_last, size; vm_page_t deferred_vdrop_list, m, m_ret; - int flind, i, oind, order, pind; + int segind, i, oind, order, pind; size =3D npages << PAGE_SHIFT; KASSERT(size !=3D 0, @@ -611,21 +611,20 @@ #if VM_NRESERVLEVEL > 0 retry: #endif - for (flind =3D 0; flind < vm_nfreelists; flind++) { + for (segind =3D 0; segind < vm_phys_nsegs; segind++) { + /* + * A free list may contain physical pages + * from one or more segments. + */ + seg =3D &vm_phys_segs[segind]; + if (seg->start > high || low >=3D seg->end) + continue; + for (oind =3D min(order, VM_NFREEORDER - 1); oind < VM_NFREEORDER; oind++) { for (pind =3D 0; pind < VM_NFREEPOOL; pind++) { - fl =3D vm_phys_free_queues[flind][pind]; + fl =3D (*seg->free_queues)[pind]; TAILQ_FOREACH(m_ret, &fl[oind].pl, pageq) { /* - * A free list may contain physical pages - * from one or more segments. - */ - seg =3D &vm_phys_segs[m_ret->segind= ]; - if (seg->start > high || - low >=3D seg->end) - continue; - - /* * Is the size of this allocation request * larger than the largest block si= ze? */ ----- This change, along with the vmparam.h changes for HIGHMEM, I think we should be able to use vm_phys_alloc_contig() for page table pages (or have I again missed something fundamental?). JC. From owner-freebsd-mips@FreeBSD.ORG Wed Jun 9 05:50:24 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6422106564A; Wed, 9 Jun 2010 05:50:24 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 630388FC24; Wed, 9 Jun 2010 05:50:24 +0000 (UTC) Received: by vws1 with SMTP id 1so575901vws.13 for ; Tue, 08 Jun 2010 22:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=j+QBLzLRA94V0clIBAlWct1sAH2Ew1WLJ3InQkAXMqQ=; b=Sd4YCfufszrYQ8k1Dzp9nVLGF3uR5m7D/xL/PlOCHZg8sdb6HNsdj0MwTZa/bPJDTj A4yLeNFwhum+dBN/TG2t4EtFlCdU6B8ylkaZn+Hw8wje7k1X5YtOwYmBS1RZ3O9IeRNG dzhGFl1k3nM1rCnOVR0UXiIRW+Q5JxU2JfTGM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wR4r291+XOiHdS3Qgvjp6+Xq7Fq1E1jq0Spx2zY45c6yTAjHh7sdPXccSFCZPFfTLP s5RvZ5d7k/51cQIgVG7FxfsWHrNNhDkGEMuIhT0WHhhiqmEwPl7WLqzqTCdJoaFIGP5S lDWaAcJl6d1gPeevi/DMctbvS5hf/vJQqz6bQ= MIME-Version: 1.0 Received: by 10.224.27.142 with SMTP id i14mr1436526qac.272.1276062622667; Tue, 08 Jun 2010 22:50:22 -0700 (PDT) Received: by 10.220.189.13 with HTTP; Tue, 8 Jun 2010 22:50:22 -0700 (PDT) In-Reply-To: References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> <4C0DE424.9080601@cs.rice.edu> Date: Wed, 9 Jun 2010 11:20:22 +0530 Message-ID: From: "Jayachandran C." To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , "Jayachandran C." , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 05:50:25 -0000 On Wed, Jun 9, 2010 at 3:01 AM, Jayachandran C. wrote: > On Tue, Jun 8, 2010 at 12:03 PM, Alan Cox wrote: >> >> VM_FREEPOOL_DIRECT is used by at least amd64 and ia64 for page table pag= es >> and small kernel memory allocations. =A0Unlike mips, these machines don'= t have >> MMU support for a direct map. =A0Their direct maps are just a range of >> mappings in the regular (kernel) page table. =A0So, unlike mips, accesse= s >> through their direct map may still miss in the TLB and require a page ta= ble >> walk. =A0VM_FREEPOOL_* is a way to increase the physical locality (or >> clustering) of page allocations, so that, for example, page table page >> accesses by the pmap on amd64 are less likely to miss in the TLB. =A0How= ever, >> it doesn't place a hard restriction on the range of physical addresses t= hat >> will be used, which you need for mips. >> >> The impact of this clustering can be significant. =A0For example, on amd= 64 we >> use 2MB page mappings to implement the direct map. =A0However, old Opter= ons >> only had 8 data TLB entries for 2MB page mappings. =A0For a uniprocessor >> kernel running on such an Opteron, I measured an 18% reduction in system >> time during a buildworld with the introduction of VM_FREEPOOL_DIRECT. = =A0(See >> the commit logs for vm/vm_phys.c and the comment that precedes the >> VM_NFREEORDER definition on amd64.) >> >> Until such time as superpage support is ported to mips from the amd64/i3= 86 >> pmaps, I don't think there is a point in having more than one VM_FREEPOO= L_* >> on mips. =A0And then, the point would be to reduce fragmentation of the >> physical memory that could be caused by small allocations, such as page >> table pages. > > Thanks for the detailed explanation. > > Also, after looking at the code again, =A0I think vm_phys_alloc_contig() > can optimized not to look into segments which lie outside the area of > interest. The patch is: [...] > This change, along with the vmparam.h changes for HIGHMEM, I think we > should be able to use =A0vm_phys_alloc_contig() for page table pages (or > have I again missed something fundamental?). That patch was obviously wrong - many segments can map to a freelist as the comment right above my change noted. But the idea of eliminating freelists for which all the segments are outside (low,high) may still be useful, will look at this some more. JC. From owner-freebsd-mips@FreeBSD.ORG Wed Jun 9 18:11:58 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9E671065674; Wed, 9 Jun 2010 18:11:58 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 970ED8FC26; Wed, 9 Jun 2010 18:11:58 +0000 (UTC) Received: by pvb32 with SMTP id 32so646108pvb.13 for ; Wed, 09 Jun 2010 11:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=bld56DLCQdUp+2cn3ejfAwMj5bx6mbhX2kgPrqPm6II=; b=kJKtVNdyTrO9rIOV7vCHSyZQFe9+I8SHd0lLtjj+Ve6HZpbhAE2ibmBI5WCjSh63Qh tUI4Dv8/9Nzlpzz0Oo9zWCRhkH9uq1nKIVFapG0bIviOPkH9N8rITml1MjfUJFsjrWgg s2aZ+1gvCR4NvONYY0rM4biv/cVl6wiwd1Sgo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Dglkr71bj+97ixVBh6QhMIWWnVPptnALi1xygLxtp189NrnUXKaY5ZGO6XVAySv3We ePvCyU3sl+BI7Z8Y2vSRH5eaEIHsSe/aSs8CbwwVgyQZRUHErzw5yygRdeFBUDnEfwML Muf8SB2dGvk9taOt1kLxQeIjTpEtPIGkZNdbg= MIME-Version: 1.0 Received: by 10.229.237.144 with SMTP id ko16mr6467965qcb.68.1276107117297; Wed, 09 Jun 2010 11:11:57 -0700 (PDT) Received: by 10.220.189.13 with HTTP; Wed, 9 Jun 2010 11:11:57 -0700 (PDT) In-Reply-To: References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> <4C0DE424.9080601@cs.rice.edu> Date: Wed, 9 Jun 2010 23:41:57 +0530 Message-ID: From: "Jayachandran C." To: Alan Cox Content-Type: multipart/mixed; boundary=0016364edd086c06ef04889cd7fe Cc: Kostik Belousov , "Jayachandran C." , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 18:11:58 -0000 --0016364edd086c06ef04889cd7fe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 9, 2010 at 11:20 AM, Jayachandran C. wrote: > On Wed, Jun 9, 2010 at 3:01 AM, Jayachandran C. > wrote: >> On Tue, Jun 8, 2010 at 12:03 PM, Alan Cox wrote: >>> >>> VM_FREEPOOL_DIRECT is used by at least amd64 and ia64 for page table pa= ges >>> and small kernel memory allocations. =A0Unlike mips, these machines don= 't have >>> MMU support for a direct map. =A0Their direct maps are just a range of >>> mappings in the regular (kernel) page table. =A0So, unlike mips, access= es >>> through their direct map may still miss in the TLB and require a page t= able >>> walk. =A0VM_FREEPOOL_* is a way to increase the physical locality (or >>> clustering) of page allocations, so that, for example, page table page >>> accesses by the pmap on amd64 are less likely to miss in the TLB. =A0Ho= wever, >>> it doesn't place a hard restriction on the range of physical addresses = that >>> will be used, which you need for mips. >>> >>> The impact of this clustering can be significant. =A0For example, on am= d64 we >>> use 2MB page mappings to implement the direct map. =A0However, old Opte= rons >>> only had 8 data TLB entries for 2MB page mappings. =A0For a uniprocesso= r >>> kernel running on such an Opteron, I measured an 18% reduction in syste= m >>> time during a buildworld with the introduction of VM_FREEPOOL_DIRECT. = =A0(See >>> the commit logs for vm/vm_phys.c and the comment that precedes the >>> VM_NFREEORDER definition on amd64.) >>> >>> Until such time as superpage support is ported to mips from the amd64/i= 386 >>> pmaps, I don't think there is a point in having more than one VM_FREEPO= OL_* >>> on mips. =A0And then, the point would be to reduce fragmentation of the >>> physical memory that could be caused by small allocations, such as page >>> table pages. >> >> Thanks for the detailed explanation. >> >> Also, after looking at the code again, =A0I think vm_phys_alloc_contig() >> can optimized not to look into segments which lie outside the area of >> interest. The patch is: > [...] >> This change, along with the vmparam.h changes for HIGHMEM, I think we >> should be able to use =A0vm_phys_alloc_contig() for page table pages (or >> have I again missed something fundamental?). > > That patch was obviously wrong - many segments can map to a freelist > as the comment right above my change noted. > > But the idea of eliminating freelists for which all the segments are > outside (low,high) may still be useful, will look at this some more. I have attached a patch (also at http://people.freebsd.org/~jchandra/pmap-with-HIGHMEM-freelist.patch) which reverts most of the changes I did to convert the page table page allocation to use UMA zone, and replaces it with an implementation using vm_phys_alloc_contig() and vm_contig_grow_cache(). This creates a new HIGHMEM freelist for mips for memory outside the KSEG0 area, and makes a few changes in vm_phys_alloc_contig() to skip freelists for which all the segments fall outside the address range requested. With this the buildworld perf on MIPS is similar to what I got with the older code with zones. If this approach is okay, I will do another round of testing(buildworld passes, but I haven't really tested the case where grow_cache is called). If the changes are not okay, I will add another page allocator which takes freelist as argument as you had suggested earlier, instead of the vm_phys_alloc_contig() changes. Thanks, JC. --0016364edd086c06ef04889cd7fe Content-Type: application/octet-stream; name="pmap-with-HIGHMEM-freelist.patch" Content-Disposition: attachment; filename="pmap-with-HIGHMEM-freelist.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ga8h2ua20 SW5kZXg6IHN5cy9taXBzL2luY2x1ZGUvdm1wYXJhbS5oCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9taXBz L2luY2x1ZGUvdm1wYXJhbS5oCShyZXZpc2lvbiAyMDg4OTApCisrKyBzeXMvbWlwcy9pbmNsdWRl L3ZtcGFyYW0uaAkod29ya2luZyBjb3B5KQpAQCAtMTAzLDggKzEwMyw5IEBACiAjZGVmaW5lCVZN X01BWFVTRVJfQUREUkVTUwkoKHZtX29mZnNldF90KTB4ODAwMDAwMDApCiAjZGVmaW5lCVZNX01B WF9NTUFQX0FERFIJVk1fTUFYVVNFUl9BRERSRVNTCiAKLSNkZWZpbmUJVk1fTUlOX0tFUk5FTF9B RERSRVNTCQkoKHZtX29mZnNldF90KTB4QzAwMDAwMDApCi0jZGVmaW5lCVZNX01BWF9LRVJORUxf QUREUkVTUwkJKCh2bV9vZmZzZXRfdCkweEZGRkZDMDAwKQorI2RlZmluZQlWTV9NSU5fS0VSTkVM X0FERFJFU1MJKCh2bV9vZmZzZXRfdCkweEMwMDAwMDAwKQorI2RlZmluZQlWTV9NQVhfS0VSTkVM X0FERFJFU1MJKCh2bV9vZmZzZXRfdCkweEZGRkZDMDAwKQorI2RlZmluZQlWTV9ISUdITUVNX0FE RFJFU1MJKCh2bV9wYWRkcl90KTB4MjAwMDAwMDApCiAjaWYgMAogI2RlZmluZQlLRVJOQkFTRQkJ KFZNX01JTl9LRVJORUxfQUREUkVTUykKICNlbHNlCkBAIC0xNjgsMTMgKzE2OSwxNSBAQAogI2Rl ZmluZQlWTV9GUkVFUE9PTF9ESVJFQ1QJMQogCiAvKgotICogd2Ugc3VwcG9ydCAxIGZyZWUgbGlz dDoKKyAqIHdlIHN1cHBvcnQgMiBmcmVlIGxpc3RzOgogICoKLSAqCS0gREVGQVVMVCBmb3IgYWxs IHN5c3RlbXMKKyAqCS0gREVGQVVMVCBmb3IgZGlyZWN0IG1hcHBlZCAoS1NFRzApIHBhZ2VzCisg KgktIEhJR0hNRU0gZm9yIG90aGVyIHBhZ2VzIAogICovCiAKLSNkZWZpbmUJVk1fTkZSRUVMSVNU CQkxCi0jZGVmaW5lCVZNX0ZSRUVMSVNUX0RFRkFVTFQJMAorI2RlZmluZQlWTV9ORlJFRUxJU1QJ CTIKKyNkZWZpbmUJVk1fRlJFRUxJU1RfREVGQVVMVAkxCisjZGVmaW5lCVZNX0ZSRUVMSVNUX0hJ R0hNRU0JMAogCiAvKgogICogVGhlIGxhcmdlc3QgYWxsb2NhdGlvbiBzaXplIGlzIDFNQi4KSW5k ZXg6IHN5cy9taXBzL21pcHMvcG1hcC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9taXBzL21pcHMvcG1h cC5jCShyZXZpc2lvbiAyMDg4OTApCisrKyBzeXMvbWlwcy9taXBzL3BtYXAuYwkod29ya2luZyBj b3B5KQpAQCAtMTg0LDggKzE4NCw2IEBACiBzdGF0aWMgaW50IGluaXRfcHRlX3Byb3Qodm1fb2Zm c2V0X3QgdmEsIHZtX3BhZ2VfdCBtLCB2bV9wcm90X3QgcHJvdCk7CiBzdGF0aWMgdm9pZCBwbWFw X1RMQl9pbnZhbGlkYXRlX2tlcm5lbCh2bV9vZmZzZXRfdCk7CiBzdGF0aWMgdm9pZCBwbWFwX1RM Ql91cGRhdGVfa2VybmVsKHZtX29mZnNldF90LCBwdF9lbnRyeV90KTsKLXN0YXRpYyB2bV9wYWdl X3QgcG1hcF9hbGxvY19wdGVfcGFnZShwbWFwX3QsIHVuc2lnbmVkIGludCwgaW50LCB2bV9vZmZz ZXRfdCAqKTsKLXN0YXRpYyB2b2lkIHBtYXBfcmVsZWFzZV9wdGVfcGFnZSh2bV9wYWdlX3QpOwog CiAjaWZkZWYgU01QCiBzdGF0aWMgdm9pZCBwbWFwX2ludmFsaWRhdGVfcGFnZV9hY3Rpb24odm9p ZCAqYXJnKTsKQEAgLTE5MywxMCArMTkxLDYgQEAKIHN0YXRpYyB2b2lkIHBtYXBfdXBkYXRlX3Bh Z2VfYWN0aW9uKHZvaWQgKmFyZyk7CiAjZW5kaWYKIAotc3RhdGljIHZvaWQgcG1hcF9wdHBnem9u ZV9kdG9yKHZvaWQgKm1lbSwgaW50IHNpemUsIHZvaWQgKmFyZyk7Ci1zdGF0aWMgdm9pZCAqcG1h cF9wdHBnem9uZV9hbGxvY2YodW1hX3pvbmVfdCwgaW50LCB1X2ludDhfdCAqLCBpbnQpOwotc3Rh dGljIHVtYV96b25lX3QgcHRwZ3pvbmU7Ci0KIHN0cnVjdCBsb2NhbF9zeXNtYXBzIHsKIAlzdHJ1 Y3QgbXR4IGxvY2s7CiAJdm1fb2Zmc2V0X3QgYmFzZTsKQEAgLTMyOSw3ICszMjMsNyBAQAogfQog CiAvKgotICoJQm9vdHN0cmFwIHRoZSBzeXN0ZW0gZW5vdWdoIHRvIHJ1biB3aXRoIHZpcnR1YWwg bWVtb3J5LiAgVGhpcworICogQm9vdHN0cmFwIHRoZSBzeXN0ZW0gZW5vdWdoIHRvIHJ1biB3aXRo IHZpcnR1YWwgbWVtb3J5LiAgVGhpcwogICogYXNzdW1lcyB0aGF0IHRoZSBwaHlzX2F2YWlsIGFy cmF5IGhhcyBiZWVuIGluaXRpYWxpemVkLgogICovCiB2b2lkCkBAIC01MzUsMTAgKzUyOSw2IEBA CiAJcHZfZW50cnlfbWF4ID0gUE1BUF9TSFBHUEVSUFJPQyAqIG1heHByb2MgKyBjbnQudl9wYWdl X2NvdW50OwogCXB2X2VudHJ5X2hpZ2hfd2F0ZXIgPSA5ICogKHB2X2VudHJ5X21heCAvIDEwKTsK IAl1bWFfem9uZV9zZXRfb2JqKHB2em9uZSwgJnB2em9uZV9vYmosIHB2X2VudHJ5X21heCk7Ci0K LQlwdHBnem9uZSA9IHVtYV96Y3JlYXRlKCJQVCBFTlRSWSIsIFBBR0VfU0laRSwgTlVMTCwgcG1h cF9wdHBnem9uZV9kdG9yLAotCSAgICBOVUxMLCBOVUxMLCBQQUdFX1NJWkUgLSAxLCBVTUFfWk9O RV9OT0ZSRUUgfCBVTUFfWk9ORV9aSU5JVCk7Ci0JdW1hX3pvbmVfc2V0X2FsbG9jZihwdHBnem9u ZSwgcG1hcF9wdHBnem9uZV9hbGxvY2YpOwogfQogCiAvKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqCkBAIC04ODUsMTIgKzg3NSw4IEBACiAJLyoKIAkg KiBJZiB0aGUgcGFnZSBpcyBmaW5hbGx5IHVud2lyZWQsIHNpbXBseSBmcmVlIGl0LgogCSAqLwor CXZtX3BhZ2VfZnJlZV96ZXJvKG0pOwogCWF0b21pY19zdWJ0cmFjdF9pbnQoJmNudC52X3dpcmVf Y291bnQsIDEpOwotCVBNQVBfVU5MT0NLKHBtYXApOwotCXZtX3BhZ2VfdW5sb2NrX3F1ZXVlcygp OwotCXBtYXBfcmVsZWFzZV9wdGVfcGFnZShtKTsKLQl2bV9wYWdlX2xvY2tfcXVldWVzKCk7Ci0J UE1BUF9MT0NLKHBtYXApOwogCXJldHVybiAoMSk7CiB9CiAKQEAgLTk0OSw5NiArOTM1LDM2IEBA CiAJYnplcm8oJnBtYXAtPnBtX3N0YXRzLCBzaXplb2YgcG1hcC0+cG1fc3RhdHMpOwogfQogCisK IHN0YXRpYyB2b2lkCi1wbWFwX3B0cGd6b25lX2R0b3Iodm9pZCAqbWVtLCBpbnQgc2l6ZSwgdm9p ZCAqYXJnKQorcG1hcF9ncm93X3BhZ2VfY2FjaGUoaW50IHdhaXQpCiB7Ci0jaWZkZWYgSU5WQVJJ QU5UUwotCXN0YXRpYyBjaGFyIHplcm9wYWdlW1BBR0VfU0laRV07Ci0KLQlLQVNTRVJUKHNpemUg PT0gUEFHRV9TSVpFLAotCQkoInBtYXBfcHRwZ3pvbmVfZHRvcjogaW52YWxpZCBzaXplICVkIiwg c2l6ZSkpOwotCUtBU1NFUlQoYmNtcChtZW0sIHplcm9wYWdlLCBQQUdFX1NJWkUpID09IDAsCi0J CSgicG1hcF9wdHBnem9uZV9kdG9yOiBmcmVlaW5nIGEgbm9uLXplcm9lZCBwYWdlIikpOwotI2Vu ZGlmCisJcHJpbnRmKCJbJXNdIHdhaXQgJXhcbiIsIF9fZnVuY19fLCB3YWl0KTsKKwl2bV9jb250 aWdfZ3Jvd19jYWNoZSgzLCAwLCBNSVBTX0tTRUcwX0xBUkdFU1RfUEhZUyk7CiB9CiAKLXN0YXRp YyB2b2lkICoKLXBtYXBfcHRwZ3pvbmVfYWxsb2NmKHVtYV96b25lX3Qgem9uZSwgaW50IGJ5dGVz LCB1X2ludDhfdCAqZmxhZ3MsIGludCB3YWl0KQotewotCXZtX3BhZ2VfdCBtOwotCXZtX3BhZGRy X3QgcGFkZHI7Ci0JaW50IHRyaWVzOwotCQotCUtBU1NFUlQoYnl0ZXMgPT0gUEFHRV9TSVpFLAot CQkoInBtYXBfcHRwZ3pvbmVfYWxsb2NmOiBpbnZhbGlkIGFsbG9jYXRpb24gc2l6ZSAlZCIsIGJ5 dGVzKSk7CiAKLQkqZmxhZ3MgPSBVTUFfU0xBQl9QUklWOwotCXRyaWVzID0gMDsKLXJldHJ5Ogot CW0gPSB2bV9waHlzX2FsbG9jX2NvbnRpZygxLCAwLCBNSVBTX0tTRUcwX0xBUkdFU1RfUEhZUywK LQkgICAgUEFHRV9TSVpFLCBQQUdFX1NJWkUpOwotCWlmIChtID09IE5VTEwpIHsKLSAgICAgICAg ICAgICAgICBpZiAodHJpZXMgPCAoKHdhaXQgJiBNX05PV0FJVCkgIT0gMCA/IDEgOiAzKSkgewot CQkJdm1fY29udGlnX2dyb3dfY2FjaGUodHJpZXMsIDAsIE1JUFNfS1NFRzBfTEFSR0VTVF9QSFlT KTsKLQkJCXRyaWVzKys7Ci0JCQlnb3RvIHJldHJ5OwotCQl9IGVsc2UKLQkJCXJldHVybiAoTlVM TCk7Ci0JfQotCi0JcGFkZHIgPSBWTV9QQUdFX1RPX1BIWVMobSk7Ci0JcmV0dXJuICgodm9pZCAq KU1JUFNfUEhZU19UT19LU0VHMChwYWRkcikpOwotfQkKLQogc3RhdGljIHZtX3BhZ2VfdAotcG1h cF9hbGxvY19wdGVfcGFnZShwbWFwX3QgcG1hcCwgdW5zaWduZWQgaW50IGluZGV4LCBpbnQgd2Fp dCwgdm1fb2Zmc2V0X3QgKnZhcCkKK3BtYXBfYWxsb2NfcHRlX3BhZ2UodW5zaWduZWQgaW50IGlu ZGV4LCBpbnQgd2FpdCkKIHsKLQl2bV9wYWRkcl90IHBhZGRyOwotCXZvaWQgKnZhOwogCXZtX3Bh Z2VfdCBtOwotCWludCBsb2NrZWQ7CiAKLQlsb2NrZWQgPSBtdHhfb3duZWQoJnBtYXAtPnBtX210 eCk7Ci0JaWYgKGxvY2tlZCkgewotCQltdHhfYXNzZXJ0KCZ2bV9wYWdlX3F1ZXVlX210eCwgTUFf T1dORUQpOwotCQlQTUFQX1VOTE9DSyhwbWFwKTsKLQkJdm1fcGFnZV91bmxvY2tfcXVldWVzKCk7 Ci0JfQotCXZhID0gdW1hX3phbGxvYyhwdHBnem9uZSwgd2FpdCk7Ci0JaWYgKGxvY2tlZCkgewot CQl2bV9wYWdlX2xvY2tfcXVldWVzKCk7Ci0JCVBNQVBfTE9DSyhwbWFwKTsKLQl9Ci0JaWYgKHZh ID09IE5VTEwpCisJbSA9IHZtX3BoeXNfYWxsb2NfY29udGlnKDEsIDAsIE1JUFNfS1NFRzBfTEFS R0VTVF9QSFlTLAorCSAgICBQQUdFX1NJWkUsIDApOworCWlmIChtID09IE5VTEwpCiAJCXJldHVy biAoTlVMTCk7CiAKLQlwYWRkciA9IE1JUFNfS1NFRzBfVE9fUEhZUyh2YSk7Ci0JbSA9IFBIWVNf VE9fVk1fUEFHRShwYWRkcik7Ci0JCi0JaWYgKCFsb2NrZWQpCi0JCXZtX3BhZ2VfbG9ja19xdWV1 ZXMoKTsKKwlpZiAoKG0tPmZsYWdzICYgUEdfWkVSTykgPT0gMCkKKwkJcG1hcF96ZXJvX3BhZ2Uo bSk7CisKIAltLT5waW5kZXggPSBpbmRleDsKIAltLT52YWxpZCA9IFZNX1BBR0VfQklUU19BTEw7 Ci0JbS0+d2lyZV9jb3VudCA9IDE7Ci0JaWYgKCFsb2NrZWQpCi0JCXZtX3BhZ2VfdW5sb2NrX3F1 ZXVlcygpOwotCiAJYXRvbWljX2FkZF9pbnQoJmNudC52X3dpcmVfY291bnQsIDEpOwotCSp2YXAg PSAodm1fb2Zmc2V0X3QpdmE7CisJbS0+d2lyZV9jb3VudCA9IDE7CiAJcmV0dXJuIChtKTsKIH0K IAotc3RhdGljIHZvaWQKLXBtYXBfcmVsZWFzZV9wdGVfcGFnZSh2bV9wYWdlX3QgbSkKLXsKLQl2 b2lkICp2YTsKLQl2bV9wYWRkcl90IHBhZGRyOwogCi0JcGFkZHIgPSBWTV9QQUdFX1RPX1BIWVMo bSk7Ci0JdmEgPSAodm9pZCAqKU1JUFNfUEhZU19UT19LU0VHMChwYWRkcik7Ci0JdW1hX3pmcmVl KHB0cGd6b25lLCB2YSk7Ci19Ci0KIC8qCiAgKiBJbml0aWFsaXplIGEgcHJlYWxsb2NhdGVkIGFu ZCB6ZXJvZWQgcG1hcCBzdHJ1Y3R1cmUsCiAgKiBzdWNoIGFzIG9uZSBpbiBhIHZtc3BhY2Ugc3Ry dWN0dXJlLgpAQCAtMTA1NSwxMCArOTgxLDEwIEBACiAJLyoKIAkgKiBhbGxvY2F0ZSB0aGUgcGFn ZSBkaXJlY3RvcnkgcGFnZQogCSAqLwotCXB0ZHBnID0gcG1hcF9hbGxvY19wdGVfcGFnZShwbWFw LCBOVVNFUlBHVEJMUywgTV9XQUlUT0ssICZwdGR2YSk7Ci0JaWYgKHB0ZHBnID09IE5VTEwpCi0J CXJldHVybiAoMCk7CisJd2hpbGUgKChwdGRwZyA9IHBtYXBfYWxsb2NfcHRlX3BhZ2UoTlVTRVJQ R1RCTFMsIE1fV0FJVE9LKSkgPT0gTlVMTCkKKwkgICAgICAgcG1hcF9ncm93X3BhZ2VfY2FjaGUo TV9XQUlUT0spOwogCisJcHRkdmEgPSBNSVBTX1BIWVNfVE9fS1NFRzAoVk1fUEFHRV9UT19QSFlT KHB0ZHBnKSk7CiAJcG1hcC0+cG1fc2VndGFiID0gKHBkX2VudHJ5X3QgKilwdGR2YTsKIAlwbWFw LT5wbV9hY3RpdmUgPSAwOwogCXBtYXAtPnBtX3B0cGhpbnQgPSBOVUxMOwpAQCAtMTA4OSwxNSAr MTAxNSwyOCBAQAogCS8qCiAJICogRmluZCBvciBmYWJyaWNhdGUgYSBuZXcgcGFnZXRhYmxlIHBh Z2UKIAkgKi8KLQltID0gcG1hcF9hbGxvY19wdGVfcGFnZShwbWFwLCBwdGVwaW5kZXgsIGZsYWdz LCAmcHRldmEpOwotCWlmIChtID09IE5VTEwpCisJaWYgKChtID0gcG1hcF9hbGxvY19wdGVfcGFn ZShwdGVwaW5kZXgsIGZsYWdzKSkgPT0gTlVMTCkgeworCQlpZiAoZmxhZ3MgJiBNX1dBSVRPSykg eworCQkJUE1BUF9VTkxPQ0socG1hcCk7CisJCQl2bV9wYWdlX3VubG9ja19xdWV1ZXMoKTsKKwkJ CXBtYXBfZ3Jvd19wYWdlX2NhY2hlKGZsYWdzKTsKKwkJCXZtX3BhZ2VfbG9ja19xdWV1ZXMoKTsK KwkJCVBNQVBfTE9DSyhwbWFwKTsKKwkJfQorCisJCS8qCisJCSAqIEluZGljYXRlIHRoZSBuZWVk IHRvIHJldHJ5LglXaGlsZSB3YWl0aW5nLCB0aGUgcGFnZQorCQkgKiB0YWJsZSBwYWdlIG1heSBo YXZlIGJlZW4gYWxsb2NhdGVkLgorCQkgKi8KIAkJcmV0dXJuIChOVUxMKTsKKwl9CiAKIAkvKgog CSAqIE1hcCB0aGUgcGFnZXRhYmxlIHBhZ2UgaW50byB0aGUgcHJvY2VzcyBhZGRyZXNzIHNwYWNl LCBpZiBpdAogCSAqIGlzbid0IGFscmVhZHkgdGhlcmUuCiAJICovCiAKKwlwdGV2YSA9IE1JUFNf UEhZU19UT19LU0VHMChWTV9QQUdFX1RPX1BIWVMobSkpOwogCXBtYXAtPnBtX3N0YXRzLnJlc2lk ZW50X2NvdW50Kys7CiAJcG1hcC0+cG1fc2VndGFiW3B0ZXBpbmRleF0gPSAocGRfZW50cnlfdClw dGV2YTsKIApAQCAtMTE5Myw3ICsxMTMyLDcgQEAKIAogCXB0ZHBnLT53aXJlX2NvdW50LS07CiAJ YXRvbWljX3N1YnRyYWN0X2ludCgmY250LnZfd2lyZV9jb3VudCwgMSk7Ci0JcG1hcF9yZWxlYXNl X3B0ZV9wYWdlKHB0ZHBnKTsKKwl2bV9wYWdlX2ZyZWVfemVybyhwdGRwZyk7CiAJUE1BUF9MT0NL X0RFU1RST1kocG1hcCk7CiB9CiAKQEAgLTEyMDMsNyArMTE0Miw2IEBACiB2b2lkCiBwbWFwX2dy b3drZXJuZWwodm1fb2Zmc2V0X3QgYWRkcikKIHsKLQl2bV9vZmZzZXRfdCBwYWdldmE7CiAJdm1f cGFnZV90IG5rcGc7CiAJcHRfZW50cnlfdCAqcHRlOwogCWludCBpOwpAQCAtMTIzOCwxMyArMTE3 NiwxMyBAQAogCQkvKgogCQkgKiBUaGlzIGluZGV4IGlzIGJvZ3VzLCBidXQgb3V0IG9mIHRoZSB3 YXkKIAkJICovCi0JCW5rcGcgPSBwbWFwX2FsbG9jX3B0ZV9wYWdlKGtlcm5lbF9wbWFwLCBua3B0 LCBNX05PV0FJVCwgJnBhZ2V2YSk7CisJCW5rcGcgPSBwbWFwX2FsbG9jX3B0ZV9wYWdlKG5rcHQs IE1fTk9XQUlUKTsKIAogCQlpZiAoIW5rcGcpCiAJCQlwYW5pYygicG1hcF9ncm93a2VybmVsOiBu byBtZW1vcnkgdG8gZ3JvdyBrZXJuZWwiKTsKIAogCQlua3B0Kys7Ci0JCXB0ZSA9IChwdF9lbnRy eV90ICopcGFnZXZhOworCQlwdGUgPSAocHRfZW50cnlfdCAqKU1JUFNfUEhZU19UT19LU0VHMChW TV9QQUdFX1RPX1BIWVMobmtwZykpOwogCQlzZWd0YWJfcGRlKGtlcm5lbF9zZWdtYXAsIGtlcm5l bF92bV9lbmQpID0gKHBkX2VudHJ5X3QpcHRlOwogCiAJCS8qCkluZGV4OiBzeXMvdm0vdm1fcGh5 cy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIHN5cy92bS92bV9waHlzLmMJKHJldmlzaW9uIDIwODg5MCkKKysr IHN5cy92bS92bV9waHlzLmMJKHdvcmtpbmcgY29weSkKQEAgLTY2LDYgKzY2LDcgQEAKIAl2bV9w YWRkcl90CWVuZDsKIAl2bV9wYWdlX3QJZmlyc3RfcGFnZTsKIAlzdHJ1Y3Qgdm1fZnJlZWxpc3Qg KCpmcmVlX3F1ZXVlcylbVk1fTkZSRUVQT09MXVtWTV9ORlJFRU9SREVSXTsKKwlpbnQJCWZsaW5k OwogfTsKIAogc3RhdGljIHN0cnVjdCB2bV9waHlzX3NlZyB2bV9waHlzX3NlZ3NbVk1fUEhZU1NF R19NQVhdOwpAQCAtMTg4LDYgKzE4OSw3IEBACiAJc2VnID0gJnZtX3BoeXNfc2Vnc1t2bV9waHlz X25zZWdzKytdOwogCXNlZy0+c3RhcnQgPSBzdGFydDsKIAlzZWctPmVuZCA9IGVuZDsKKwlzZWct PmZsaW5kID0gZmxpbmQ7CiAjaWZkZWYgVk1fUEhZU1NFR19TUEFSU0UKIAlzZWctPmZpcnN0X3Bh Z2UgPSAmdm1fcGFnZV9hcnJheVtwYWdlc107CiAjZWxzZQpAQCAtNTk1LDcgKzU5Nyw4IEBACiAJ dm1fb2JqZWN0X3QgbV9vYmplY3Q7CiAJdm1fcGFkZHJfdCBwYSwgcGFfbGFzdCwgc2l6ZTsKIAl2 bV9wYWdlX3QgZGVmZXJyZWRfdmRyb3BfbGlzdCwgbSwgbV9yZXQ7Ci0JaW50IGZsaW5kLCBpLCBv aW5kLCBvcmRlciwgcGluZDsKKwlpbnQgZmxpbmQsIGksIG9pbmQsIG9yZGVyLCBwaW5kLCBzZWdp bmQ7CisJaW50IGZsX2dvb2RbVk1fTkZSRUVMSVNUXTsKIAogCXNpemUgPSBucGFnZXMgPDwgUEFH RV9TSElGVDsKIAlLQVNTRVJUKHNpemUgIT0gMCwKQEAgLTYwNywxMSArNjEwLDIyIEBACiAJZGVm ZXJyZWRfdmRyb3BfbGlzdCA9IE5VTEw7CiAJLyogQ29tcHV0ZSB0aGUgcXVldWUgdGhhdCBpcyB0 aGUgYmVzdCBmaXQgZm9yIG5wYWdlcy4gKi8KIAlmb3IgKG9yZGVyID0gMDsgKDEgPDwgb3JkZXIp IDwgbnBhZ2VzOyBvcmRlcisrKTsKKwkvKiBDb21wdXRlIHRoZSBmcmVlbGlzdHMgdGhhdCBzaG91 bGQgYmUgc2VhcmNoZWQgKi8KKwlmb3IgKGZsaW5kID0gMDsgZmxpbmQgPCB2bV9uZnJlZWxpc3Rz OyBmbGluZCsrKQorCQlmbF9nb29kW2ZsaW5kXSA9IDA7CisJZm9yIChzZWdpbmQgPSAwOyBzZWdp bmQgPCB2bV9waHlzX25zZWdzOyBzZWdpbmQrKykgeworCQlzZWcgPSAmdm1fcGh5c19zZWdzW3Nl Z2luZF07CisJCWlmIChsb3cgPCBzZWctPmVuZCAmJiBoaWdoID4gc2VnLT5zdGFydCkKKwkJCWZs X2dvb2Rbc2VnLT5mbGluZF0rKzsKKwl9CiAJbXR4X2xvY2soJnZtX3BhZ2VfcXVldWVfZnJlZV9t dHgpOwogI2lmIFZNX05SRVNFUlZMRVZFTCA+IDAKIHJldHJ5OgogI2VuZGlmCiAJZm9yIChmbGlu ZCA9IDA7IGZsaW5kIDwgdm1fbmZyZWVsaXN0czsgZmxpbmQrKykgeworCQlpZiAoZmxfZ29vZFtm bGluZF0gPT0gMCkKKwkJCWNvbnRpbnVlOworCiAJCWZvciAob2luZCA9IG1pbihvcmRlciwgVk1f TkZSRUVPUkRFUiAtIDEpOyBvaW5kIDwgVk1fTkZSRUVPUkRFUjsgb2luZCsrKSB7CiAJCQlmb3Ig KHBpbmQgPSAwOyBwaW5kIDwgVk1fTkZSRUVQT09MOyBwaW5kKyspIHsKIAkJCQlmbCA9IHZtX3Bo eXNfZnJlZV9xdWV1ZXNbZmxpbmRdW3BpbmRdOwo= --0016364edd086c06ef04889cd7fe-- From owner-freebsd-mips@FreeBSD.ORG Wed Jun 9 19:57:08 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E9531065677; Wed, 9 Jun 2010 19:57:08 +0000 (UTC) (envelope-from phcoder@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 85EF98FC13; Wed, 9 Jun 2010 19:57:07 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so1683348fga.13 for ; Wed, 09 Jun 2010 12:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=Q3yjijyfFEHQgCLNIrFE433/5aypz1ZE4x4r40j88ds=; b=TNdfajibw6XPn+GjsF42mNFZPCan+uqxE0GnZ8hRNUKuXi6WNAthUkTKIsWkJupBvr wHUst8E/bcWy0O9+oA6ui+sYfe5lIx2eJKVrcPsFtFs73DIuhAUIkNeHI/KoJ4LkjHz+ yPn7aa1Auig/h4BgTb+U0Bdy952wS+SQp10Cg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=l1Cf1nvr8F42anu+7ao5aX3VsI+UDRzmJ2hLeaeffnI3apj40uanlQpd75OC1xzSMn aYyVULPL4K+btDLWN8XtIvQ36ZAntAqv/Ik7My9Bpy34/kiEr22MBLn2HhFnHBpPdUuR a+foE9c3DCF2Nntexw1r83fq+KFT9iGEDERqM= Received: by 10.204.148.69 with SMTP id o5mr3064879bkv.188.1276113426447; Wed, 09 Jun 2010 12:57:06 -0700 (PDT) Received: from debian.bg45.phnet (gprs41.swisscom-mobile.ch [193.247.250.41]) by mx.google.com with ESMTPS id z20sm30949556bkx.15.2010.06.09.12.57.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Jun 2010 12:57:04 -0700 (PDT) Message-ID: <4C0FF206.308@gmail.com> Date: Wed, 09 Jun 2010 21:56:54 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4 MIME-Version: 1.0 To: Juli Mallett References: <4C0C1EF4.9070609@gmail.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig87CCC24E7B05619012BCA45E" Cc: soc-students@freebsd.org, freebsd-mips@freebsd.org Subject: Re: Weekly report on Yeeloong progress X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 19:57:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig87CCC24E7B05619012BCA45E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/07/2010 12:30 AM, Juli Mallett wrote: > 2010/6/6 Vladimir '=CF=86-coder/phcoder' Serbinenko = : > =20 >> Hello, as my duty I report the current progress. >> Serial console is working >> Debugger including backtrace is apparently working >> Now it's based on octeon branch which has greatly improved 64-bit sup= port. >> =20 > Great stuff! Keep up the good work. > > =20 Thanks >> - Checking TLB format. TLB format on loongson is slightly different th= an >> on mips FreeBSD works on but it shouldn't have been a problem. After >> fixing TLB entries nothing changed >> =20 > How is it different? Do you mean that you need to use 64-bit PTEs > (did you get my E-Mail about that?) or something else? > > =20 Yes I did. It's documented on pages 56, 58 and 61 of Loongson 2F manual. The difference is in wider PFN and PageMask and presence of no-execute bit. If all unknown bit are zeroed it shouldn't be any problem. But it will be useful in future for sure. > Juli. > > =20 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig87CCC24E7B05619012BCA45E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAkwP8gYACgkQNak7dOguQglx2QD/YpeFfIPLyzLIY51reIZSky+r e8GTWue8CnO7t/S4WmsA+wZ7yyvl7EwyoMcqhkIifeIe5x5KQKXcu0/a9oSiY5Fl =dEkr -----END PGP SIGNATURE----- --------------enig87CCC24E7B05619012BCA45E-- From owner-freebsd-mips@FreeBSD.ORG Wed Jun 9 21:40:10 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3547E106566B for ; Wed, 9 Jun 2010 21:40:10 +0000 (UTC) (envelope-from gofdm-freebsd-mips@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id E5EEE8FC0A for ; Wed, 9 Jun 2010 21:40:09 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OMSlj-00025P-No for freebsd-mips@freebsd.org; Wed, 09 Jun 2010 23:25:03 +0200 Received: from odyssee.gentiane.org ([80.65.224.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Jun 2010 23:25:03 +0200 Received: from miod by odyssee.gentiane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Jun 2010 23:25:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-mips@freebsd.org connect(): No such file or directory From: Miod Vallat Date: Wed, 9 Jun 2010 20:44:06 +0000 (UTC) Organization: Forez Luddite Technologies Lines: 9 Message-ID: References: <4C0C1EF4.9070609@gmail.com> <4C0FF206.308@gmail.com> X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: odyssee.gentiane.org User-Agent: slrn/0.9.8.1 (OpenBSD) Subject: Re: Weekly report on Yeeloong progress X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 21:40:10 -0000 > Yes I did. It's documented on pages 56, 58 and 61 of Loongson 2F manual. > The difference is in wider PFN and PageMask and presence of no-execute > bit. If all unknown bit are zeroed it shouldn't be any problem. But it > will be useful in future for sure. I am not sure the NX bit is actually implemented in the 2F. It sounds like a leftover of the 2E documentation, and unfortunately neither the 2E nor the 2F documentation mention what kind of exception is generated at ITLB refill time when the TLB entry has the NX bit set. From owner-freebsd-mips@FreeBSD.ORG Fri Jun 11 11:14:58 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD9131065670 for ; Fri, 11 Jun 2010 11:14:58 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5C9FE8FC15 for ; Fri, 11 Jun 2010 11:14:58 +0000 (UTC) Received: by vws1 with SMTP id 1so1268839vws.13 for ; Fri, 11 Jun 2010 04:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=IgLhbNeodrjgtf8NODb/e+XjVNSyQtTGnaEN/H32IDo=; b=cS2tZnAsmvSMqKgYnmm0Ph8lP5NeDqpR7/qv58C5kGHQ/hVOxTVMC6VKKt17wTzgos G4nGARMJdS9qGlBN4/qotYs/RmVRzEBGHQ7Ms4Eg8tk8SflZlJdhA2WZ0Ys1UAPl4wCU eExDektL2TJRhFeF8UH1uZ05NX8hIiRpka/OY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=s3Mvrd9i8KsdT/1lFgTOWzzDEh3afrtua0PWncZIMspqCDjhhrfwrWTgr9Q4t/mXwt SmThaJSfpWbDBMjzbYw11IDPWo8NI08+lZHqfgTBDClV32DJ1NowOFL75TaIPcdxxnDA XqNNavpR530ezgKA31d8I5x3VAZkOpD9aQPkQ= MIME-Version: 1.0 Received: by 10.224.18.36 with SMTP id u36mr489138qaa.64.1276254897069; Fri, 11 Jun 2010 04:14:57 -0700 (PDT) Received: by 10.224.54.71 with HTTP; Fri, 11 Jun 2010 04:14:56 -0700 (PDT) In-Reply-To: References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> <4C0DE424.9080601@cs.rice.edu> Date: Fri, 11 Jun 2010 16:44:56 +0530 Message-ID: From: "Jayachandran C." To: Alan Cox Content-Type: multipart/mixed; boundary=00c09f899574c85e660488bf3fcf Cc: Kostik Belousov , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 11:14:58 -0000 --00c09f899574c85e660488bf3fcf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 9, 2010 at 11:41 PM, Jayachandran C. wrote: > On Wed, Jun 9, 2010 at 11:20 AM, Jayachandran C. > wrote: >> On Wed, Jun 9, 2010 at 3:01 AM, Jayachandran C. >> wrote: >>> On Tue, Jun 8, 2010 at 12:03 PM, Alan Cox wrote: >>>> >>>> VM_FREEPOOL_DIRECT is used by at least amd64 and ia64 for page table p= ages >>>> and small kernel memory allocations. =A0Unlike mips, these machines do= n't have >>>> MMU support for a direct map. =A0Their direct maps are just a range of >>>> mappings in the regular (kernel) page table. =A0So, unlike mips, acces= ses >>>> through their direct map may still miss in the TLB and require a page = table >>>> walk. =A0VM_FREEPOOL_* is a way to increase the physical locality (or >>>> clustering) of page allocations, so that, for example, page table page >>>> accesses by the pmap on amd64 are less likely to miss in the TLB. =A0H= owever, >>>> it doesn't place a hard restriction on the range of physical addresses= that >>>> will be used, which you need for mips. >>>> >>>> The impact of this clustering can be significant. =A0For example, on a= md64 we >>>> use 2MB page mappings to implement the direct map. =A0However, old Opt= erons >>>> only had 8 data TLB entries for 2MB page mappings. =A0For a uniprocess= or >>>> kernel running on such an Opteron, I measured an 18% reduction in syst= em >>>> time during a buildworld with the introduction of VM_FREEPOOL_DIRECT. = =A0(See >>>> the commit logs for vm/vm_phys.c and the comment that precedes the >>>> VM_NFREEORDER definition on amd64.) >>>> >>>> Until such time as superpage support is ported to mips from the amd64/= i386 >>>> pmaps, I don't think there is a point in having more than one VM_FREEP= OOL_* >>>> on mips. =A0And then, the point would be to reduce fragmentation of th= e >>>> physical memory that could be caused by small allocations, such as pag= e >>>> table pages. >>> >>> Thanks for the detailed explanation. >>> >>> Also, after looking at the code again, =A0I think vm_phys_alloc_contig(= ) >>> can optimized not to look into segments which lie outside the area of >>> interest. The patch is: >> [...] >>> This change, along with the vmparam.h changes for HIGHMEM, I think we >>> should be able to use =A0vm_phys_alloc_contig() for page table pages (o= r >>> have I again missed something fundamental?). >> >> That patch was obviously wrong - many segments can map to a freelist >> as the comment right above my change noted. >> >> But the idea of eliminating freelists for which all the segments are >> outside (low,high) may still be useful, will look at this some more. > > I have attached a patch (also at > http://people.freebsd.org/~jchandra/pmap-with-HIGHMEM-freelist.patch) > which reverts most of the changes I did to convert the page table page > allocation to use UMA zone, and replaces it with an implementation > using vm_phys_alloc_contig() and vm_contig_grow_cache(). This creates > a new HIGHMEM freelist for mips for memory outside the KSEG0 area, and > makes a few changes in vm_phys_alloc_contig() to skip freelists for > which all the segments fall outside the address range requested. > > With this the buildworld perf on MIPS is similar to what I got with > the older code with zones. > > If this approach is okay, I will do another round of > testing(buildworld passes, but I haven't really tested the case where > grow_cache is called). =A0If the changes are not okay, I will add > another page allocator which takes freelist as argument as you had > suggested earlier, instead of the vm_phys_alloc_contig() changes. Here is the alternative patch (http://people.freebsd.org/~jchandra/pmap-with-HIGHMEM-freelist-alternate.p= atch). In this all the pmap.c changes are almost exactly same as the patch above, except that the call to vm_phys_alloc_contig() to allocate page table pages has been replaced with a new function vm_phys_page_alloc(). The patch also has changes in sys/vm/vm_phys.c to: - add vm_phys_page_alloc(int flind, int pool, int order) to allocate a page from a freelist - add vm_phys_alloc_freelist_pages(int flind, int pool, int order) - which will be called by vm_phys_page_alloc() and vm_phys_alloc_pages(), to dequeue a page of correct pool and order. - move out page initialization code of vm_phys_alloc_contig() to vm_page_alloc_init(), and use it in both vm_phys_page_alloc and vm_phys_alloc_contig I have been running buildworld on this for a few hours now (with code to add random alloc failuers), and it seems to hold up. Let me know you comments. Thanks, JC. --00c09f899574c85e660488bf3fcf Content-Type: text/plain; charset=US-ASCII; name="pmap-with-HIGHMEM-freelist-alternate.patch" Content-Disposition: attachment; filename="pmap-with-HIGHMEM-freelist-alternate.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gaax0day1 SW5kZXg6IHN5cy9taXBzL2luY2x1ZGUvdm1wYXJhbS5oCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9taXBz L2luY2x1ZGUvdm1wYXJhbS5oCShyZXZpc2lvbiAyMDg4OTApCisrKyBzeXMvbWlwcy9pbmNsdWRl L3ZtcGFyYW0uaAkod29ya2luZyBjb3B5KQpAQCAtMTAzLDggKzEwMyw5IEBACiAjZGVmaW5lCVZN X01BWFVTRVJfQUREUkVTUwkoKHZtX29mZnNldF90KTB4ODAwMDAwMDApCiAjZGVmaW5lCVZNX01B WF9NTUFQX0FERFIJVk1fTUFYVVNFUl9BRERSRVNTCiAKLSNkZWZpbmUJVk1fTUlOX0tFUk5FTF9B RERSRVNTCQkoKHZtX29mZnNldF90KTB4QzAwMDAwMDApCi0jZGVmaW5lCVZNX01BWF9LRVJORUxf QUREUkVTUwkJKCh2bV9vZmZzZXRfdCkweEZGRkZDMDAwKQorI2RlZmluZQlWTV9NSU5fS0VSTkVM X0FERFJFU1MJKCh2bV9vZmZzZXRfdCkweEMwMDAwMDAwKQorI2RlZmluZQlWTV9NQVhfS0VSTkVM X0FERFJFU1MJKCh2bV9vZmZzZXRfdCkweEZGRkZDMDAwKQorI2RlZmluZQlWTV9ISUdITUVNX0FE RFJFU1MJKCh2bV9wYWRkcl90KTB4MjAwMDAwMDApCiAjaWYgMAogI2RlZmluZQlLRVJOQkFTRQkJ KFZNX01JTl9LRVJORUxfQUREUkVTUykKICNlbHNlCkBAIC0xNjgsMTMgKzE2OSwxNSBAQAogI2Rl ZmluZQlWTV9GUkVFUE9PTF9ESVJFQ1QJMQogCiAvKgotICogd2Ugc3VwcG9ydCAxIGZyZWUgbGlz dDoKKyAqIHdlIHN1cHBvcnQgMiBmcmVlIGxpc3RzOgogICoKLSAqCS0gREVGQVVMVCBmb3IgYWxs IHN5c3RlbXMKKyAqCS0gREVGQVVMVCBmb3IgZGlyZWN0IG1hcHBlZCAoS1NFRzApIHBhZ2VzCisg KgktIEhJR0hNRU0gZm9yIG90aGVyIHBhZ2VzIAogICovCiAKLSNkZWZpbmUJVk1fTkZSRUVMSVNU CQkxCi0jZGVmaW5lCVZNX0ZSRUVMSVNUX0RFRkFVTFQJMAorI2RlZmluZQlWTV9ORlJFRUxJU1QJ CTIKKyNkZWZpbmUJVk1fRlJFRUxJU1RfREVGQVVMVAkxCisjZGVmaW5lCVZNX0ZSRUVMSVNUX0hJ R0hNRU0JMAogCiAvKgogICogVGhlIGxhcmdlc3QgYWxsb2NhdGlvbiBzaXplIGlzIDFNQi4KSW5k ZXg6IHN5cy9taXBzL21pcHMvcG1hcC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9taXBzL21pcHMvcG1h cC5jCShyZXZpc2lvbiAyMDg4OTApCisrKyBzeXMvbWlwcy9taXBzL3BtYXAuYwkod29ya2luZyBj b3B5KQpAQCAtMTg0LDggKzE4NCw2IEBACiBzdGF0aWMgaW50IGluaXRfcHRlX3Byb3Qodm1fb2Zm c2V0X3QgdmEsIHZtX3BhZ2VfdCBtLCB2bV9wcm90X3QgcHJvdCk7CiBzdGF0aWMgdm9pZCBwbWFw X1RMQl9pbnZhbGlkYXRlX2tlcm5lbCh2bV9vZmZzZXRfdCk7CiBzdGF0aWMgdm9pZCBwbWFwX1RM Ql91cGRhdGVfa2VybmVsKHZtX29mZnNldF90LCBwdF9lbnRyeV90KTsKLXN0YXRpYyB2bV9wYWdl X3QgcG1hcF9hbGxvY19wdGVfcGFnZShwbWFwX3QsIHVuc2lnbmVkIGludCwgaW50LCB2bV9vZmZz ZXRfdCAqKTsKLXN0YXRpYyB2b2lkIHBtYXBfcmVsZWFzZV9wdGVfcGFnZSh2bV9wYWdlX3QpOwog CiAjaWZkZWYgU01QCiBzdGF0aWMgdm9pZCBwbWFwX2ludmFsaWRhdGVfcGFnZV9hY3Rpb24odm9p ZCAqYXJnKTsKQEAgLTE5MywxMCArMTkxLDYgQEAKIHN0YXRpYyB2b2lkIHBtYXBfdXBkYXRlX3Bh Z2VfYWN0aW9uKHZvaWQgKmFyZyk7CiAjZW5kaWYKIAotc3RhdGljIHZvaWQgcG1hcF9wdHBnem9u ZV9kdG9yKHZvaWQgKm1lbSwgaW50IHNpemUsIHZvaWQgKmFyZyk7Ci1zdGF0aWMgdm9pZCAqcG1h cF9wdHBnem9uZV9hbGxvY2YodW1hX3pvbmVfdCwgaW50LCB1X2ludDhfdCAqLCBpbnQpOwotc3Rh dGljIHVtYV96b25lX3QgcHRwZ3pvbmU7Ci0KIHN0cnVjdCBsb2NhbF9zeXNtYXBzIHsKIAlzdHJ1 Y3QgbXR4IGxvY2s7CiAJdm1fb2Zmc2V0X3QgYmFzZTsKQEAgLTMyOSw3ICszMjMsNyBAQAogfQog CiAvKgotICoJQm9vdHN0cmFwIHRoZSBzeXN0ZW0gZW5vdWdoIHRvIHJ1biB3aXRoIHZpcnR1YWwg bWVtb3J5LiAgVGhpcworICogQm9vdHN0cmFwIHRoZSBzeXN0ZW0gZW5vdWdoIHRvIHJ1biB3aXRo IHZpcnR1YWwgbWVtb3J5LiAgVGhpcwogICogYXNzdW1lcyB0aGF0IHRoZSBwaHlzX2F2YWlsIGFy cmF5IGhhcyBiZWVuIGluaXRpYWxpemVkLgogICovCiB2b2lkCkBAIC01MzUsMTAgKzUyOSw2IEBA CiAJcHZfZW50cnlfbWF4ID0gUE1BUF9TSFBHUEVSUFJPQyAqIG1heHByb2MgKyBjbnQudl9wYWdl X2NvdW50OwogCXB2X2VudHJ5X2hpZ2hfd2F0ZXIgPSA5ICogKHB2X2VudHJ5X21heCAvIDEwKTsK IAl1bWFfem9uZV9zZXRfb2JqKHB2em9uZSwgJnB2em9uZV9vYmosIHB2X2VudHJ5X21heCk7Ci0K LQlwdHBnem9uZSA9IHVtYV96Y3JlYXRlKCJQVCBFTlRSWSIsIFBBR0VfU0laRSwgTlVMTCwgcG1h cF9wdHBnem9uZV9kdG9yLAotCSAgICBOVUxMLCBOVUxMLCBQQUdFX1NJWkUgLSAxLCBVTUFfWk9O RV9OT0ZSRUUgfCBVTUFfWk9ORV9aSU5JVCk7Ci0JdW1hX3pvbmVfc2V0X2FsbG9jZihwdHBnem9u ZSwgcG1hcF9wdHBnem9uZV9hbGxvY2YpOwogfQogCiAvKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqCkBAIC04ODUsMTIgKzg3NSw4IEBACiAJLyoKIAkg KiBJZiB0aGUgcGFnZSBpcyBmaW5hbGx5IHVud2lyZWQsIHNpbXBseSBmcmVlIGl0LgogCSAqLwor CXZtX3BhZ2VfZnJlZV96ZXJvKG0pOwogCWF0b21pY19zdWJ0cmFjdF9pbnQoJmNudC52X3dpcmVf Y291bnQsIDEpOwotCVBNQVBfVU5MT0NLKHBtYXApOwotCXZtX3BhZ2VfdW5sb2NrX3F1ZXVlcygp OwotCXBtYXBfcmVsZWFzZV9wdGVfcGFnZShtKTsKLQl2bV9wYWdlX2xvY2tfcXVldWVzKCk7Ci0J UE1BUF9MT0NLKHBtYXApOwogCXJldHVybiAoMSk7CiB9CiAKQEAgLTk0OSw5NiArOTM1LDM1IEBA CiAJYnplcm8oJnBtYXAtPnBtX3N0YXRzLCBzaXplb2YgcG1hcC0+cG1fc3RhdHMpOwogfQogCisK IHN0YXRpYyB2b2lkCi1wbWFwX3B0cGd6b25lX2R0b3Iodm9pZCAqbWVtLCBpbnQgc2l6ZSwgdm9p ZCAqYXJnKQorcG1hcF9ncm93X3B0ZV9wYWdlX2NhY2hlKGludCB3YWl0KQogewotI2lmZGVmIElO VkFSSUFOVFMKLQlzdGF0aWMgY2hhciB6ZXJvcGFnZVtQQUdFX1NJWkVdOwotCi0JS0FTU0VSVChz aXplID09IFBBR0VfU0laRSwKLQkJKCJwbWFwX3B0cGd6b25lX2R0b3I6IGludmFsaWQgc2l6ZSAl ZCIsIHNpemUpKTsKLQlLQVNTRVJUKGJjbXAobWVtLCB6ZXJvcGFnZSwgUEFHRV9TSVpFKSA9PSAw LAotCQkoInBtYXBfcHRwZ3pvbmVfZHRvcjogZnJlZWluZyBhIG5vbi16ZXJvZWQgcGFnZSIpKTsK LSNlbmRpZgorCXByaW50ZigiWyVzXSB3YWl0ICV4XG4iLCBfX2Z1bmNfXywgd2FpdCk7CisJdm1f Y29udGlnX2dyb3dfY2FjaGUoMywgMCwgTUlQU19LU0VHMF9MQVJHRVNUX1BIWVMpOwogfQogCi1z dGF0aWMgdm9pZCAqCi1wbWFwX3B0cGd6b25lX2FsbG9jZih1bWFfem9uZV90IHpvbmUsIGludCBi eXRlcywgdV9pbnQ4X3QgKmZsYWdzLCBpbnQgd2FpdCkKLXsKLQl2bV9wYWdlX3QgbTsKLQl2bV9w YWRkcl90IHBhZGRyOwotCWludCB0cmllczsKLQkKLQlLQVNTRVJUKGJ5dGVzID09IFBBR0VfU0la RSwKLQkJKCJwbWFwX3B0cGd6b25lX2FsbG9jZjogaW52YWxpZCBhbGxvY2F0aW9uIHNpemUgJWQi LCBieXRlcykpOwogCi0JKmZsYWdzID0gVU1BX1NMQUJfUFJJVjsKLQl0cmllcyA9IDA7Ci1yZXRy eToKLQltID0gdm1fcGh5c19hbGxvY19jb250aWcoMSwgMCwgTUlQU19LU0VHMF9MQVJHRVNUX1BI WVMsCi0JICAgIFBBR0VfU0laRSwgUEFHRV9TSVpFKTsKLQlpZiAobSA9PSBOVUxMKSB7Ci0gICAg ICAgICAgICAgICAgaWYgKHRyaWVzIDwgKCh3YWl0ICYgTV9OT1dBSVQpICE9IDAgPyAxIDogMykp IHsKLQkJCXZtX2NvbnRpZ19ncm93X2NhY2hlKHRyaWVzLCAwLCBNSVBTX0tTRUcwX0xBUkdFU1Rf UEhZUyk7Ci0JCQl0cmllcysrOwotCQkJZ290byByZXRyeTsKLQkJfSBlbHNlCi0JCQlyZXR1cm4g KE5VTEwpOwotCX0KLQotCXBhZGRyID0gVk1fUEFHRV9UT19QSFlTKG0pOwotCXJldHVybiAoKHZv aWQgKilNSVBTX1BIWVNfVE9fS1NFRzAocGFkZHIpKTsKLX0JCi0KIHN0YXRpYyB2bV9wYWdlX3QK LXBtYXBfYWxsb2NfcHRlX3BhZ2UocG1hcF90IHBtYXAsIHVuc2lnbmVkIGludCBpbmRleCwgaW50 IHdhaXQsIHZtX29mZnNldF90ICp2YXApCitwbWFwX2FsbG9jX3B0ZV9wYWdlKHVuc2lnbmVkIGlu dCBpbmRleCwgaW50IHdhaXQpCiB7Ci0Jdm1fcGFkZHJfdCBwYWRkcjsKLQl2b2lkICp2YTsKIAl2 bV9wYWdlX3QgbTsKLQlpbnQgbG9ja2VkOwogCi0JbG9ja2VkID0gbXR4X293bmVkKCZwbWFwLT5w bV9tdHgpOwotCWlmIChsb2NrZWQpIHsKLQkJbXR4X2Fzc2VydCgmdm1fcGFnZV9xdWV1ZV9tdHgs IE1BX09XTkVEKTsKLQkJUE1BUF9VTkxPQ0socG1hcCk7Ci0JCXZtX3BhZ2VfdW5sb2NrX3F1ZXVl cygpOwotCX0KLQl2YSA9IHVtYV96YWxsb2MocHRwZ3pvbmUsIHdhaXQpOwotCWlmIChsb2NrZWQp IHsKLQkJdm1fcGFnZV9sb2NrX3F1ZXVlcygpOwotCQlQTUFQX0xPQ0socG1hcCk7Ci0JfQotCWlm ICh2YSA9PSBOVUxMKQorCW0gPSB2bV9waHlzX3BhZ2VfYWxsb2MoVk1fRlJFRUxJU1RfREVGQVVM VCwgVk1fRlJFRVBPT0xfREVGQVVMVCwwKTsKKwlpZiAobSA9PSBOVUxMKQogCQlyZXR1cm4gKE5V TEwpOwogCi0JcGFkZHIgPSBNSVBTX0tTRUcwX1RPX1BIWVModmEpOwotCW0gPSBQSFlTX1RPX1ZN X1BBR0UocGFkZHIpOwotCQotCWlmICghbG9ja2VkKQotCQl2bV9wYWdlX2xvY2tfcXVldWVzKCk7 CisJaWYgKChtLT5mbGFncyAmIFBHX1pFUk8pID09IDApCisJCXBtYXBfemVyb19wYWdlKG0pOwor CiAJbS0+cGluZGV4ID0gaW5kZXg7CiAJbS0+dmFsaWQgPSBWTV9QQUdFX0JJVFNfQUxMOwotCW0t PndpcmVfY291bnQgPSAxOwotCWlmICghbG9ja2VkKQotCQl2bV9wYWdlX3VubG9ja19xdWV1ZXMo KTsKLQogCWF0b21pY19hZGRfaW50KCZjbnQudl93aXJlX2NvdW50LCAxKTsKLQkqdmFwID0gKHZt X29mZnNldF90KXZhOworCW0tPndpcmVfY291bnQgPSAxOwogCXJldHVybiAobSk7CiB9CiAKLXN0 YXRpYyB2b2lkCi1wbWFwX3JlbGVhc2VfcHRlX3BhZ2Uodm1fcGFnZV90IG0pCi17Ci0Jdm9pZCAq dmE7Ci0Jdm1fcGFkZHJfdCBwYWRkcjsKIAotCXBhZGRyID0gVk1fUEFHRV9UT19QSFlTKG0pOwot CXZhID0gKHZvaWQgKilNSVBTX1BIWVNfVE9fS1NFRzAocGFkZHIpOwotCXVtYV96ZnJlZShwdHBn em9uZSwgdmEpOwotfQotCiAvKgogICogSW5pdGlhbGl6ZSBhIHByZWFsbG9jYXRlZCBhbmQgemVy b2VkIHBtYXAgc3RydWN0dXJlLAogICogc3VjaCBhcyBvbmUgaW4gYSB2bXNwYWNlIHN0cnVjdHVy ZS4KQEAgLTEwNTUsMTAgKzk4MCwxMCBAQAogCS8qCiAJICogYWxsb2NhdGUgdGhlIHBhZ2UgZGly ZWN0b3J5IHBhZ2UKIAkgKi8KLQlwdGRwZyA9IHBtYXBfYWxsb2NfcHRlX3BhZ2UocG1hcCwgTlVT RVJQR1RCTFMsIE1fV0FJVE9LLCAmcHRkdmEpOwotCWlmIChwdGRwZyA9PSBOVUxMKQotCQlyZXR1 cm4gKDApOworCXdoaWxlICgocHRkcGcgPSBwbWFwX2FsbG9jX3B0ZV9wYWdlKE5VU0VSUEdUQkxT LCBNX1dBSVRPSykpID09IE5VTEwpCisJICAgICAgIHBtYXBfZ3Jvd19wdGVfcGFnZV9jYWNoZShN X1dBSVRPSyk7CiAKKwlwdGR2YSA9IE1JUFNfUEhZU19UT19LU0VHMChWTV9QQUdFX1RPX1BIWVMo cHRkcGcpKTsKIAlwbWFwLT5wbV9zZWd0YWIgPSAocGRfZW50cnlfdCAqKXB0ZHZhOwogCXBtYXAt PnBtX2FjdGl2ZSA9IDA7CiAJcG1hcC0+cG1fcHRwaGludCA9IE5VTEw7CkBAIC0xMDg5LDE1ICsx MDE0LDI4IEBACiAJLyoKIAkgKiBGaW5kIG9yIGZhYnJpY2F0ZSBhIG5ldyBwYWdldGFibGUgcGFn ZQogCSAqLwotCW0gPSBwbWFwX2FsbG9jX3B0ZV9wYWdlKHBtYXAsIHB0ZXBpbmRleCwgZmxhZ3Ms ICZwdGV2YSk7Ci0JaWYgKG0gPT0gTlVMTCkKKwlpZiAoKG0gPSBwbWFwX2FsbG9jX3B0ZV9wYWdl KHB0ZXBpbmRleCwgZmxhZ3MpKSA9PSBOVUxMKSB7CisJCWlmIChmbGFncyAmIE1fV0FJVE9LKSB7 CisJCQlQTUFQX1VOTE9DSyhwbWFwKTsKKwkJCXZtX3BhZ2VfdW5sb2NrX3F1ZXVlcygpOworCQkJ cG1hcF9ncm93X3B0ZV9wYWdlX2NhY2hlKGZsYWdzKTsKKwkJCXZtX3BhZ2VfbG9ja19xdWV1ZXMo KTsKKwkJCVBNQVBfTE9DSyhwbWFwKTsKKwkJfQorCisJCS8qCisJCSAqIEluZGljYXRlIHRoZSBu ZWVkIHRvIHJldHJ5LglXaGlsZSB3YWl0aW5nLCB0aGUgcGFnZQorCQkgKiB0YWJsZSBwYWdlIG1h eSBoYXZlIGJlZW4gYWxsb2NhdGVkLgorCQkgKi8KIAkJcmV0dXJuIChOVUxMKTsKKwl9CiAKIAkv KgogCSAqIE1hcCB0aGUgcGFnZXRhYmxlIHBhZ2UgaW50byB0aGUgcHJvY2VzcyBhZGRyZXNzIHNw YWNlLCBpZiBpdAogCSAqIGlzbid0IGFscmVhZHkgdGhlcmUuCiAJICovCiAKKwlwdGV2YSA9IE1J UFNfUEhZU19UT19LU0VHMChWTV9QQUdFX1RPX1BIWVMobSkpOwogCXBtYXAtPnBtX3N0YXRzLnJl c2lkZW50X2NvdW50Kys7CiAJcG1hcC0+cG1fc2VndGFiW3B0ZXBpbmRleF0gPSAocGRfZW50cnlf dClwdGV2YTsKIApAQCAtMTE5Myw3ICsxMTMxLDcgQEAKIAogCXB0ZHBnLT53aXJlX2NvdW50LS07 CiAJYXRvbWljX3N1YnRyYWN0X2ludCgmY250LnZfd2lyZV9jb3VudCwgMSk7Ci0JcG1hcF9yZWxl YXNlX3B0ZV9wYWdlKHB0ZHBnKTsKKwl2bV9wYWdlX2ZyZWVfemVybyhwdGRwZyk7CiAJUE1BUF9M T0NLX0RFU1RST1kocG1hcCk7CiB9CiAKQEAgLTEyMDMsNyArMTE0MSw2IEBACiB2b2lkCiBwbWFw X2dyb3drZXJuZWwodm1fb2Zmc2V0X3QgYWRkcikKIHsKLQl2bV9vZmZzZXRfdCBwYWdldmE7CiAJ dm1fcGFnZV90IG5rcGc7CiAJcHRfZW50cnlfdCAqcHRlOwogCWludCBpOwpAQCAtMTIzOCwxMyAr MTE3NSwxMyBAQAogCQkvKgogCQkgKiBUaGlzIGluZGV4IGlzIGJvZ3VzLCBidXQgb3V0IG9mIHRo ZSB3YXkKIAkJICovCi0JCW5rcGcgPSBwbWFwX2FsbG9jX3B0ZV9wYWdlKGtlcm5lbF9wbWFwLCBu a3B0LCBNX05PV0FJVCwgJnBhZ2V2YSk7CisJCW5rcGcgPSBwbWFwX2FsbG9jX3B0ZV9wYWdlKG5r cHQsIE1fTk9XQUlUKTsKIAogCQlpZiAoIW5rcGcpCiAJCQlwYW5pYygicG1hcF9ncm93a2VybmVs OiBubyBtZW1vcnkgdG8gZ3JvdyBrZXJuZWwiKTsKIAogCQlua3B0Kys7Ci0JCXB0ZSA9IChwdF9l bnRyeV90ICopcGFnZXZhOworCQlwdGUgPSAocHRfZW50cnlfdCAqKU1JUFNfUEhZU19UT19LU0VH MChWTV9QQUdFX1RPX1BIWVMobmtwZykpOwogCQlzZWd0YWJfcGRlKGtlcm5lbF9zZWdtYXAsIGtl cm5lbF92bV9lbmQpID0gKHBkX2VudHJ5X3QpcHRlOwogCiAJCS8qCkluZGV4OiBzeXMvdm0vdm1f cGh5cy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHN5cy92bS92bV9waHlzLmMJKHJldmlzaW9uIDIwODg5MCkK KysrIHN5cy92bS92bV9waHlzLmMJKHdvcmtpbmcgY29weSkKQEAgLTkzLDcgKzkzLDEwIEBACiBz dGF0aWMgaW50IHZtX3BoeXNfcGFkZHJfdG9fc2VnaW5kKHZtX3BhZGRyX3QgcGEpOwogc3RhdGlj IHZvaWQgdm1fcGh5c19zcGxpdF9wYWdlcyh2bV9wYWdlX3QgbSwgaW50IG9pbmQsIHN0cnVjdCB2 bV9mcmVlbGlzdCAqZmwsCiAgICAgaW50IG9yZGVyKTsKK3N0YXRpYyB2bV9wYWdlX3Qgdm1fcGh5 c19hbGxvY19mcmVlbGlzdF9wYWdlcyhpbnQgZmxpbmQsIGludCBwb29sLCBpbnQgb3JkZXIpOwor c3RhdGljIHZvaWQgdm1fcGFnZV9hbGxvY19pbml0KHZtX3BhZ2VfdCBtLCBzdHJ1Y3Qgdm5vZGUg Kipkcm9wKTsKIAorCiAvKgogICogT3V0cHV0cyB0aGUgc3RhdGUgb2YgdGhlIHBoeXNpY2FsIG1l bW9yeSBhbGxvY2F0b3IsIHNwZWNpZmljYWxseSwKICAqIHRoZSBhbW91bnQgb2YgcGh5c2ljYWwg bWVtb3J5IGluIGVhY2ggZnJlZSBsaXN0LgpAQCAtMjkzLDYgKzI5NiwyOSBAQAogfQogCiAvKgor ICogR3JhYiBhIHBhZ2UgZnJvbSB0aGUgc3BlY2lmaWVkIGZyZWVsaXN0IHdpdGggdGhlIGdpdmVu IHBvb2wgYW5kCisgKiBvcmRlci4KKyAqLwordm1fcGFnZV90Cit2bV9waHlzX3BhZ2VfYWxsb2Mo aW50IGZsaW5kLCBpbnQgcG9vbCwgaW50IG9yZGVyKQoreworCXN0cnVjdCB2bm9kZSAqZHJvcDsK Kwl2bV9wYWdlX3QgbTsKKworCW10eF9sb2NrKCZ2bV9wYWdlX3F1ZXVlX2ZyZWVfbXR4KTsKKwlt ID0gdm1fcGh5c19hbGxvY19mcmVlbGlzdF9wYWdlcyhmbGluZCwgcG9vbCwgb3JkZXIpOworCWlm IChtID09IE5VTEwpIHsKKwkJbXR4X3VubG9jaygmdm1fcGFnZV9xdWV1ZV9mcmVlX210eCk7CisJ CXJldHVybiAoTlVMTCk7CisJfQorCXZtX3BhZ2VfYWxsb2NfaW5pdChtLCAmZHJvcCk7CisJbXR4 X3VubG9jaygmdm1fcGFnZV9xdWV1ZV9mcmVlX210eCk7CisJaWYgKGRyb3ApCisJCXZkcm9wKGRy b3ApOworCXJldHVybiAobSk7Cit9CisKKy8qCiAgKiBBbGxvY2F0ZSBhIGNvbnRpZ3VvdXMsIHBv d2VyIG9mIHR3by1zaXplZCBzZXQgb2YgcGh5c2ljYWwgcGFnZXMKICAqIGZyb20gdGhlIGZyZWUg bGlzdHMuCiAgKgpAQCAtMzAxLDQ5ICszMjcsNjggQEAKIHZtX3BhZ2VfdAogdm1fcGh5c19hbGxv Y19wYWdlcyhpbnQgcG9vbCwgaW50IG9yZGVyKQogeworCXZtX3BhZ2VfdCBtOworCWludCBmbGlu ZDsKKworCWZvciAoZmxpbmQgPSAwOyBmbGluZCA8IHZtX25mcmVlbGlzdHM7IGZsaW5kKyspIHsK KwkJbSA9IHZtX3BoeXNfYWxsb2NfZnJlZWxpc3RfcGFnZXMoZmxpbmQsIHBvb2wsIG9yZGVyKTsK KwkJaWYgKG0gIT0gTlVMTCkKKwkJCXJldHVybiBtOworCX0KKwlyZXR1cm4gKE5VTEwpOworfQor CisvKgorICogRmluZCBhbmQgZGVxdWV1ZSBhIGZyZWUgcGFnZSBvbiB0aGUgZ2l2ZW4gZnJlZSBs aXN0LCB3aXRoIHRoZSAKKyAqIHNwZWNpZmllZCBwb29sIGFuZCBvcmRlcgorICovCitzdGF0aWMg dm1fcGFnZV90Cit2bV9waHlzX2FsbG9jX2ZyZWVsaXN0X3BhZ2VzKGludCBmbGluZCwgaW50IHBv b2wsIGludCBvcmRlcikKK3sJCiAJc3RydWN0IHZtX2ZyZWVsaXN0ICpmbDsKIAlzdHJ1Y3Qgdm1f ZnJlZWxpc3QgKmFsdDsKLQlpbnQgZmxpbmQsIG9pbmQsIHBpbmQ7CisJaW50IG9pbmQsIHBpbmQ7 CiAJdm1fcGFnZV90IG07CiAKKwlLQVNTRVJUKGZsaW5kIDwgVk1fTkZSRUVMSVNULAorCSAgICAo InZtX3BoeXNfYWxsb2NfZnJlZWxpc3RfcGFnZXM6IGZyZWVsaXN0ICVkIGlzIG91dCBvZiByYW5n ZSIsIGZsaW5kKSk7CiAJS0FTU0VSVChwb29sIDwgVk1fTkZSRUVQT09MLAotCSAgICAoInZtX3Bo eXNfYWxsb2NfcGFnZXM6IHBvb2wgJWQgaXMgb3V0IG9mIHJhbmdlIiwgcG9vbCkpOworCSAgICAo InZtX3BoeXNfYWxsb2NfZnJlZWxpc3RfcGFnZXM6IHBvb2wgJWQgaXMgb3V0IG9mIHJhbmdlIiwg cG9vbCkpOwogCUtBU1NFUlQob3JkZXIgPCBWTV9ORlJFRU9SREVSLAotCSAgICAoInZtX3BoeXNf YWxsb2NfcGFnZXM6IG9yZGVyICVkIGlzIG91dCBvZiByYW5nZSIsIG9yZGVyKSk7CisJICAgICgi dm1fcGh5c19hbGxvY19mcmVlbGlzdF9wYWdlczogb3JkZXIgJWQgaXMgb3V0IG9mIHJhbmdlIiwg b3JkZXIpKTsKIAltdHhfYXNzZXJ0KCZ2bV9wYWdlX3F1ZXVlX2ZyZWVfbXR4LCBNQV9PV05FRCk7 Ci0JZm9yIChmbGluZCA9IDA7IGZsaW5kIDwgdm1fbmZyZWVsaXN0czsgZmxpbmQrKykgewotCQlm bCA9IHZtX3BoeXNfZnJlZV9xdWV1ZXNbZmxpbmRdW3Bvb2xdOwotCQlmb3IgKG9pbmQgPSBvcmRl cjsgb2luZCA8IFZNX05GUkVFT1JERVI7IG9pbmQrKykgewotCQkJbSA9IFRBSUxRX0ZJUlNUKCZm bFtvaW5kXS5wbCk7CisKKwlmbCA9IHZtX3BoeXNfZnJlZV9xdWV1ZXNbZmxpbmRdW3Bvb2xdOwor CWZvciAob2luZCA9IG9yZGVyOyBvaW5kIDwgVk1fTkZSRUVPUkRFUjsgb2luZCsrKSB7CisJCW0g PSBUQUlMUV9GSVJTVCgmZmxbb2luZF0ucGwpOworCQlpZiAobSAhPSBOVUxMKSB7CisJCQlUQUlM UV9SRU1PVkUoJmZsW29pbmRdLnBsLCBtLCBwYWdlcSk7CisJCQlmbFtvaW5kXS5sY250LS07CisJ CQltLT5vcmRlciA9IFZNX05GUkVFT1JERVI7CisJCQl2bV9waHlzX3NwbGl0X3BhZ2VzKG0sIG9p bmQsIGZsLCBvcmRlcik7CisJCQlyZXR1cm4gKG0pOworCQl9CisJfQorCisJLyoKKwkgKiBUaGUg Z2l2ZW4gcG9vbCB3YXMgZW1wdHkuICBGaW5kIHRoZSBsYXJnZXN0CisJICogY29udGlndW91cywg cG93ZXItb2YtdHdvLXNpemVkIHNldCBvZiBwYWdlcyBpbiBhbnkKKwkgKiBwb29sLiAgVHJhbnNm ZXIgdGhlc2UgcGFnZXMgdG8gdGhlIGdpdmVuIHBvb2wsIGFuZAorCSAqIHVzZSB0aGVtIHRvIHNh dGlzZnkgdGhlIGFsbG9jYXRpb24uCisJICovCisJZm9yIChvaW5kID0gVk1fTkZSRUVPUkRFUiAt IDE7IG9pbmQgPj0gb3JkZXI7IG9pbmQtLSkgeworCQlmb3IgKHBpbmQgPSAwOyBwaW5kIDwgVk1f TkZSRUVQT09MOyBwaW5kKyspIHsKKwkJCWFsdCA9IHZtX3BoeXNfZnJlZV9xdWV1ZXNbZmxpbmRd W3BpbmRdOworCQkJbSA9IFRBSUxRX0ZJUlNUKCZhbHRbb2luZF0ucGwpOwogCQkJaWYgKG0gIT0g TlVMTCkgewotCQkJCVRBSUxRX1JFTU9WRSgmZmxbb2luZF0ucGwsIG0sIHBhZ2VxKTsKLQkJCQlm bFtvaW5kXS5sY250LS07CisJCQkJVEFJTFFfUkVNT1ZFKCZhbHRbb2luZF0ucGwsIG0sIHBhZ2Vx KTsKKwkJCQlhbHRbb2luZF0ubGNudC0tOwogCQkJCW0tPm9yZGVyID0gVk1fTkZSRUVPUkRFUjsK KwkJCQl2bV9waHlzX3NldF9wb29sKHBvb2wsIG0sIG9pbmQpOwogCQkJCXZtX3BoeXNfc3BsaXRf cGFnZXMobSwgb2luZCwgZmwsIG9yZGVyKTsKIAkJCQlyZXR1cm4gKG0pOwogCQkJfQogCQl9Ci0K LQkJLyoKLQkJICogVGhlIGdpdmVuIHBvb2wgd2FzIGVtcHR5LiAgRmluZCB0aGUgbGFyZ2VzdAot CQkgKiBjb250aWd1b3VzLCBwb3dlci1vZi10d28tc2l6ZWQgc2V0IG9mIHBhZ2VzIGluIGFueQot CQkgKiBwb29sLiAgVHJhbnNmZXIgdGhlc2UgcGFnZXMgdG8gdGhlIGdpdmVuIHBvb2wsIGFuZAot CQkgKiB1c2UgdGhlbSB0byBzYXRpc2Z5IHRoZSBhbGxvY2F0aW9uLgotCQkgKi8KLQkJZm9yIChv aW5kID0gVk1fTkZSRUVPUkRFUiAtIDE7IG9pbmQgPj0gb3JkZXI7IG9pbmQtLSkgewotCQkJZm9y IChwaW5kID0gMDsgcGluZCA8IFZNX05GUkVFUE9PTDsgcGluZCsrKSB7Ci0JCQkJYWx0ID0gdm1f cGh5c19mcmVlX3F1ZXVlc1tmbGluZF1bcGluZF07Ci0JCQkJbSA9IFRBSUxRX0ZJUlNUKCZhbHRb b2luZF0ucGwpOwotCQkJCWlmIChtICE9IE5VTEwpIHsKLQkJCQkJVEFJTFFfUkVNT1ZFKCZhbHRb b2luZF0ucGwsIG0sIHBhZ2VxKTsKLQkJCQkJYWx0W29pbmRdLmxjbnQtLTsKLQkJCQkJbS0+b3Jk ZXIgPSBWTV9ORlJFRU9SREVSOwotCQkJCQl2bV9waHlzX3NldF9wb29sKHBvb2wsIG0sIG9pbmQp OwotCQkJCQl2bV9waHlzX3NwbGl0X3BhZ2VzKG0sIG9pbmQsIGZsLCBvcmRlcik7Ci0JCQkJCXJl dHVybiAobSk7Ci0JCQkJfQotCQkJfQotCQl9CiAJfQogCXJldHVybiAoTlVMTCk7CiB9CkBAIC01 NzcsNiArNjIyLDU2IEBACiB9CiAKIC8qCisgKiBJbml0aWFsaXplZCBhIHBhZ2UgdGhhdCBoYXMg YmVlbiBmcmVzaGx5IGRlcXVldWVkIGZyb20gYSBmcmVlbGlzdAorICogdGhlIGNhbGxlciBoYXMg dG8gZHJvcCB0aGUgdm5vZGUgcmV0dW5lZCBpbiBkcm9wLCBpZiBpdCBpcyBub3QgTlVMTAorICoK KyAqIFRvIGJlIGNhbGxlZCB3aXRoIHZtX3BhZ2VfcXVldWVfZnJlZV9tdHggaGVsZC4KKyAqLwor c3RhdGljIHZvaWQKK3ZtX3BhZ2VfYWxsb2NfaW5pdCh2bV9wYWdlX3QgbSwgc3RydWN0IHZub2Rl ICoqZHJvcCkKK3sKKwl2bV9vYmplY3RfdCBtX29iamVjdDsKKworCUtBU1NFUlQobS0+cXVldWUg PT0gUFFfTk9ORSwKKwkgICAgKCJ2bV9waHlzX2FsbG9jX2NvbnRpZzogcGFnZSAlcCBoYXMgdW5l eHBlY3RlZCBxdWV1ZSAlZCIsCisJICAgIG0sIG0tPnF1ZXVlKSk7CisJS0FTU0VSVChtLT53aXJl X2NvdW50ID09IDAsCisJICAgICgidm1fcGh5c19hbGxvY19jb250aWc6IHBhZ2UgJXAgaXMgd2ly ZWQiLCBtKSk7CisJS0FTU0VSVChtLT5ob2xkX2NvdW50ID09IDAsCisJICAgICgidm1fcGh5c19h bGxvY19jb250aWc6IHBhZ2UgJXAgaXMgaGVsZCIsIG0pKTsKKwlLQVNTRVJUKG0tPmJ1c3kgPT0g MCwKKwkgICAgKCJ2bV9waHlzX2FsbG9jX2NvbnRpZzogcGFnZSAlcCBpcyBidXN5IiwgbSkpOwor CUtBU1NFUlQobS0+ZGlydHkgPT0gMCwKKwkgICAgKCJ2bV9waHlzX2FsbG9jX2NvbnRpZzogcGFn ZSAlcCBpcyBkaXJ0eSIsIG0pKTsKKwlLQVNTRVJUKHBtYXBfcGFnZV9nZXRfbWVtYXR0cihtKSA9 PSBWTV9NRU1BVFRSX0RFRkFVTFQsCisJICAgICgidm1fcGh5c19hbGxvY19jb250aWc6IHBhZ2Ug JXAgaGFzIHVuZXhwZWN0ZWQgbWVtYXR0ciAlZCIsCisJICAgIG0sIHBtYXBfcGFnZV9nZXRfbWVt YXR0cihtKSkpOworCW10eF9hc3NlcnQoJnZtX3BhZ2VfcXVldWVfZnJlZV9tdHgsIE1BX09XTkVE KTsKKworCSpkcm9wID0gTlVMTDsKKwlpZiAoKG0tPmZsYWdzICYgUEdfQ0FDSEVEKSAhPSAwKSB7 CisJCW0tPnZhbGlkID0gMDsKKwkJbV9vYmplY3QgPSBtLT5vYmplY3Q7CisJCXZtX3BhZ2VfY2Fj aGVfcmVtb3ZlKG0pOworCQlpZiAobV9vYmplY3QtPnR5cGUgPT0gT0JKVF9WTk9ERSAmJgorCQkg ICAgbV9vYmplY3QtPmNhY2hlID09IE5VTEwpCisJCQkqZHJvcCA9IG1fb2JqZWN0LT5oYW5kbGU7 CisJfSBlbHNlIHsKKwkJS0FTU0VSVChWTV9QQUdFX0lTX0ZSRUUobSksCisJCSAgICAoInZtX3Bo eXNfYWxsb2NfY29udGlnOiBwYWdlICVwIGlzIG5vdCBmcmVlIiwgbSkpOworCQlLQVNTRVJUKG0t PnZhbGlkID09IDAsCisJCSAgICAoInZtX3BoeXNfYWxsb2NfY29udGlnOiBmcmVlIHBhZ2UgJXAg aXMgdmFsaWQiLCBtKSk7CisJCWNudC52X2ZyZWVfY291bnQtLTsKKwl9CisJaWYgKG0tPmZsYWdz ICYgUEdfWkVSTykKKwkJdm1fcGFnZV96ZXJvX2NvdW50LS07CisJLyogRG9uJ3QgY2xlYXIgdGhl IFBHX1pFUk8gZmxhZzsgd2UnbGwgbmVlZCBpdCBsYXRlci4gKi8KKwltLT5mbGFncyA9IFBHX1VO TUFOQUdFRCB8IChtLT5mbGFncyAmIFBHX1pFUk8pOworCW0tPm9mbGFncyA9IDA7CisJLyogVW5t YW5hZ2VkIHBhZ2VzIGRvbid0IHVzZSAiYWN0X2NvdW50Ii4gKi8KK30KKworLyoKICAqIEFsbG9j YXRlIGEgY29udGlndW91cyBzZXQgb2YgcGh5c2ljYWwgcGFnZXMgb2YgdGhlIGdpdmVuIHNpemUK ICAqICJucGFnZXMiIGZyb20gdGhlIGZyZWUgbGlzdHMuICBBbGwgb2YgdGhlIHBoeXNpY2FsIHBh Z2VzIG11c3QgYmUgYXQKICAqIG9yIGFib3ZlIHRoZSBnaXZlbiBwaHlzaWNhbCBhZGRyZXNzICJs b3ciIGFuZCBiZWxvdyB0aGUgZ2l2ZW4KQEAgLTU5MiwxMCArNjg3LDExIEBACiB7CiAJc3RydWN0 IHZtX2ZyZWVsaXN0ICpmbDsKIAlzdHJ1Y3Qgdm1fcGh5c19zZWcgKnNlZzsKLQl2bV9vYmplY3Rf dCBtX29iamVjdDsKKwlzdHJ1Y3Qgdm5vZGUgKnZwOwogCXZtX3BhZGRyX3QgcGEsIHBhX2xhc3Qs IHNpemU7CiAJdm1fcGFnZV90IGRlZmVycmVkX3Zkcm9wX2xpc3QsIG0sIG1fcmV0OwogCWludCBm bGluZCwgaSwgb2luZCwgb3JkZXIsIHBpbmQ7CisJCiAKIAlzaXplID0gbnBhZ2VzIDw8IFBBR0Vf U0hJRlQ7CiAJS0FTU0VSVChzaXplICE9IDAsCkBAIC02ODcsNTAgKzc4MywyMCBAQAogCXZtX3Bo eXNfc3BsaXRfcGFnZXMobV9yZXQsIG9pbmQsIGZsLCBvcmRlcik7CiAJZm9yIChpID0gMDsgaSA8 IG5wYWdlczsgaSsrKSB7CiAJCW0gPSAmbV9yZXRbaV07Ci0JCUtBU1NFUlQobS0+cXVldWUgPT0g UFFfTk9ORSwKLQkJICAgICgidm1fcGh5c19hbGxvY19jb250aWc6IHBhZ2UgJXAgaGFzIHVuZXhw ZWN0ZWQgcXVldWUgJWQiLAotCQkgICAgbSwgbS0+cXVldWUpKTsKLQkJS0FTU0VSVChtLT53aXJl X2NvdW50ID09IDAsCi0JCSAgICAoInZtX3BoeXNfYWxsb2NfY29udGlnOiBwYWdlICVwIGlzIHdp cmVkIiwgbSkpOwotCQlLQVNTRVJUKG0tPmhvbGRfY291bnQgPT0gMCwKLQkJICAgICgidm1fcGh5 c19hbGxvY19jb250aWc6IHBhZ2UgJXAgaXMgaGVsZCIsIG0pKTsKLQkJS0FTU0VSVChtLT5idXN5 ID09IDAsCi0JCSAgICAoInZtX3BoeXNfYWxsb2NfY29udGlnOiBwYWdlICVwIGlzIGJ1c3kiLCBt KSk7Ci0JCUtBU1NFUlQobS0+ZGlydHkgPT0gMCwKLQkJICAgICgidm1fcGh5c19hbGxvY19jb250 aWc6IHBhZ2UgJXAgaXMgZGlydHkiLCBtKSk7Ci0JCUtBU1NFUlQocG1hcF9wYWdlX2dldF9tZW1h dHRyKG0pID09IFZNX01FTUFUVFJfREVGQVVMVCwKLQkJICAgICgidm1fcGh5c19hbGxvY19jb250 aWc6IHBhZ2UgJXAgaGFzIHVuZXhwZWN0ZWQgbWVtYXR0ciAlZCIsCi0JCSAgICBtLCBwbWFwX3Bh Z2VfZ2V0X21lbWF0dHIobSkpKTsKLQkJaWYgKChtLT5mbGFncyAmIFBHX0NBQ0hFRCkgIT0gMCkg ewotCQkJbS0+dmFsaWQgPSAwOwotCQkJbV9vYmplY3QgPSBtLT5vYmplY3Q7Ci0JCQl2bV9wYWdl X2NhY2hlX3JlbW92ZShtKTsKLQkJCWlmIChtX29iamVjdC0+dHlwZSA9PSBPQkpUX1ZOT0RFICYm Ci0JCQkgICAgbV9vYmplY3QtPmNhY2hlID09IE5VTEwpIHsKLQkJCQkvKgotCQkJCSAqIEVucXVl dWUgdGhlIHZub2RlIGZvciBkZWZlcnJlZCB2ZHJvcCgpLgotCQkJCSAqCi0JCQkJICogVW5tYW5h Z2VkIHBhZ2VzIGRvbid0IHVzZSAicGFnZXEiLCBzbyBpdAotCQkJCSAqIGNhbiBiZSBzYWZlbHkg YWJ1c2VkIHRvIGNvbnN0cnVjdCBhIHNob3J0LQotCQkJCSAqIGxpdmVkIHF1ZXVlIG9mIHZub2Rl cy4KLQkJCQkgKi8KLQkJCQltLT5wYWdlcS50cWVfcHJldiA9IG1fb2JqZWN0LT5oYW5kbGU7Ci0J CQkJbS0+cGFnZXEudHFlX25leHQgPSBkZWZlcnJlZF92ZHJvcF9saXN0OwotCQkJCWRlZmVycmVk X3Zkcm9wX2xpc3QgPSBtOwotCQkJfQotCQl9IGVsc2UgewotCQkJS0FTU0VSVChWTV9QQUdFX0lT X0ZSRUUobSksCi0JCQkgICAgKCJ2bV9waHlzX2FsbG9jX2NvbnRpZzogcGFnZSAlcCBpcyBub3Qg ZnJlZSIsIG0pKTsKLQkJCUtBU1NFUlQobS0+dmFsaWQgPT0gMCwKLQkJCSAgICAoInZtX3BoeXNf YWxsb2NfY29udGlnOiBmcmVlIHBhZ2UgJXAgaXMgdmFsaWQiLCBtKSk7Ci0JCQljbnQudl9mcmVl X2NvdW50LS07CisJCXZtX3BhZ2VfYWxsb2NfaW5pdChtLCAmdnApOworCQlpZiAodnAgIT0gTlVM TCkgeworCQkJLyoKKwkJCSAqIEVucXVldWUgdGhlIHZub2RlIGZvciBkZWZlcnJlZCB2ZHJvcCgp LgorCQkJICoKKwkJCSAqIFVubWFuYWdlZCBwYWdlcyBkb24ndCB1c2UgInBhZ2VxIiwgc28gaXQK KwkJCSAqIGNhbiBiZSBzYWZlbHkgYWJ1c2VkIHRvIGNvbnN0cnVjdCBhIHNob3J0LQorCQkJICog bGl2ZWQgcXVldWUgb2Ygdm5vZGVzLgorCQkJICovCisKKwkJCW0tPnBhZ2VxLnRxZV9wcmV2ID0g KHZvaWQgKil2cDsKKwkJCW0tPnBhZ2VxLnRxZV9uZXh0ID0gZGVmZXJyZWRfdmRyb3BfbGlzdDsK KwkJCWRlZmVycmVkX3Zkcm9wX2xpc3QgPSBtOwogCQl9Ci0JCWlmIChtLT5mbGFncyAmIFBHX1pF Uk8pCi0JCQl2bV9wYWdlX3plcm9fY291bnQtLTsKLQkJLyogRG9uJ3QgY2xlYXIgdGhlIFBHX1pF Uk8gZmxhZzsgd2UnbGwgbmVlZCBpdCBsYXRlci4gKi8KLQkJbS0+ZmxhZ3MgPSBQR19VTk1BTkFH RUQgfCAobS0+ZmxhZ3MgJiBQR19aRVJPKTsKLQkJbS0+b2ZsYWdzID0gMDsKLQkJLyogVW5tYW5h Z2VkIHBhZ2VzIGRvbid0IHVzZSAiYWN0X2NvdW50Ii4gKi8KIAl9CiAJZm9yICg7IGkgPCByb3Vu ZHVwMihucGFnZXMsIDEgPDwgaW1pbihvaW5kLCBvcmRlcikpOyBpKyspIHsKIAkJbSA9ICZtX3Jl dFtpXTsKSW5kZXg6IHN5cy92bS92bV9waHlzLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL3ZtL3ZtX3Bo eXMuaAkocmV2aXNpb24gMjA4ODkwKQorKysgc3lzL3ZtL3ZtX3BoeXMuaAkod29ya2luZyBjb3B5 KQpAQCAtNDQsNiArNDQsNyBAQAogdm1fcGFnZV90IHZtX3BoeXNfYWxsb2NfY29udGlnKHVuc2ln bmVkIGxvbmcgbnBhZ2VzLAogICAgIHZtX3BhZGRyX3QgbG93LCB2bV9wYWRkcl90IGhpZ2gsCiAg ICAgdW5zaWduZWQgbG9uZyBhbGlnbm1lbnQsIHVuc2lnbmVkIGxvbmcgYm91bmRhcnkpOwordm1f cGFnZV90IHZtX3BoeXNfcGFnZV9hbGxvYyhpbnQgZmxpbmQsIGludCBwb29sLCBpbnQgb3JkZXIp Owogdm1fcGFnZV90IHZtX3BoeXNfYWxsb2NfcGFnZXMoaW50IHBvb2wsIGludCBvcmRlcik7CiB2 bV9wYWRkcl90IHZtX3BoeXNfYm9vdHN0cmFwX2FsbG9jKHZtX3NpemVfdCBzaXplLCB1bnNpZ25l ZCBsb25nIGFsaWdubWVudCk7CiB2b2lkIHZtX3BoeXNfZnJlZV9wYWdlcyh2bV9wYWdlX3QgbSwg aW50IG9yZGVyKTsK --00c09f899574c85e660488bf3fcf-- From owner-freebsd-mips@FreeBSD.ORG Fri Jun 11 12:45:32 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A4E21065670 for ; Fri, 11 Jun 2010 12:45:32 +0000 (UTC) (envelope-from sg@sg.org.ua) Received: from tbilisi.kiev.ua (mail.tbilisi.kiev.ua [193.254.217.230]) by mx1.freebsd.org (Postfix) with ESMTP id 1B8E98FC1B for ; Fri, 11 Jun 2010 12:45:30 +0000 (UTC) Received: from sg.intra ([172.16.1.4]) by tbilisi.kiev.ua with esmtpa (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ON2ys-000MF3-0y for freebsd-mips@freebsd.org; Fri, 11 Jun 2010 15:05:02 +0300 From: Alexander Mogilny Content-Type: multipart/mixed; boundary=Apple-Mail-1--549525150 Date: Fri, 11 Jun 2010 15:05:01 +0300 Message-Id: <9C6B899F-0361-4E20-A9C4-20C002A3CA1D@sg.org.ua> To: freebsd-mips@freebsd.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-SA-Exim-Connect-IP: 172.16.1.4 X-SA-Exim-Mail-From: sg@sg.org.ua X-SA-Exim-Scanned: No (on tbilisi.kiev.ua); SAEximRunCond expanded to false Subject: RouterBOARD RB450G X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 12:45:32 -0000 --Apple-Mail-1--549525150 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all! I have recently purchased RB450G router and was not satisfied with RouterOS so I decided to install FreeBSD on this device. There are some issues with starting FreeBSD on this device so I would like to help community to fix some code and get this device working. Default AR71XX kernel failed to boot. Boot process stopped at ohci device detection (it just hanged). When I commented it out in hints file I got following: =3D=3D=3D=3D=3D=3D=3D=3D RouterBOOT booter 2.23 RouterBoard 450G CPU frequency: 680 MHz Memory size: 256 MB Press any key within 2 seconds to enter setup.. Please, check ethernet cable... trying bootp protocol... OK Got IP address: 172.16.0.40 resolved mac address 00:E0:81:49:87:F7 Gateway: 172.16.0.1 transfer started ...................................... transfer ok, = time=3D3.02s setting up elf image... OK jumping to kernel code platform frequency: 680000000 arguments:=20 a0 =3D 00000008 a1 =3D a0861c00 a2 =3D 00000000 a3 =3D 00000000 Cmd line: console=3DttyS0,115200 gpio=3D1983 HZ=3D340000000 mem=3D256M = kmac=3D00:0C:42:59:30:FF board=3D450G boot=3D1 mlc=3D2 Environment: envp is invalid Cache info: picache_stride =3D 4096 picache_loopcount =3D 16 pdcache_stride =3D 4096 pdcache_loopcount =3D 8 cpu0: MIPS Technologies processor v116.147 MMU: Standard TLB, 16 entries L1 i-cache: 4 ways of 512 sets, 32 bytes per line L1 d-cache: 4 ways of 256 sets, 32 bytes per line Config1=3D0x9ee3519e Config3=3D0x20 KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #17: Thu Jun 10 14:40:34 EEST 2010 root@tbilisi.intra:/usr/obj/mips/mips/usr/src.mips/sys/MIKROTIK mips WARNING: WITNESS option enabled, expect reduced performance. real memory =3D 33554432 (32768K bytes) avail memory =3D 25894912 (24MB) nexus0: clock0: on nexus0 clock0: [FILTER] apb0 at irq 4 on nexus0 apb0: [FILTER] uart0: <16550 or compatible> on apb0 uart0: [FILTER] uart0: console (115200,n,8,1) ehci0: at mem = 0x1b000000-0x1bffffff irq 1 on nexus0 ehci0: [ITHREAD] usbus0: set host controller mode usbus0: EHCI version 1.0 usbus0: set host controller mode usbus0: on ehci0 pcib0 at irq 0 on nexus0 pcib0: [FILTER] pci0: on pcib0 pci0: at device 0.0 (no driver attached) ... [ skipped ] ... pci0: at device 31.0 (no driver attached) arge0: at mem = 0x19000000-0x19000fff irq 2 on nexus0 miibus0: on arge0 ukphy0: PHY 4 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, = auto arge0: Ethernet address: 62:73:64:40:64:4b arge0: [FILTER+ITHREAD] arge1: at mem = 0x1a000000-0x1a000fff irq 3 on nexus0 arge1: Ethernet address: 62:73:64:ca:db:ce arge1: [FILTER+ITHREAD] spi0: at mem 0x1f000000-0x1f00000f on nexus0 spibus0: on spi0 spibus0: at cs 1 mx25l0: at cs 0 on spibus0 Unknown SPI flash device. Vendor: ff, device id: ffff device_attach: mx25l0 attach returned 6 ar71xx_wdog0: on nexus0 Timecounter "MIPS32" frequency 340000000 Hz quality 800 Timecounters tick every 1.000 msec bootpc_init: wired to interface 'arge0' Sending DHCP Discover packet from interface arge0 (62:73:64:40:64:4b) arge0: link state changed to DOWN usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on = usbus0 uhub0: 2 ports with 2 removable, self powered DHCP/BOOTP timeout for server 255.255.255.255 arge0: link state changed to UP =3D=3D=3D=3D=3D=3D=3D As you can see ethernet card got incorrect ethernet address. What could cause this? Perhaps I can somehow give you some more debug information? Kern conf and hints file are in attachment. --=20 AIM-UANIC | AIM-RIPE +-----[ FreeBSD ]-----+ Alexander Mogilny | The Power to Serve! | <> sg@sg.org.ua +---------------------+ --Apple-Mail-1--549525150 Content-Disposition: attachment; filename=AR71XX.hints Content-Type: application/octet-stream; x-unix-mode=0644; name="AR71XX.hints" Content-Transfer-Encoding: 7bit # $FreeBSD: src/sys/mips/conf/AR71XX.hints,v 1.2 2010/01/22 22:14:12 gonzo Exp $ hint.apb.0.at="nexus0" hint.apb.0.irq=4 # uart0 hint.uart.0.at="apb0" # see atheros/uart_cpu_ar71xx.c why +3 hint.uart.0.maddr=0x18020003 hint.uart.0.msize=0x18 hint.uart.0.irq=3 #ohci #hint.ohci.0.at="apb0" #hint.ohci.0.maddr=0x1c000000 #hint.ohci.0.msize=0x01000000 #hint.ohci.0.irq=6 #ehci hint.ehci.0.at="nexus0" hint.ehci.0.maddr=0x1b000000 hint.ehci.0.msize=0x01000000 hint.ehci.0.irq=1 # pci hint.pcib.0.at="nexus0" hint.pcib.0.irq=0 hint.arge.0.at="nexus0" hint.arge.0.maddr=0x19000000 hint.arge.0.msize=0x1000 hint.arge.0.irq=2 hint.arge.0.phymask=0x10 hint.arge.1.at="nexus0" hint.arge.1.maddr=0x1a000000 hint.arge.1.msize=0x1000 hint.arge.1.irq=3 # PHY1, PHY2, PHY3 hint.arge.1.phymask=0x0e # should be 100 for RS hint.arge.1.media=1000 hint.arge.1.fduplex=1 # GPIO hint.gpio.0.at="apb0" hint.gpio.0.maddr=0x18040000 hint.gpio.0.msize=0x1000 hint.gpio.0.irq=2 # User led - pin 4 hint.gpioled.0.at="gpiobus0" hint.gpioled.0.name="userled" hint.gpioled.0.pins=0x0010 # RB NAND Flash - read busy status from SoC gpio pin 5 hint.rb_nandbusy.0.at="gpiobus0" hint.rb_nandbusy.0.pins=0x0020 # RouterBoard CPLD hint.rb_cpldbus.0.at="spibus0" hint.rb_cpldbus.0.cs=1 # RouterBoard CPLD leds hint.gpioled.1.at="gpiobus1" hint.gpioled.1.name="led1" hint.gpioled.1.pins=0x0001 hint.gpioled.2.at="gpiobus1" hint.gpioled.2.name="led2" hint.gpioled.2.pins=0x0002 hint.gpioled.3.at="gpiobus1" hint.gpioled.3.name="led3" hint.gpioled.3.pins=0x0004 hint.gpioled.4.at="gpiobus1" hint.gpioled.4.name="led4" hint.gpioled.4.pins=0x0008 # NAND slices for RouterBoard hint.flash.0.at="nand0" hint.flash.0.start=0x0 hint.flash.0.end=0x42000 hint.flash.0.name="bootloader" hint.flash.0.readonly=1 hint.flash.1.at="nand0" hint.flash.1.start=0x42000 hint.flash.1.end=0x420000 hint.flash.1.name="kernelfs" hint.flash.2.at="nand0" hint.flash.2.start=0x420000 hint.flash.2.end=0x4200000 hint.flash.2.name="rootfs" # SPI flash hint.spi.0.at="nexus0" hint.spi.0.maddr=0x1f000000 hint.spi.0.msize=0x10 hint.mx25l.0.at="spibus0" hint.mx25l.0.cs=0 # shares the same bus with mx25l. # CE low for flash, CE high for RTC # at the moment it's just stub until SPI bus is ready for such hacks # hint.rtc.0.at="spibus0" # hint.rtc.0.cs=0 # Watchdog hint.ar71xx_wdog.0.at="nexus0" --Apple-Mail-1--549525150 Content-Disposition: attachment; filename=dmesg.boot Content-Type: application/octet-stream; x-unix-mode=0644; name="dmesg.boot" Content-Transfer-Encoding: 7bit RouterBOOT booter 2.23 RouterBoard 450G CPU frequency: 680 MHz Memory size: 256 MB Press any key within 2 seconds to enter setup.. Please, check ethernet cable... trying bootp protocol... OK Got IP address: 172.16.0.40 resolved mac address 00:E0:81:49:87:F7 Gateway: 172.16.0.1 transfer started ...................................... transfer ok, time=3.02s setting up elf image... OK jumping to kernel code platform frequency: 680000000 arguments: a0 = 00000008 a1 = a0861c00 a2 = 00000000 a3 = 00000000 Cmd line: console=ttyS0,115200 gpio=1983 HZ=340000000 mem=256M kmac=00:0C:42:59:30:FF board=450G boot=1 mlc=2 Environment: envp is invalid Cache info: picache_stride = 4096 picache_loopcount = 16 pdcache_stride = 4096 pdcache_loopcount = 8 cpu0: MIPS Technologies processor v116.147 MMU: Standard TLB, 16 entries L1 i-cache: 4 ways of 512 sets, 32 bytes per line L1 d-cache: 4 ways of 256 sets, 32 bytes per line Config1=0x9ee3519e Config3=0x20 KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #17: Thu Jun 10 14:40:34 EEST 2010 root@tbilisi.intra:/usr/obj/mips/mips/usr/src.mips/sys/MIKROTIK mips WARNING: WITNESS option enabled, expect reduced performance. real memory = 33554432 (32768K bytes) avail memory = 25894912 (24MB) nexus0: clock0: on nexus0 clock0: [FILTER] apb0 at irq 4 on nexus0 apb0: [FILTER] uart0: <16550 or compatible> on apb0 uart0: [FILTER] uart0: console (115200,n,8,1) ehci0: at mem 0x1b000000-0x1bffffff irq 1 on nexus0 ehci0: [ITHREAD] usbus0: set host controller mode usbus0: EHCI version 1.0 usbus0: set host controller mode usbus0: on ehci0 pcib0 at irq 0 on nexus0 pcib0: [FILTER] pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 1.0 (no driver attached) pci0: at device 2.0 (no driver attached) pci0: at device 3.0 (no driver attached) pci0: at device 4.0 (no driver attached) pci0: at device 5.0 (no driver attached) pci0: at device 6.0 (no driver attached) pci0: at device 7.0 (no driver attached) pci0: at device 8.0 (no driver attached) pci0: at device 9.0 (no driver attached) pci0: at device 10.0 (no driver attached) pci0: at device 11.0 (no driver attached) pci0: at device 12.0 (no driver attached) pci0: at device 13.0 (no driver attached) pci0: at device 14.0 (no driver attached) pci0: at device 15.0 (no driver attached) pci0: at device 16.0 (no driver attached) pci0: at device 17.0 (no driver attached) pci0: at device 18.0 (no driver attached) pci0: at device 19.0 (no driver attached) pci0: at device 20.0 (no driver attached) pci0: at device 21.0 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 23.0 (no driver attached) pci0: at device 24.0 (no driver attached) pci0: at device 25.0 (no driver attached) pci0: at device 26.0 (no driver attached) pci0: at device 27.0 (no driver attached) pci0: at device 28.0 (no driver attached) pci0: at device 29.0 (no driver attached) pci0: at device 30.0 (no driver attached) pci0: at device 31.0 (no driver attached) arge0: at mem 0x19000000-0x19000fff irq 2 on nexus0 miibus0: on arge0 ukphy0: PHY 4 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto arge0: Ethernet address: 62:73:64:40:64:4b arge0: [FILTER+ITHREAD] arge1: at mem 0x1a000000-0x1a000fff irq 3 on nexus0 arge1: Ethernet address: 62:73:64:ca:db:ce arge1: [FILTER+ITHREAD] spi0: at mem 0x1f000000-0x1f00000f on nexus0 spibus0: on spi0 spibus0: at cs 1 mx25l0: at cs 0 on spibus0 Unknown SPI flash device. Vendor: ff, device id: ffff device_attach: mx25l0 attach returned 6 ar71xx_wdog0: on nexus0 Timecounter "MIPS32" frequency 340000000 Hz quality 800 Timecounters tick every 1.000 msec bootpc_init: wired to interface 'arge0' Sending DHCP Discover packet from interface arge0 (62:73:64:40:64:4b) arge0: link state changed to DOWN usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 2 ports with 2 removable, self powered DHCP/BOOTP timeout for server 255.255.255.255 arge0: link state changed to UP --Apple-Mail-1--549525150 Content-Disposition: attachment; filename=MIKROTIK Content-Type: application/octet-stream; x-unix-mode=0644; name="MIKROTIK" Content-Transfer-Encoding: 7bit # # AR71XX # ident MIKROTIK cpu CPU_MIPS4KC options ISA_MIPS32 makeoptions TARGET_BIG_ENDIAN makeoptions KERNLOADADDR=0x80050000 options HZ=1000 files "../atheros/files.ar71xx" hints "AR71XX.hints" #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols #makeoptions MODULES_OVERRIDE="" options DDB options KDB options SCHED_4BSD #4BSD scheduler options INET #InterNETworking options NFSCLIENT #Network Filesystem Client options NFS_ROOT #NFS usable as /, requires NFSCLIENT options PSEUDOFS #Pseudo-filesystem framework options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions # options NFS_LEGACYRPC # Debugging for use in -current options DEADLKRES options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options BOOTP options BOOTP_NFSROOT options BOOTP_NFSV3 options BOOTP_WIRED_TO=arge0 options BOOTP_COMPAT options ROOTDEVNAME=\"nfs:172.16.0.100:/home/nfs\" device pci # Wireless NIC cards options IEEE80211_DEBUG options IEEE80211_SUPPORT_MESH options IEEE80211_SUPPORT_TDMA device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device ath # Atheros pci/cardbus NIC's options ATH_DEBUG device ath_hal option AH_SUPPORT_AR5416 option AH_RXCFG_SDMAMW_4BYTES # See NOTES for details of this WAR device ath_rate_sample device mii device arge device usb options USB_EHCI_BIG_ENDIAN_DESC # handle big-endian byte order options USB_DEBUG device ohci device ehci device spibus device ar71xx_spi device mx25l device geom_redboot device ar71xx_wdog device uart device loop device ether device md device bpf device random device if_bridge --Apple-Mail-1--549525150 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail-1--549525150-- From owner-freebsd-mips@FreeBSD.ORG Fri Jun 11 13:24:39 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC1A2106566C for ; Fri, 11 Jun 2010 13:24:39 +0000 (UTC) (envelope-from freebsd@luftivennad.com) Received: from fiona.equix.ee (fiona.equix.ee [188.92.161.31]) by mx1.freebsd.org (Postfix) with ESMTP id 21D0B8FC12 for ; Fri, 11 Jun 2010 13:24:38 +0000 (UTC) Received: by fiona.equix.ee (Postfix, from userid 2500) id 47BEE26F94B; Fri, 11 Jun 2010 16:07:31 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.equix.ee X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.5 Received: from webmail.equix.ee (localhost [188.92.161.31]) by fiona.equix.ee (Postfix) with ESMTP id 508C526F949 for ; Fri, 11 Jun 2010 16:07:28 +0300 (EEST) Received: from 62.65.217.127.cable.starman.ee ([62.65.217.127]) (SquirrelMail authenticated user zwoz) by webmail.equix.ee with HTTP; Fri, 11 Jun 2010 16:07:28 +0300 Message-ID: <9c83a480a3f456a711411e7b458fdd41.squirrel@webmail.equix.ee> Date: Fri, 11 Jun 2010 16:07:28 +0300 From: "Ain" To: freebsd-mips@freebsd.org User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Building image for Routerstation Pro X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 13:24:40 -0000 Hello! I am trying get big picture, what is needed to make standalone, all in onboard flash installation. I found some good pointers, like Adrian Chadd patched utilities and README at http://people.freebsd.org/~adrian/rspro/ But something seems to missing, from example, i don't get, why mfs writes mdroot in kernel and then mkfwimage (used by mkflash script) combines new kernel with mdroot file again. Second thing is (if i understand correctly) 13 MB is allowed RSPRO image size. My temporary file system image size is 13-14 MB (created by Adrian mfs script, named /tmp/mfsroot). mkfwimage raports combined image filesize 19MB (i added little printing statement in create_image_layout, before if (filelength(rootfsfile) + kernel->partition_length > p->firmware_max_length) ). What is needed to make system smaller? Sources are 8. june CURRENT, kernel options MD_ROOT_SIZE=8192 Any pointers or questions are welcomed, Ain From owner-freebsd-mips@FreeBSD.ORG Fri Jun 11 13:40:06 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E78E1065677 for ; Fri, 11 Jun 2010 13:40:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id CB46D8FC22 for ; Fri, 11 Jun 2010 13:40:05 +0000 (UTC) Received: by gyh20 with SMTP id 20so862835gyh.13 for ; Fri, 11 Jun 2010 06:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=v6CMQEd+ZHGS3u2tKvDsYSV67vMvsIKZRayIPpaGQgA=; b=mZUrKKfEy5iYFqartW2zBMRk+uvzxMA9aELvDbkXsDGNFMkVTsIQkDj5S7zCbMdOGE Wka5zZrKvHQT9axe338rQ1/hEWhlkQ8ag8/KFdTZEMvfZenLsGQDEvaiSh1a5+BHKLFj 7Vt626TXmnh6YHtAsfMOr938NOUpCeddBuK3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=P2fTkg2vydL8F/6v+DBj05wI9x0jS1X5krm96W9G3l3tPfjcuf4zUZSnfYGXh33aQK bWq/tLOpDWRHxy6KP8d1J3Q/OsYuKkMYDl6fryTjx2F9G01ym4//SbI9WC72G+jsEyGd or671EHauZJcNSjLRndk3rE8dGEpnCYsFlz8w= MIME-Version: 1.0 Received: by 10.91.146.20 with SMTP id y20mr2288838agn.19.1276263604786; Fri, 11 Jun 2010 06:40:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.156.76 with HTTP; Fri, 11 Jun 2010 06:40:04 -0700 (PDT) In-Reply-To: <9c83a480a3f456a711411e7b458fdd41.squirrel@webmail.equix.ee> References: <9c83a480a3f456a711411e7b458fdd41.squirrel@webmail.equix.ee> Date: Fri, 11 Jun 2010 21:40:04 +0800 X-Google-Sender-Auth: EEr40O18FsBcu6t-pLPPaskTT8A Message-ID: From: Adrian Chadd To: Ain Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: Building image for Routerstation Pro X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 13:40:06 -0000 Hi! Ok, so: The mkfwimage program is from ubiquiti and the openwrt project. It's based on "Linux" assumptions - that there's a small kernel partition that is booted, then a large rootfs partition which holds the root filesystem, (device driver, etc) modules, etc. My images at work are integrated kernel+mdroot (gzip'ed). I'd like to eventually be able to run off of a read-only rootfs on the SPI flash but that will require some significant twiddling of the flash device code. For now, I use a user-space filestore program and a small rootfs (1mb) for config file and other sundry storage. There should be a cut down config file example in the config file there. You could try adding the various bits to make a geom_gzip mdroot - this significantly reduced my image size. HTH, adrian On 11 June 2010 21:07, Ain wrote: > Hello! > > I am trying get big picture, what is needed to make standalone, all in > onboard flash installation. I found some good pointers, like Adrian Chadd > patched utilities and README at http://people.freebsd.org/~adrian/rspro/ > But something seems to missing, from example, i don't get, why =A0mfs wri= tes > mdroot in kernel and then =A0mkfwimage (used by mkflash script) combines = new > kernel with mdroot file again. > Second thing is (if i understand correctly) 13 MB is allowed RSPRO image > size. > My =A0temporary file system image size is 13-14 MB (created by =A0Adrian = mfs > script, named /tmp/mfsroot). > mkfwimage raports =A0combined image filesize 19MB (i added little printin= g > statement in create_image_layout, before if (filelength(rootfsfile) + > kernel->partition_length > p->firmware_max_length) ). > What is needed to make system smaller? Sources are 8. june CURRENT, kerne= l > options MD_ROOT_SIZE=3D8192 > > Any pointers or questions are welcomed, > > Ain > > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > From owner-freebsd-mips@FreeBSD.ORG Fri Jun 11 14:01:36 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A87B61065676 for ; Fri, 11 Jun 2010 14:01:36 +0000 (UTC) (envelope-from freebsd@luftivennad.com) Received: from fiona.equix.ee (fiona.equix.ee [188.92.161.31]) by mx1.freebsd.org (Postfix) with ESMTP id 06E958FC12 for ; Fri, 11 Jun 2010 14:01:35 +0000 (UTC) Received: by fiona.equix.ee (Postfix, from userid 2500) id A8EAB26F947; Fri, 11 Jun 2010 17:03:02 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.equix.ee X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL autolearn=disabled version=3.2.5 Received: from webmail.equix.ee (localhost [188.92.161.31]) by fiona.equix.ee (Postfix) with ESMTP id 3DED826F93A; Fri, 11 Jun 2010 17:02:59 +0300 (EEST) Received: from 62.65.217.127.cable.starman.ee ([62.65.217.127]) (SquirrelMail authenticated user zwoz) by webmail.equix.ee with HTTP; Fri, 11 Jun 2010 17:02:59 +0300 Message-ID: <6d625a568cdee81a51c155bbae240244.squirrel@webmail.equix.ee> In-Reply-To: References: <9c83a480a3f456a711411e7b458fdd41.squirrel@webmail.equix.ee> Date: Fri, 11 Jun 2010 17:02:59 +0300 From: "Ain" To: "Adrian Chadd" User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-mips@freebsd.org Subject: Re: Building image for Routerstation Pro X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 14:01:36 -0000 Thank You for answer! I think i get some ideas, what i can try next WBR, Ain > Hi! > > Ok, so: > > The mkfwimage program is from ubiquiti and the openwrt project. It's > based on "Linux" assumptions - that there's a small kernel partition > that is booted, then a large rootfs partition which holds the root > filesystem, (device driver, etc) modules, etc. > > My images at work are integrated kernel+mdroot (gzip'ed). I'd like to > eventually be able to run off of a read-only rootfs on the SPI flash > but that will require some significant twiddling of the flash device > code. For now, I use a user-space filestore program and a small rootfs > (1mb) for config file and other sundry storage. > > There should be a cut down config file example in the config file > there. You could try adding the various bits to make a geom_gzip > mdroot - this significantly reduced my image size. > > HTH, > > > adrian > > On 11 June 2010 21:07, Ain wrote: >> Hello! >> >> I am trying get big picture, what is needed to make standalone, all in >> onboard flash installation. I found some good pointers, like Adrian >> Chadd >> patched utilities and README at http://people.freebsd.org/~adrian/rspro/ >> But something seems to missing, from example, i don't get, why  mfs >> writes >> mdroot in kernel and then  mkfwimage (used by mkflash script) combines >> new >> kernel with mdroot file again. >> Second thing is (if i understand correctly) 13 MB is allowed RSPRO image >> size. >> My  temporary file system image size is 13-14 MB (created by  Adrian mfs >> script, named /tmp/mfsroot). >> mkfwimage raports  combined image filesize 19MB (i added little printing >> statement in create_image_layout, before if (filelength(rootfsfile) + >> kernel->partition_length > p->firmware_max_length) ). >> What is needed to make system smaller? Sources are 8. june CURRENT, >> kernel >> options MD_ROOT_SIZE=8192 >> >> Any pointers or questions are welcomed, >> >> Ain >> >> _______________________________________________ >> freebsd-mips@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-mips >> To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" >> > From owner-freebsd-mips@FreeBSD.ORG Fri Jun 11 20:50:05 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E36AC1065678 for ; Fri, 11 Jun 2010 20:50:05 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7736D8FC14 for ; Fri, 11 Jun 2010 20:50:05 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 03FA016F5CC; Fri, 11 Jun 2010 15:50:04 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id PPVQ8R1PZK0L; Fri, 11 Jun 2010 15:50:03 -0500 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <9C6B899F-0361-4E20-A9C4-20C002A3CA1D@sg.org.ua> Date: Fri, 11 Jun 2010 21:50:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C6B899F-0361-4E20-A9C4-20C002A3CA1D@sg.org.ua> To: Alexander Mogilny X-Mailer: Apple Mail (2.1078) Cc: freebsd-mips@freebsd.org Subject: Re: RouterBOARD RB450G X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 20:50:06 -0000 On 11 Jun 2010, at 13:05, Alexander Mogilny wrote: > Hi all! > I have recently purchased RB450G router and was not > satisfied with RouterOS so I decided to install FreeBSD > on this device. > There are some issues with starting FreeBSD on this device > so I would like to help community to fix some code and get > this device working. >=20 > Default AR71XX kernel failed to boot. Boot process stopped > at ohci device detection (it just hanged). When I commented > it out in hints file I got following: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D > RouterBOOT booter 2.23 > RouterBoard 450G > CPU frequency: 680 MHz > Memory size: 256 MB >=20 > Press any key within 2 seconds to enter setup.. > Please, check ethernet cable... > trying bootp protocol... OK > Got IP address: 172.16.0.40 > resolved mac address 00:E0:81:49:87:F7 > Gateway: 172.16.0.1 > transfer started ...................................... transfer ok, = time=3D3.02s > setting up elf image... OK > jumping to kernel code > platform frequency: 680000000 > arguments:=20 > a0 =3D 00000008 > a1 =3D a0861c00 > a2 =3D 00000000 > a3 =3D 00000000 > Cmd line: console=3DttyS0,115200 gpio=3D1983 HZ=3D340000000 mem=3D256M = kmac=3D00:0C:42:59:30:FF board=3D450G boot=3D1 mlc=3D2 > Environment: > envp is invalid > Cache info: > picache_stride =3D 4096 > picache_loopcount =3D 16 > pdcache_stride =3D 4096 > pdcache_loopcount =3D 8 > cpu0: MIPS Technologies processor v116.147 > MMU: Standard TLB, 16 entries > L1 i-cache: 4 ways of 512 sets, 32 bytes per line > L1 d-cache: 4 ways of 256 sets, 32 bytes per line > Config1=3D0x9ee3519e > Config3=3D0x20 > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2010 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 > The Regents of the University of California. All rights = reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-CURRENT #17: Thu Jun 10 14:40:34 EEST 2010 > root@tbilisi.intra:/usr/obj/mips/mips/usr/src.mips/sys/MIKROTIK = mips > WARNING: WITNESS option enabled, expect reduced performance. > real memory =3D 33554432 (32768K bytes) > avail memory =3D 25894912 (24MB) > nexus0: > clock0: on nexus0 > clock0: [FILTER] > apb0 at irq 4 on nexus0 > apb0: [FILTER] > uart0: <16550 or compatible> on apb0 > uart0: [FILTER] > uart0: console (115200,n,8,1) > ehci0: at mem = 0x1b000000-0x1bffffff irq 1 on nexus0 > ehci0: [ITHREAD] > usbus0: set host controller mode > usbus0: EHCI version 1.0 > usbus0: set host controller mode > usbus0: on ehci0 > pcib0 at irq 0 on nexus0 > pcib0: [FILTER] > pci0: on pcib0 > pci0: at device 0.0 (no driver attached) >=20 > ... > [ skipped ] > ... >=20 > pci0: at device 31.0 (no driver = attached) > arge0: at mem = 0x19000000-0x19000fff irq 2 on nexus0 > miibus0: on arge0 > ukphy0: PHY 4 on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, auto > arge0: Ethernet address: 62:73:64:40:64:4b > arge0: [FILTER+ITHREAD] > arge1: at mem = 0x1a000000-0x1a000fff irq 3 on nexus0 > arge1: Ethernet address: 62:73:64:ca:db:ce > arge1: [FILTER+ITHREAD] > spi0: at mem 0x1f000000-0x1f00000f on nexus0 > spibus0: on spi0 > spibus0: at cs 1 > mx25l0: at cs 0 on spibus0 > Unknown SPI flash device. Vendor: ff, device id: ffff > device_attach: mx25l0 attach returned 6 > ar71xx_wdog0: on nexus0 > Timecounter "MIPS32" frequency 340000000 Hz quality 800 > Timecounters tick every 1.000 msec > bootpc_init: wired to interface 'arge0' > Sending DHCP Discover packet from interface arge0 (62:73:64:40:64:4b) > arge0: link state changed to DOWN > usbus0: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on = usbus0 > uhub0: 2 ports with 2 removable, self powered > DHCP/BOOTP timeout for server 255.255.255.255 > arge0: link state changed to UP > =3D=3D=3D=3D=3D=3D=3D >=20 > As you can see ethernet card got incorrect ethernet address. > What could cause this? Perhaps I can somehow give you some more > debug information? >=20 > Kern conf and hints file are in attachment. How are you booting your kernel? If you typed 'go' instead of 'exec', = bad things like these can happen. Regards, -- Rui Paulo From owner-freebsd-mips@FreeBSD.ORG Fri Jun 11 21:20:55 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CFF5106566C for ; Fri, 11 Jun 2010 21:20:55 +0000 (UTC) (envelope-from gonzo@launchpad.bluezbox.com) Received: from launchpad.bluezbox.com (launchpad.bluezbox.com [195.137.202.161]) by mx1.freebsd.org (Postfix) with ESMTP id B51A48FC19 for ; Fri, 11 Jun 2010 21:20:54 +0000 (UTC) Received: from [76.77.86.2] (helo=[10.80.7.8]) by launchpad.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONBei-000OMh-Er; Fri, 11 Jun 2010 21:20:53 +0000 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Oleksandr Tymoshenko In-Reply-To: <9C6B899F-0361-4E20-A9C4-20C002A3CA1D@sg.org.ua> Date: Fri, 11 Jun 2010 14:20:15 -0700 Content-Transfer-Encoding: 7bit Message-Id: <2D2B1168-4E11-4353-8856-FD2728413F1B@bluezbox.com> References: <9C6B899F-0361-4E20-A9C4-20C002A3CA1D@sg.org.ua> To: Alexander Mogilny X-Mailer: Apple Mail (2.1078) Sender: gonzo@launchpad.bluezbox.com X-Spam-Level: ---- X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list Cc: freebsd-mips@freebsd.org Subject: Re: RouterBOARD RB450G X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 21:20:55 -0000 On 2010-06-11, at 5:05 AM, Alexander Mogilny wrote: > Hi all! > I have recently purchased RB450G router and was not > satisfied with RouterOS so I decided to install FreeBSD > on this device. > There are some issues with starting FreeBSD on this device > so I would like to help community to fix some code and get > this device working. > > Default AR71XX kernel failed to boot. Boot process stopped > at ohci device detection (it just hanged). When I commented > it out in hints file I got following: > .. skipped .. > > As you can see ethernet card got incorrect ethernet address. > What could cause this? Perhaps I can somehow give you some more > debug information? RouterBoard and Routerstation use different approaches for passing device-dependent data (MAC address, memsize) to kernel. Routerstation uses redboot that passes key-value pairs in environment memory area while RouterBoard's own boot loader passes them as key-value pairs in argv. Some minor hackery required to get it working. It's not done yet because I didn't have a chance to get my hands on AR71XX-based routerboard :) -- gonzo From owner-freebsd-mips@FreeBSD.ORG Sat Jun 12 12:05:43 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD5311065678 for ; Sat, 12 Jun 2010 12:05:43 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5BCA58FC24 for ; Sat, 12 Jun 2010 12:05:43 +0000 (UTC) Received: by vws20 with SMTP id 20so1659488vws.13 for ; Sat, 12 Jun 2010 05:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=YO6icTyJfR1xWE9l50c8/Z1uaUhKK4yNHHR8kiZJkkA=; b=ffCg0HKCnLgwKZnK+S1GZzeGX4I0thvUFVucBW4jih/bdCnvYZSDDzVa60wfwHQBV1 KzV6zMkmDXYpNsymKcNui/YjrbAAUc8zoZRf5fWcuxlsnAZHweMlFkHzCvYqw/PCZzzT B/MtaC54LypI5u5t3tQ/xsoPx0iuejsTUsd7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=pJQK459i5lCob8b8pCr0n8bsegVM6Kgs6bTA39mm9v+XOMMj9ou84lZ4Wbb25+NwSz ti1M1YxtHJ/4JUf0xL8W17/lQpMJ5FvdVVHeI6jUPjg04lwYgEoK5RSdZUOePcSRCMwJ eR4CnE9oqcbN83c4+UPwwjmVB3gdgs6UMmRVU= Received: by 10.220.47.220 with SMTP id o28mr588879vcf.218.1276342626061; Sat, 12 Jun 2010 04:37:06 -0700 (PDT) Received: from [192.168.0.86] ([187.39.15.144]) by mx.google.com with ESMTPS id p14sm949430vca.47.2010.06.12.04.37.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 12 Jun 2010 04:37:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Luiz Otavio O Souza In-Reply-To: <2D2B1168-4E11-4353-8856-FD2728413F1B@bluezbox.com> Date: Sat, 12 Jun 2010 08:36:59 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C6B899F-0361-4E20-A9C4-20C002A3CA1D@sg.org.ua> <2D2B1168-4E11-4353-8856-FD2728413F1B@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.1078) Cc: freebsd-mips@freebsd.org Subject: Re: RouterBOARD RB450G X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 12:05:43 -0000 On Jun 11, 2010, at 6:20 PM, Oleksandr Tymoshenko wrote: >=20 > On 2010-06-11, at 5:05 AM, Alexander Mogilny wrote: >=20 >> Hi all! >> I have recently purchased RB450G router and was not >> satisfied with RouterOS so I decided to install FreeBSD >> on this device. >> There are some issues with starting FreeBSD on this device >> so I would like to help community to fix some code and get >> this device working. >>=20 >> Default AR71XX kernel failed to boot. Boot process stopped >> at ohci device detection (it just hanged). When I commented >> it out in hints file I got following: >>=20 > .. skipped .. >>=20 >> As you can see ethernet card got incorrect ethernet address. >> What could cause this? Perhaps I can somehow give you some more >> debug information? > RouterBoard and Routerstation use different approaches for passing > device-dependent data (MAC address, memsize) to kernel. Routerstation > uses redboot that passes key-value pairs in environment memory area > while RouterBoard's own boot loader passes them as key-value pairs in = argv.=20 >=20 > Some minor hackery required to get it working. It's not done yet = because I=20 > didn't have a chance to get my hands on AR71XX-based routerboard :)=20 Gonzo, I 've most of the trivial fixes for routerboards, just give me a few = days to extract the current patches. My old stuff can be found on: http://loos.no-ip.org:280/routerboard/ The missing bits are: nand (the driver is ported, but i need more -free- = time to sort out the FS layer), sd/mmc card slot (connected to spi bus) = and the ethernet switch (useful on RG450(g) which have 4 ports connected = to switch). Luiz= From owner-freebsd-mips@FreeBSD.ORG Sat Jun 12 20:02:31 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DA58106578D for ; Sat, 12 Jun 2010 20:02:31 +0000 (UTC) (envelope-from sg@sg.org.ua) Received: from mail.redtram.com (mail.redtram.com [213.186.114.162]) by mx1.freebsd.org (Postfix) with ESMTP id 3983E8FC15 for ; Sat, 12 Jun 2010 20:02:30 +0000 (UTC) Received: from [89.252.19.57] (helo=[192.168.100.11]) by mail.redtram.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONWb3-0006N8-Eo; Sat, 12 Jun 2010 22:42:25 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Alexander Mogilny In-Reply-To: Date: Sat, 12 Jun 2010 22:41:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C6B899F-0361-4E20-A9C4-20C002A3CA1D@sg.org.ua> <2D2B1168-4E11-4353-8856-FD2728413F1B@bluezbox.com> To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1078) Cc: freebsd-mips@freebsd.org Subject: Re: RouterBOARD RB450G X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 20:02:31 -0000 On Jun 12, 2010, at 2:36 PM, Luiz Otavio O Souza wrote: > Gonzo, >=20 > I 've most of the trivial fixes for routerboards, just give me a few = days to extract the current patches. >=20 > My old stuff can be found on: http://loos.no-ip.org:280/routerboard/ >=20 > The missing bits are: nand (the driver is ported, but i need more = -free- time to sort out the FS layer), sd/mmc card slot (connected to = spi bus) and the ethernet switch (useful on RG450(g) which have 4 ports = connected to switch). >=20 Great! I will try this on Monday as soon as I get to device and let you = know if it worked for me.