From owner-freebsd-mips@FreeBSD.ORG Sun Feb 20 18:48:46 2011 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 E0DCD1065696; Sun, 20 Feb 2011 18:48:45 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by mx1.freebsd.org (Postfix) with ESMTP id EB9BD8FC1A; Sun, 20 Feb 2011 18:48:42 +0000 (UTC) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTWFiCbD4mOU4xK/P+yQklwgJfHlBmmhV@postini.com; Sun, 20 Feb 2011 10:48:45 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 20 Feb 2011 10:48:10 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sun, 20 Feb 2011 13:48:40 -0500 From: Andrew Duane To: Juli Mallett , Warner Losh Date: Sun, 20 Feb 2011 13:43:51 -0500 Thread-Topic: Bootstraps for Mips/OCTEON platforms Thread-Index: AcvPwACNR8o8VtVKSaGKc5y2yvJtYABbh3z8 Message-ID: References: <4D5EF8CA.5010008@bsdimp.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-mips@freebsd.org" Subject: RE: Bootstraps for Mips/OCTEON platforms 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, 20 Feb 2011 18:48:46 -0000 Oh well, looks like I have (another) complicated shim layer to write..... We use standard ELF, and have both U-Boot and a simple embedded bootstrap (= J-Boot) on different platforms. Neither one uses the Cavium HW descriptor, = as the bootstraps support other MIPS-family chips besides Cavium. Also, sad= ly, they use a different calling convention with slightly different things = in registers A0-A3. U-Boot had already gone it's own way with a separate en= try point, and once firmware is flashed into released platforms, it's effec= tively impossible to change the interface like that. I'll put on my thinking hat and try to decide what to do about this. I'm gu= essing a new shim entry point that figures out our U-Boot versus J-Boot and= tries to construct the right things for platform_start(). I'd like to say = this is something I haven't had to do before, but....... -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr aduane@juniper.net Westford, MA 01886-3418 ________________________________________ From: owner-freebsd-mips@freebsd.org [owner-freebsd-mips@freebsd.org] On Be= half Of Juli Mallett [jmallett@freebsd.org] Sent: Friday, February 18, 2011 6:02 PM To: Warner Losh Cc: freebsd-mips@freebsd.org Subject: Re: Bootstraps for Mips/OCTEON platforms On Fri, Feb 18, 2011 at 14:55, Warner Losh wrote: > On 02/18/2011 12:08, Andrew Duane wrote: >> >> I'm starting at ground zero (almost) with an Octeon based platform relat= ed >> to the OCTEON1 config in the -CURRENT. The board uses an existing MIPS >> bootstrap and loader, but that does not seem to be compatible with what = the >> kernel expects. What bootstrap is used normally? u-boot? > > u-boot is what we support. There's no other support in the codebase righ= t > now. uboot gives us: > > in a3 is passed in the cavium hardware descriptor. All other registers a= re > ignored on boot. We only support version 6 and newer of the boot > descriptor. You can see the details of the structure in > sys/mips/cavium/octeon_machdep.c starting with platform_start(). It's worth noting that we don't use the Simple Executive ELF Application calling convention but the Octeon Linux one, so 'bootoctlinux' should be used instead of 'bootoctelf'. Juli. _______________________________________________ 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 Tue Feb 22 01:38:54 2011 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 1DC1310656C1 for ; Tue, 22 Feb 2011 01:38:54 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id C81218FC12 for ; Tue, 22 Feb 2011 01:38:53 +0000 (UTC) Received: by mail-qw0-f54.google.com with SMTP id 8so501519qwj.13 for ; Mon, 21 Feb 2011 17:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=HcaDq1jqF8nPAzWIm4eHX1LfK8G3I6203mp4rOWOHvg=; b=TgsDGFn4dms5ZdiGT6RJTPB4p8OnnpeN9g0lfRJW97j4mgO1InPT4VQQ88i0hL9lLs yWy6xcg3i7NWhuRYMFclfM6gD8IkNEBzGKOGecANQt7KxACSyTsZq+G6AvQpGvCSP6ql KZXU3mCb7PjY3xUphPGR90URyyuslCaKsgDxA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=cZ8UQHedQHCWw6yoz8taoo93X0tM6cBlf+8qs6gC067o6zEg/FwC1iB38zsgmWXj/w Qf1v+n954PU/DugmsqCgLUPTMgcYChE15UddWq7OqG/1QX+kQkH7o3xBY+fc2QdMlhup UGXf2G4JWDP61TsuS3Mxq2jqpjz6sDRgGITEc= MIME-Version: 1.0 Received: by 10.229.232.3 with SMTP id js3mr1493569qcb.182.1298336877612; Mon, 21 Feb 2011 17:07:57 -0800 (PST) Sender: artemb@gmail.com Received: by 10.229.215.71 with HTTP; Mon, 21 Feb 2011 17:07:57 -0800 (PST) Date: Mon, 21 Feb 2011 17:07:57 -0800 X-Google-Sender-Auth: xYHLx-SBs-ethYyfi6S6eW6D5ng Message-ID: From: Artem Belevich To: Juli Mallett , "C. Jayachandran" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: lib/libc/mips/string/bzero.S -- problem in 64-bit mode. 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, 22 Feb 2011 01:38:54 -0000 Hi, I think htere's a problem with bzero implementation for 64-bit mips (SZREG==8). http://svn.freebsd.org/viewvc/base/head/lib/libc/mips/string/bzero.S?revision=209231&view=markup LEAF(bzero) .set noreorder blt a1, 3*SZREG, smallclr # small amount to clear? PTR_SUBU a3, zero, a0 # compute # bytes to word align address and a3, a3, SZREG-1 beq a3, zero, 1f # skip if word aligned #if SZREG == 4 PTR_SUBU a1, a1, a3 # subtract from remaining count SWHI zero, 0(a0) # clear 1, 2, or 3 bytes to align PTR_ADDU a0, a0, a3 #endif #if SZREG == 8 PTR_SUBU a1, a1, a3 # subtract from remaining count PTR_ADDU a0, a0, a3 # align dst to next word sll a3, a3, 3 # bits to bytes li a2, -1 # make a mask #if _BYTE_ORDER == _BIG_ENDIAN (a) REG_SRLV a2, a2, a3 # we want to keep the MSB bytes #endif #if _BYTE_ORDER == _LITTLE_ENDIAN (b) REG_SLLV a2, a2, a3 # we want to keep the LSB bytes #endif (c) nor a2, zero, a2 # complement the mask REG_L v0, -SZREG(a0) # load the word to partially clear and v0, v0, a2 # clear the bytes REG_S v0, -SZREG(a0) # store it back #endif Let's suppose we're trying to bzero something at 0x1234567. A3 will contain number of bytes *remaining* until register-aligned address. I.e. 1 in this case. When we make it to (c) on big-endian platforms A2=0x00FFFFFF_FFFFFFFF and on little-endianA2=0xFFFFFFFF_FFFFFF00. after (c) it's 0xFF000000_00000000 and 0x00000000_000000FF correspondingly, unless I've got NOR semantics wrong. Now we load register, AND it with a2 and write the result back. It does not look right -- we're clearing *7* bytes instead of only one and clobber the data that preceeds the start address. I believe correct code should look like this: #if SZREG == 8 PTR_SUBU a1, a1, a3 # subtract from remaining count PTR_ADDU a0, a0, a3 # align dst to next word sll a3, a3, 3 # bits to bytes li a2, -1 # make a mask #if _BYTE_ORDER == _BIG_ENDIAN REG_SLLV a2, a2, a3 # we want to keep the MSB bytes #endif #if _BYTE_ORDER == _LITTLE_ENDIAN REG_SRLV a2, a2, a3 # we want to keep the LSB bytes #endif REG_L v0, -SZREG(a0) # load the word to partially clear and v0, v0, a2 # clear the bytes REG_S v0, -SZREG(a0) # store it back #endif One thing I don't quite understand is -- why do we bother with all this manual masking at all? Why not just use REG_SHI for both SZREG==4 and SZREG==8 cases? If I read the code I quoted above correctly, it attempts to emulate SDL/SDR instructions. Using REG_SHI macro would pick correct swl/swr/sdl/sdr variant based on register size and endianness and would clear the unaligned bytes. PTR_SUBU a1, a1, a3 # subtract from remaining count REG_SHI zero, 0(a0) # clear 1..SZREG-1 bytes to align PTR_ADDU a0, a0, a3 Thanks, --Artem From owner-freebsd-mips@FreeBSD.ORG Tue Feb 22 05:04:20 2011 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 5243F106566C; Tue, 22 Feb 2011 05:04:20 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7B1B68FC17; Tue, 22 Feb 2011 05:04:19 +0000 (UTC) Received: by wyb32 with SMTP id 32so2559288wyb.13 for ; Mon, 21 Feb 2011 21:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8Wlx3yyCJ2qSywBzxaaGfSBKSRwyvRUq4sHxJ5HyjcI=; b=mP0qL4JcDLX33sFIMRAU1rOdiYtArkf5prjZF2OyIsnKTBpr4wusM3APIe0nf4nPro qafZF1DcZf4rhEV14nwq/qZ5CSyC1VVKl02LKytjXbE7+pMnZD90MyyR9yL6mFKVZGEz KORt1ONVrg7nvbyA2OakiZttqDBhx6qVz/sYg= 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=dtuHV4FmFFlFojolA7kOAE4KExgpEkhxRgj94mI/eDUsftBw71jZSAFh83LAo8PEU3 TwsDB/6TAL+E8w/T+1XFBUWud3L8nqWPoX82I26sL5FishDhR/vlwIZvagjCDZs42ky4 hv5C8F33ciuZeLIETKqGAd/1Q3gVenyW6GbXg= MIME-Version: 1.0 Received: by 10.227.144.196 with SMTP id a4mr1923002wbv.122.1298351058000; Mon, 21 Feb 2011 21:04:18 -0800 (PST) Received: by 10.227.132.144 with HTTP; Mon, 21 Feb 2011 21:04:17 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Feb 2011 10:34:17 +0530 Message-ID: From: "Jayachandran C." To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: lib/libc/mips/string/bzero.S -- problem in 64-bit mode. 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, 22 Feb 2011 05:04:20 -0000 On Tue, Feb 22, 2011 at 6:37 AM, Artem Belevich wrote: > Hi, > > I think htere's a problem with bzero implementation for 64-bit mips (SZRE= G=3D=3D8). > > http://svn.freebsd.org/viewvc/base/head/lib/libc/mips/string/bzero.S?revi= sion=3D209231&view=3Dmarkup > > LEAF(bzero) > =A0 =A0 =A0 =A0.set =A0 =A0noreorder > =A0 =A0 =A0 =A0blt =A0 =A0 =A0 =A0 =A0 =A0 a1, 3*SZREG, smallclr # small = amount to clear? > =A0 =A0 =A0 =A0PTR_SUBU =A0 =A0 =A0 =A0a3, zero, a0 =A0 =A0# compute # by= tes to word align address > =A0 =A0 =A0 =A0and =A0 =A0 =A0 =A0 =A0 =A0 a3, a3, SZREG-1 > =A0 =A0 =A0 =A0beq =A0 =A0 =A0 =A0 =A0 =A0 a3, zero, 1f =A0 =A0# skip if = word aligned > #if SZREG =3D=3D 4 > =A0 =A0 =A0 =A0PTR_SUBU =A0 =A0 =A0 =A0a1, a1, a3 =A0 =A0 =A0# subtract f= rom remaining count > =A0 =A0 =A0 =A0SWHI =A0 =A0 =A0 =A0 =A0 =A0zero, 0(a0) =A0 =A0 # clear 1,= 2, or 3 bytes to align > =A0 =A0 =A0 =A0PTR_ADDU =A0 =A0 =A0 =A0a0, a0, a3 > #endif > > #if SZREG =3D=3D 8 > =A0 =A0 =A0 =A0PTR_SUBU =A0 =A0 =A0 =A0a1, a1, a3 =A0 =A0 =A0# subtract f= rom remaining count > =A0 =A0 =A0 =A0PTR_ADDU =A0 =A0 =A0 =A0a0, a0, a3 =A0 =A0 =A0# align dst = to next word > =A0 =A0 =A0 =A0sll =A0 =A0 =A0 =A0 =A0 =A0 a3, a3, 3 =A0 =A0 =A0 # bits t= o bytes > =A0 =A0 =A0 =A0li =A0 =A0 =A0 =A0 =A0 =A0 =A0a2, -1 =A0 =A0 =A0 =A0 =A0# = make a mask > #if _BYTE_ORDER =3D=3D _BIG_ENDIAN > (a) =A0 =A0 REG_SRLV =A0 =A0 =A0 =A0a2, a2, a3 =A0 =A0 =A0# we want to ke= ep the MSB bytes > #endif > #if _BYTE_ORDER =3D=3D _LITTLE_ENDIAN > (b) =A0 =A0 REG_SLLV =A0 =A0 =A0 =A0a2, a2, a3 =A0 =A0 =A0# we want to ke= ep the LSB bytes > #endif > (c) =A0 =A0 nor =A0 =A0 =A0 =A0 =A0 =A0 a2, zero, a2 =A0 =A0# complement = the mask > =A0 =A0 =A0 =A0REG_L =A0 =A0 =A0 =A0 =A0 v0, -SZREG(a0) =A0# load the wor= d to partially clear > =A0 =A0 =A0 =A0and =A0 =A0 =A0 =A0 =A0 =A0 v0, v0, a2 =A0 =A0 =A0# clear = the bytes > =A0 =A0 =A0 =A0REG_S =A0 =A0 =A0 =A0 =A0 v0, -SZREG(a0) =A0# store it bac= k > #endif > > Let's suppose we're trying to bzero something at 0x1234567. =A0A3 will > contain number of bytes *remaining* until register-aligned address. > I.e. 1 in this case. > When we make it to (c) on big-endian platforms A2=3D0x00FFFFFF_FFFFFFFF > and on little-endianA2=3D0xFFFFFFFF_FFFFFF00. > after (c) it's 0xFF000000_00000000 and 0x00000000_000000FF > correspondingly, unless I've got NOR semantics wrong. > > Now we load register, AND it with a2 and write the result back. It > does not look right -- we're clearing *7* bytes instead of only one > and clobber the data that preceeds the start address. > > I believe correct code should look like this: > > #if SZREG =3D=3D 8 > =A0 =A0 =A0 =A0PTR_SUBU =A0 =A0 =A0 =A0a1, a1, a3 =A0 =A0 =A0# subtract f= rom remaining count > =A0 =A0 =A0 =A0PTR_ADDU =A0 =A0 =A0 =A0a0, a0, a3 =A0 =A0 =A0# align dst = to next word > =A0 =A0 =A0 =A0sll =A0 =A0 =A0 =A0 =A0 =A0 a3, a3, 3 =A0 =A0 =A0 # bits t= o bytes > =A0 =A0 =A0 =A0li =A0 =A0 =A0 =A0 =A0 =A0 =A0a2, -1 =A0 =A0 =A0 =A0 =A0# = make a mask > #if _BYTE_ORDER =3D=3D _BIG_ENDIAN > =A0 =A0 =A0 =A0REG_SLLV =A0 =A0 =A0 =A0a2, a2, a3 =A0 =A0 =A0# we want to= keep the MSB bytes > #endif > #if _BYTE_ORDER =3D=3D _LITTLE_ENDIAN > =A0 =A0 =A0 =A0REG_SRLV =A0 =A0 =A0 =A0a2, a2, a3 =A0 =A0 =A0# we want to= keep the LSB bytes > #endif > =A0 =A0 =A0 =A0REG_L =A0 =A0 =A0 =A0 =A0 v0, -SZREG(a0) =A0# load the wor= d to partially clear > =A0 =A0 =A0 =A0and =A0 =A0 =A0 =A0 =A0 =A0 v0, v0, a2 =A0 =A0 =A0# clear = the bytes > =A0 =A0 =A0 =A0REG_S =A0 =A0 =A0 =A0 =A0 v0, -SZREG(a0) =A0# store it bac= k > #endif > > One thing I don't quite understand is -- why do we bother with all > this manual masking at all? Why not just use REG_SHI for both SZREG=3D=3D= 4 > and SZREG=3D=3D8 cases? If I read the code I quoted above correctly, it > attempts to emulate SDL/SDR instructions. Using REG_SHI macro would > pick correct swl/swr/sdl/sdr variant based on register size and > endianness and would clear the unaligned bytes. > > =A0 =A0 =A0 =A0PTR_SUBU =A0 =A0 =A0 =A0a1, a1, a3 =A0 =A0 =A0# subtract f= rom remaining count > =A0 =A0 =A0 =A0REG_SHI zero, 0(a0) =A0 =A0 # clear 1..SZREG-1 bytes to al= ign > =A0 =A0 =A0 =A0PTR_ADDU =A0 =A0 =A0 =A0a0, a0, a3 I just tested this with a simple program - and there is certainly an issue here. If you can send me a patch, I can check that in after testing. The kernel version of bzero() does not seem to have the SZREG=3D=3D8 case, and this bug. Thanks, JC. From owner-freebsd-mips@FreeBSD.ORG Tue Feb 22 05:39:11 2011 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 2E9FC1065679; Tue, 22 Feb 2011 05:39:11 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 467788FC14; Tue, 22 Feb 2011 05:39:10 +0000 (UTC) Received: by qyk35 with SMTP id 35so1717607qyk.13 for ; Mon, 21 Feb 2011 21:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eDl91hKHtw/gSk3MdUR4pl09fiP1naTznA0HLk4e0aA=; b=GBqr6rZXsoth+M1HBlBGoqnhTWJJPkxSaV6gEI5rmXy6lfSBCTTXxkyEGlJCgf6n9b B8rQgLykpntMSP2Sq1Rjfpd/eTURAY3ZFwAOD5ryNKiyIBBBEfKv9uYd8NAPKPQuN20g 21XuOelHxFnAQ6iL20w77FoWaKXtZZw1kyRIw= 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; b=DelUr5aLPVwGk7205hq6LFFp4G3chCl8CJdHVlDxjfHEmRDpdPja45mVWRKiQ+Wm1W SZPoNyC2q8EI/vIpq0hwnaQv3lQbSrS9M2kZ3uiGS1XDNRJDKX3tjeWYjmuUUC1l8me/ yFwQfGoGr36oCbq1o9g1KZ1x77Q1X5l46Es/c= MIME-Version: 1.0 Received: by 10.229.181.78 with SMTP id bx14mr1618123qcb.296.1298353149490; Mon, 21 Feb 2011 21:39:09 -0800 (PST) Sender: artemb@gmail.com Received: by 10.229.215.71 with HTTP; Mon, 21 Feb 2011 21:39:09 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Feb 2011 21:39:09 -0800 X-Google-Sender-Auth: GH8AtoNeSbhoh4PhGE05iOCRG8k Message-ID: From: Artem Belevich To: "Jayachandran C." Content-Type: multipart/mixed; boundary=00163630fe5544b6a5049cd8662e Cc: freebsd-mips@freebsd.org Subject: Re: lib/libc/mips/string/bzero.S -- problem in 64-bit mode. 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, 22 Feb 2011 05:39:11 -0000 --00163630fe5544b6a5049cd8662e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > I just tested this with a simple program - and there is certainly an > issue here. =A0If you can send me a patch, I can check that in after > testing. Try attached diff. > The kernel version of bzero() does not seem to have the SZREG=3D=3D8 case= , > and this bug. True. It still uses 32-bit sw to zero stuff out. There are number of routines in the kernel that could take advantage of 64-bit instructions. --Artem --00163630fe5544b6a5049cd8662e Content-Type: application/octet-stream; name="bzero.diff" Content-Disposition: attachment; filename="bzero.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gkgdtiph0 ZGlmZiAtLWdpdCBhL2xpYi9saWJjL21pcHMvc3RyaW5nL2J6ZXJvLlMgYi9saWIvbGliYy9taXBz L3N0cmluZy9iemVyby5TCmluZGV4IDY2ZjI5ZGQuLjgzZTU0YmEgMTAwNjQ0Ci0tLSBhL2xpYi9s aWJjL21pcHMvc3RyaW5nL2J6ZXJvLlMKKysrIGIvbGliL2xpYmMvbWlwcy9zdHJpbmcvYnplcm8u UwpAQCAtNTgsMjcgKzU4LDkgQEAgTEVBRihiemVybykKIAlQVFJfU1VCVQlhMywgemVybywgYTAJ IyBjb21wdXRlICMgYnl0ZXMgdG8gd29yZCBhbGlnbiBhZGRyZXNzCiAJYW5kCQlhMywgYTMsIFNa UkVHLTEKIAliZXEJCWEzLCB6ZXJvLCAxZgkjIHNraXAgaWYgd29yZCBhbGlnbmVkCi0jaWYgU1pS RUcgPT0gNAogCVBUUl9TVUJVCWExLCBhMSwgYTMJIyBzdWJ0cmFjdCBmcm9tIHJlbWFpbmluZyBj b3VudAotCVNXSEkJCXplcm8sIDAoYTApCSMgY2xlYXIgMSwgMiwgb3IgMyBieXRlcyB0byBhbGln bgorCVJFR19TSEkJCXplcm8sIDAoYTApCSMgY2xlYXIgMSwgMiwgb3IgMyBieXRlcyB0byBhbGln bgogCVBUUl9BRERVCWEwLCBhMCwgYTMKLSNlbmRpZgotI2lmIFNaUkVHID09IDgKLQlQVFJfU1VC VQlhMSwgYTEsIGEzCSMgc3VidHJhY3QgZnJvbSByZW1haW5pbmcgY291bnQKLQlQVFJfQUREVQlh MCwgYTAsIGEzCSMgYWxpZ24gZHN0IHRvIG5leHQgd29yZAotCXNsbAkJYTMsIGEzLCAzCSMgYml0 cyB0byBieXRlcwotCWxpCQlhMiwgLTEJCSMgbWFrZSBhIG1hc2sKLSNpZiBfQllURV9PUkRFUiA9 PSBfQklHX0VORElBTgotCVJFR19TUkxWCWEyLCBhMiwgYTMJIyB3ZSB3YW50IHRvIGtlZXAgdGhl IE1TQiBieXRlcwotI2VuZGlmCi0jaWYgX0JZVEVfT1JERVIgPT0gX0xJVFRMRV9FTkRJQU4KLQlS RUdfU0xMVglhMiwgYTIsIGEzCSMgd2Ugd2FudCB0byBrZWVwIHRoZSBMU0IgYnl0ZXMKLSNlbmRp ZgotCW5vcgkJYTIsIHplcm8sIGEyCSMgY29tcGxlbWVudCB0aGUgbWFzawotCVJFR19MCQl2MCwg LVNaUkVHKGEwKQkjIGxvYWQgdGhlIHdvcmQgdG8gcGFydGlhbGx5IGNsZWFyCi0JYW5kCQl2MCwg djAsIGEyCSMgY2xlYXIgdGhlIGJ5dGVzCi0JUkVHX1MJCXYwLCAtU1pSRUcoYTApCSMgc3RvcmUg aXQgYmFjawotI2VuZGlmCiAxOgogCWFuZAkJdjAsIGExLCBTWlJFRy0xCSMgY29tcHV0ZSBudW1i ZXIgb2Ygd29yZHMgbGVmdAogCVBUUl9TVUJVCWEzLCBhMSwgdjAK --00163630fe5544b6a5049cd8662e-- From owner-freebsd-mips@FreeBSD.ORG Tue Feb 22 08:03:58 2011 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 CDEB21065672; Tue, 22 Feb 2011 08:03:58 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id F21968FC16; Tue, 22 Feb 2011 08:03:57 +0000 (UTC) Received: by wwf26 with SMTP id 26so6777185wwf.31 for ; Tue, 22 Feb 2011 00:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BPPKai03wHYTdVzkxldv+nZrX+1MchNDHbux4re2vYI=; b=Cn+F7gzBiv2+L4KIWjWXxwzGXMy2KFHAaUn8PPLOfuMf0Do1wE+vEVU6h9Dz0sW6UK Effqf7cevkAs218ovR8sWjVvoj7NOZ4lBuwlgkQ76rcTB7Dj9RJ5PmlaUv14NV+f0zGP 4SEUShjCzbyQBC0gkS4d8ZBKC+ymavyhozL+c= 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=fwdzCPpfWv2fy2+zoluNJCLuKCTb7atxvsH/KaQzSLWM79HxV1otBAjqZEjHbDFXtK aOIF0YXRtDG2xNqpCawGH9FS1NhUbGs/kqEU+MBENQfEuLJhfCOOGKt3RRVRsuErQSoC Rf9KmefoDw+5z3iNmnj/ggOX/V3dwhFgQQ/Mw= MIME-Version: 1.0 Received: by 10.227.137.5 with SMTP id u5mr2036675wbt.6.1298361836320; Tue, 22 Feb 2011 00:03:56 -0800 (PST) Received: by 10.227.132.144 with HTTP; Tue, 22 Feb 2011 00:03:56 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Feb 2011 13:33:56 +0530 Message-ID: From: "Jayachandran C." To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: lib/libc/mips/string/bzero.S -- problem in 64-bit mode. 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, 22 Feb 2011 08:03:58 -0000 On Tue, Feb 22, 2011 at 11:09 AM, Artem Belevich wrote: >> I just tested this with a simple program - and there is certainly an >> issue here. =A0If you can send me a patch, I can check that in after >> testing. > > Try attached diff. Thanks! The patch is checked in now: | New Revision: 218939 | URL: http://svn.freebsd.org/changeset/base/218939 | | Log: | Fix bzero() for 64-bit. | | The existing implementation of bzero incorrectly clears bytes when the | start address is not word aligned. Fix it by using REG_SHI macro which | works on both 32 and 64 bit. | | Submitted by: Artem Belevich (fbsdlist at src cx) >> The kernel version of bzero() does not seem to have the SZREG=3D=3D8 cas= e, >> and this bug. > > True. It still uses 32-bit sw to zero stuff out. There are number of > routines in the kernel that could take advantage of 64-bit > instructions. I have not really looked at assembly for bcopy/bcmp/bzero for kernel or user space for 64 bit optimizations yet.. JC. From owner-freebsd-mips@FreeBSD.ORG Fri Feb 25 02:25:40 2011 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 37B1B1065670 for ; Fri, 25 Feb 2011 02:25:40 +0000 (UTC) (envelope-from patryczek96@os.pl) Received: from poczta.os.pl (saturn.os.pl [94.23.226.202]) by mx1.freebsd.org (Postfix) with ESMTP id 972868FC0C for ; Fri, 25 Feb 2011 02:25:39 +0000 (UTC) Received: (qmail 15075 invoked by uid 98); 25 Feb 2011 01:52:36 -0000 Received: from unknown (HELO Patryk-Notebook) (patryczek96@os.pl@84.205.7.118) by 0 with ESMTPA; 25 Feb 2011 01:52:36 -0000 Message-ID: <027b0a5b-40599-225b1205981481@patryk-notebook> From: "Patryk" To: freebsd-mips@freebsd.org Date: Fri, 25 Feb 2011 02:53:39 +0100 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Priority: 3 X-Mailer: Office Outlook X-MimeOLE: Produced by Office Outlook Subject: Prosba 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, 25 Feb 2011 02:25:40 -0000 Witam serdecznie. Na początku wiadomości, bardzo prosiłbym o poświęcenie mi chwili czasu, gdyż zwracam się z nietypową prośbą. Państwa adres napotkałem w internecie, co dowodzi jego dobrej pozycji w katalogach teleadresowych. Mam 15 lat, interesuje sie informatyką, uwielbiam zwierzęta, a od pewnego czasu mam inne hobby, mianowicie - kolekcjonuję gadżety reklamowe oraz próbki różnych produktów. Zacząłem zajmować się tym około roku temu. W mojej kolekcji znajdują się różnorodne przedmioty - od smyczy, długopisów, breloków do kubków, koszulek i pendrive'ów. Zbiory można zobaczyć na moim kanale YouTube (http://youtube.com/PatryczQ96) oraz na mojej stronie internetowej - http://kolekcja.darmowki.eu . Bardzo chciałbym, aby moja kolekcja powiększyła sie o kolejne. W związku z tym zwracam się do Państwa z ogromną prośbą o przesłanie mi kilku gadżetów promocyjnych w celu wzbogacenia mojej kolekcji. Może to się wydawać dziwne i od razu nasuwa się pytanie: "Po co mi to?", ale ja odpowiem "Niektórzy zbierają znaczki, inni monety, a ja - gadżety" - dlatego ośmielam się skierować do Państwa tą prośbę. Z wielką chęcią, przyjemnością oraz dumą dołączyłbym do swojej kolekcji podarunek od Was. Mój adres: Patryk Sikora ul.Słowiańska 8a/16 78-400 Szczecinek Z poważaniem Patryk Ps. Przepraszam za ewntualne duplikaty maili skierowanych do Państwa - mam problemy z programem pocztowym. Ps2. Proszę o wysyłanie gadżetów w kopertach bąbelkowych, zapewni to bezpieczny transport oraz mi zabawę - lubię postrzelać folią zawartą w takich kopertach ;) ------ A ja adresik to mam w adresik.pl a hosting na klatka.pl From owner-freebsd-mips@FreeBSD.ORG Fri Feb 25 14:41:02 2011 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 44A61106566C for ; Fri, 25 Feb 2011 14:41:02 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0E0C58FC15 for ; Fri, 25 Feb 2011 14:41:01 +0000 (UTC) Received: by iyj12 with SMTP id 12so1047805iyj.13 for ; Fri, 25 Feb 2011 06:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=LR2JebFYBWNivklllnbPiEht+pJJQROz6bHjil8BUcE=; b=eR8KhychE+R+N8XnqYHvYZvEdAEVR5ZuR9BPk8GGpaqDAV/WngKnJB4Y9U+OuG5QMz wnISIurxIXXHwGrVEmml4kkB1gEoMpo85yGcpAq9SS7XwdYDABL0W8YCBk0OkeFZFERu sW+OTSNjACfCV/HBKY6SbW84FQidvLFDq6qlc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=X646B7mvPuXnIBCuFISwwEZIURtZ7Lw1hoEKQBTPoWyKTWeDH3uzKW8hA8DrLKpeI7 mTGT0tyROs9hopdA3W12EZAl1TeyqAZBHCP0zg78QYGhES+X7CSOvW5ETtWPhVezQxss R45JCpokl3B7eSvagirG3MXw+iCLMj2IP5vtg= MIME-Version: 1.0 Received: by 10.42.173.199 with SMTP id s7mr843685icz.85.1298644859737; Fri, 25 Feb 2011 06:40:59 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.231.169.134 with HTTP; Fri, 25 Feb 2011 06:40:59 -0800 (PST) Date: Fri, 25 Feb 2011 15:40:59 +0100 X-Google-Sender-Auth: J44rVXCku9hRyc6tUUMU6X8W5Qs Message-ID: From: Robert Millan To: debian-bsd@lists.debian.org, debian-mips@lists.debian.org, freebsd-mips@freebsd.org, libc-ports@sourceware.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: glibc port to kfreebsd/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, 25 Feb 2011 14:41:02 -0000 This is work in progress: http://wiki.debian.org/Debian_GNU/kFreeBSD_MIPS The good: - Basic userland working. Tested: bash, coreutils, gdb, make, binutils, gcc The bad: - Static binaries only; Dynamic linker crashes (both ld.so and libdl, although libdl works for small objects). - NSS (hence getpwuid et al) crashes as it relies on libdl. - TLS not implemented as it requires some kernel fixes first. - Thread support not implemented either (but LinuxThreads is needed for build). The ugly: - Doesn't work on QEMU yet (gxemul works though). -- Robert Millan From owner-freebsd-mips@FreeBSD.ORG Fri Feb 25 15:29:20 2011 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 BB06F1065679 for ; Fri, 25 Feb 2011 15:29:20 +0000 (UTC) (envelope-from carlos@codesourcery.com) Received: from mail.codesourcery.com (mail.codesourcery.com [38.113.113.100]) by mx1.freebsd.org (Postfix) with ESMTP id 8584F8FC19 for ; Fri, 25 Feb 2011 15:29:20 +0000 (UTC) Received: (qmail 4161 invoked from network); 25 Feb 2011 15:29:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (carlos@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Feb 2011 15:29:19 -0000 Message-ID: <4D67CAD0.5020604@codesourcery.com> Date: Fri, 25 Feb 2011 10:29:20 -0500 From: Carlos O'Donell Organization: Mentor Graphics / CodeSourcery User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Robert Millan References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 110225-0, 02/25/2011), Outbound message X-Antivirus-Status: Clean Cc: debian-mips@lists.debian.org, libc-ports@sourceware.org, freebsd-mips@freebsd.org, debian-bsd@lists.debian.org Subject: Re: glibc port to kfreebsd/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, 25 Feb 2011 15:29:20 -0000 On 2/25/2011 9:40 AM, Robert Millan wrote: > This is work in progress: http://wiki.debian.org/Debian_GNU/kFreeBSD_MIPS Cool! > The good: > > - Basic userland working. Tested: bash, coreutils, gdb, make, binutils, gcc > > The bad: > > - Static binaries only; Dynamic linker crashes (both ld.so and libdl, > although libdl works for small objects). > - NSS (hence getpwuid et al) crashes as it relies on libdl. > - TLS not implemented as it requires some kernel fixes first. > - Thread support not implemented either (but LinuxThreads is needed for build). Please don't use LinuxThreads for a new port. It is unmaintained. Is there any reason you aren't using NPTL? Lack of futex-compatible syscall? > The ugly: > > - Doesn't work on QEMU yet (gxemul works though). > Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos@codesourcery.com +1 (650) 331-3385 x716 From owner-freebsd-mips@FreeBSD.ORG Fri Feb 25 16:18:45 2011 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 74458106566B for ; Fri, 25 Feb 2011 16:18:45 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 394448FC0C for ; Fri, 25 Feb 2011 16:18:44 +0000 (UTC) Received: by iwn33 with SMTP id 33so1360271iwn.13 for ; Fri, 25 Feb 2011 08:18:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aMHP0dDp6r2VKwUkhl/iSO0FYCEV5YLeqLOaUsTEABw=; b=q3t9C9xytVFQ+Y5miVKzEPnqN3xrehE5Flu3p5+2vTsknstHw4X43QkFtmyFCGiH6v +i0rpcnXd97mXjrYI4cD5zryTd+vW5bGgavlbZo525xEj3kjZ+XmXypcy62xtY8TS3mJ wFd7AM495taekPY4mhKCHKHV9/KAuRhKNb2BA= 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; b=CCsWNP2WiSCDRGt7b0TkinS33m+WlIuI9/YN4bqUt26IoB6NXgAjAixnN3grTvnUFD a9ofcphuHb/a9foq7A7mA5k/GNApOJBA3109DZPQ2mXIzBxnZ3xnrVJ5CXey0PZNQ9Lj wS17JdGQZOw2iqTpBk6gG/CJrNPJWylsKSdxo= MIME-Version: 1.0 Received: by 10.231.31.4 with SMTP id w4mr2979647ibc.140.1298650724569; Fri, 25 Feb 2011 08:18:44 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.231.169.134 with HTTP; Fri, 25 Feb 2011 08:18:44 -0800 (PST) In-Reply-To: <4D67CAD0.5020604@codesourcery.com> References: <4D67CAD0.5020604@codesourcery.com> Date: Fri, 25 Feb 2011 17:18:44 +0100 X-Google-Sender-Auth: w2hgPKff5HzUt0A83a0lCIO4A7k Message-ID: From: Robert Millan To: "Carlos O'Donell" Content-Type: text/plain; charset=UTF-8 Cc: debian-mips@lists.debian.org, libc-ports@sourceware.org, freebsd-mips@freebsd.org, debian-bsd@lists.debian.org Subject: Re: glibc port to kfreebsd/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, 25 Feb 2011 16:18:45 -0000 2011/2/25 Carlos O'Donell : >> - Static binaries only; Dynamic linker crashes (both ld.so and libdl, >> although libdl works for small objects). >> - NSS (hence getpwuid et al) crashes as it relies on libdl. >> - TLS not implemented as it requires some kernel fixes first. >> - Thread support not implemented either (but LinuxThreads is needed for build). > > Please don't use LinuxThreads for a new port. It is unmaintained. I know, but other kfreebsd-gnu ports already use LinuxThreads, so getting it to build on mips*-kfreebsd-gnu was much easier this way. > Is there any reason you aren't using NPTL? Lack of futex-compatible > syscall? To be honest, I haven't really investigated if the syscalls used by FreeBSD userland (libkse and libthr) can be used to implement futex funcionality. I believe that porting NPTL to kernel of FreeBSD would require significant effort. Thanks -- Robert Millan From owner-freebsd-mips@FreeBSD.ORG Sat Feb 26 11:27:41 2011 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 A2464106566B; Sat, 26 Feb 2011 11:27:41 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E20E88FC0A; Sat, 26 Feb 2011 11:27:40 +0000 (UTC) Received: by wwb31 with SMTP id 31so3238570wwb.31 for ; Sat, 26 Feb 2011 03:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=URU7MDD+Gx4fqXPxKmmgAGdUOJLj8uRVpmUDBHwdnVY=; b=KxchaBlk6nH33gavr00/BBsL0l2SaCgvcToPHtULDFkvvYBk/roH7itBmn0S1bAEUW /5X9haEqZa+TFaMFoMKKh8ggYhrDj6u/9+ZogYI3FCkfJ4zNEavEnjJUNd7boIjdSfv/ jmBi9U6sTeQ1zJdIakfYY2fsf9McPYkvjS9Zc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sAH28tPIXRiJ4fHDx9QIO0z1hmh9sDn1kngONX26+BKe0wKbI8GYWeV5YIg2dt/Rj1 cokI51vHzMIf+RjnlN4pPauzeDZdIv09wtDEAY0teZH1yXUwAFytbUC/xcnc1Os5hZhy TQGOoxVDcrdFhxXNf/P5i+VQqroL9HI/z+E40= MIME-Version: 1.0 Received: by 10.227.137.140 with SMTP id w12mr3109452wbt.40.1298719659635; Sat, 26 Feb 2011 03:27:39 -0800 (PST) Received: by 10.227.132.144 with HTTP; Sat, 26 Feb 2011 03:27:39 -0800 (PST) Date: Sat, 26 Feb 2011 16:57:39 +0530 Message-ID: From: "Jayachandran C." To: freebsd-mips@freebsd.org, Juli Mallett , Warner Losh Content-Type: multipart/mixed; boundary=001636832e48f9b305049d2dbb8e Cc: Subject: [PATCH] stack usage of pmap_activate in cpu_switch() 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, 26 Feb 2011 11:27:41 -0000 --001636832e48f9b305049d2dbb8e Content-Type: text/plain; charset=ISO-8859-1 In the cpu_switch code, pmap_activate is called with the stack of the old thread even after the thread was switched out. This seems to be the cause of a crash I see here (on XLP) under stress. Seems like a bug to me, any thoughts? The attached patch restores the SP from the new thread from its PCB before calling pmap_activate(). JC. --001636832e48f9b305049d2dbb8e Content-Type: application/octet-stream; name="swtch.S.diff" Content-Disposition: attachment; filename="swtch.S.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gkmfwp5s0 SW5kZXg6IHN5cy9taXBzL21pcHMvc3d0Y2guUwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbWlwcy9taXBz L3N3dGNoLlMJKHJldmlzaW9uIDIxNzkyMikKKysrIHN5cy9taXBzL21pcHMvc3d0Y2guUwkod29y a2luZyBjb3B5KQpAQCAtMTk1LDExICsxOTUsNiBAQAogCVNBVkVfVV9QQ0JfQ09OVEVYVChyYSwg UFJFR19QQywgYTApCiAJbW92ZQlyYSwgdjAJCQkvKiByZXN0b3JlICdyYScgYmVmb3JlIHJldHVy bmluZyAqLwogCi0JLyoKLQkgKiBGUkVFQlNEX0RFVkVMT1BFUlNfRklYTUU6Ci0JICogSW4gY2Fz ZSB0aGVyZSBhcmUgQ1BVLXNwZWNpZmljIHJlZ2lzdGVycyB0aGF0IG5lZWQKLQkgKiB0byBiZSBz YXZlZCB3aXRoIHRoZSBvdGhlciByZWdpc3RlcnMgZG8gc28gaGVyZS4KLQkgKi8KIAlqCXJhCiAJ bW92ZQl2MCwgemVybwogRU5EKHNhdmVjdHgpCkBAIC0yNTQsMTEgKzI0OSw2IEBACiAJbm9wCiBn ZXRwYzoKIAlTQVZFX1VfUENCX0NPTlRFWFQocmEsIFBSRUdfUEMsIGEwKQkJIyBzYXZlIHJldHVy biBhZGRyZXNzCi0JLyoKLQkgKiBGUkVFQlNEX0RFVkVMT1BFUlNfRklYTUU6Ci0JICogSW4gY2Fz ZSB0aGVyZSBhcmUgQ1BVLXNwZWNpZmljIHJlZ2lzdGVycyB0aGF0IG5lZWQKLQkgKiB0byBiZSBz YXZlZCB3aXRoIHRoZSBvdGhlciByZWdpc3RlcnMgZG8gc28gaGVyZS4KLQkgKi8KIAogCVBUUl9T CWEyLCBURF9MT0NLKGEzKQkJCSMgU3dpdGNob3V0IHRkX2xvY2sgCiAKQEAgLTMyOCwxMyArMzE4 LDE1IEBACiAgKiBOb3cgcnVubmluZyBvbiBuZXcgdSBzdHJ1Y3QuCiAgKi8KIHN3MjoKKwlQVFJf TAlzMCwgVERfUENCKHM3KQorCVJFU1RPUkVfVV9QQ0JfQ09OVEVYVChzcCwgUFJFR19TUCwgczAp CiAJUFRSX0xBCXQxLCBfQ19MQUJFTChwbWFwX2FjdGl2YXRlKQkjIHM3ID0gbmV3IHByb2MgcG9p bnRlcgogCWphbHIJdDEJCQkJIyBzNyA9IG5ldyBwcm9jIHBvaW50ZXIKIAltb3ZlCWEwLCBzNwkJ CQkjIEJEU0xPVAogLyoKICAqIFJlc3RvcmUgcmVnaXN0ZXJzIGFuZCByZXR1cm4uCiAgKi8KLQlQ VFJfTAlhMCwgVERfUENCKHM3KQorCW1vdmUJYTAsIHMwCiAJUkVTVE9SRV9VX1BDQl9DT05URVhU KGdwLCBQUkVHX0dQLCBhMCkKIAlSRVNUT1JFX1VfUENCX0NPTlRFWFQodjAsIFBSRUdfU1IsIGEw KQkjIHJlc3RvcmUga2VybmVsIGNvbnRleHQKIAlSRVNUT1JFX1VfUENCX0NPTlRFWFQocmEsIFBS RUdfUkEsIGEwKQpAQCAtMzQ2LDEzICszMzgsOCBAQAogCVJFU1RPUkVfVV9QQ0JfQ09OVEVYVChz NSwgUFJFR19TNSwgYTApCiAJUkVTVE9SRV9VX1BDQl9DT05URVhUKHM2LCBQUkVHX1M2LCBhMCkK IAlSRVNUT1JFX1VfUENCX0NPTlRFWFQoczcsIFBSRUdfUzcsIGEwKQotCVJFU1RPUkVfVV9QQ0Jf Q09OVEVYVChzcCwgUFJFR19TUCwgYTApCiAJUkVTVE9SRV9VX1BDQl9DT05URVhUKHM4LCBQUkVH X1M4LCBhMCkKLQkvKgotCSAqIEZSRUVCU0RfREVWRUxPUEVSU19GSVhNRToKLQkgKiBJbiBjYXNl IHRoZXJlIGFyZSBDUFUtc3BlY2lmaWMgcmVnaXN0ZXJzIHRoYXQgbmVlZAotCSAqIHRvIGJlIHJl c3RvcmVkIHdpdGggdGhlIG90aGVyIHJlZ2lzdGVycyBkbyBzbyBoZXJlLgotCSAqLworCiAJbWZj MAl0MCwgTUlQU19DT1BfMF9TVEFUVVMKIAlhbmQJdDAsIHQwLCBNSVBTX1NSX0lOVF9NQVNLCiAJ YW5kCXYwLCB2MCwgfk1JUFNfU1JfSU5UX01BU0sK --001636832e48f9b305049d2dbb8e--