From owner-freebsd-mips@freebsd.org Sun Nov 13 08:13:27 2016 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2A5CC3F963 for ; Sun, 13 Nov 2016 08:13:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B365E96E for ; Sun, 13 Nov 2016 08:13:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x243.google.com with SMTP id q124so5934062itd.1 for ; Sun, 13 Nov 2016 00:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=nJ1644C5k7EElCV7NTTLe5hesaNQsySCzegHlm5JHNU=; b=qq0HBl+TcS2qxial7oESELaQh4o4vXi3ChEAo+jKpRjqqFzrO8hhWBrIjld6zo+wNR 09Y0cpp/igauMIKTRSqTTBY8P7bVzfeeLV0tSU8q16dak17F07w0HhqpdEbighR0oNq6 ITdUmwaVNRlwNIFkwUOQcxXbvLSiUhBNMc9awV2UmC7M78O7AJC4OFnk176n6QEKZSun vMjZpNPZnqfjyaZTP4rDKndvb8ly7KFwQRuhD0xWSOo/hQKsPjpbdl+t9fC33WZ+n0IE Jk33Zt0tn0Idk98xYABFwirpuF4ZIBpxQOeSAGm75ppqmlGiV/Uwtuvx5ZaH5sHhYyjb AsuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=nJ1644C5k7EElCV7NTTLe5hesaNQsySCzegHlm5JHNU=; b=SMCETORFpBs+eD/A//kdNBXxLFw9rjhH5fLzKAIio926PcoX/e/vqbCbdt+DWSD3no A5IogO72ngq6RpJpt+DHEUCDu3BLeXSuM0mqIhY6i5Fj6N0gKXJkQSrgDWj/umTIz7z9 q4qvhDf3U/oh6H5vMt8Zohqyt9hYZtufYcBpnu2PiZ6i7hxRFIq9WfuQ34ZCpeaxBHp3 tLTKyxp4cwm+EtpCSZOcwbiUyVDZ+DPg0sB3idrSU2SER7Ig0swO75xcLV4MsLrsoa2W vd15YZXf/W09v8YNU3UNT/kddr2L8cKbkBiec53JOASk//tB6CUQG3ZkTyolhVLpPPYZ GwQQ== X-Gm-Message-State: ABUngvc96W4DGMidwPbXaoADVpoV90shwL53fKf5QLrII6CBiTKJ9TuNN4h+iwl/ifEsmg== X-Received: by 10.36.69.134 with SMTP id c6mr2867188itd.102.1479024807127; Sun, 13 Nov 2016 00:13:27 -0800 (PST) Received: from mac-wired.nflx.bsdimp.com (50-253-99-174-static.hfc.comcastbusiness.net. [50.253.99.174]) by smtp.gmail.com with ESMTPSA id q66sm1900247iof.31.2016.11.13.00.13.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Nov 2016 00:13:26 -0800 (PST) Subject: Re: svn commit: r307626 - head/sys/ufs/ffs Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_070B6E65-8DF8-45E7-A09D-18C3A65DACF0"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Warner Losh In-Reply-To: <20161113075557.GH54029@kib.kiev.ua> Date: Sun, 13 Nov 2016 01:13:24 -0700 Cc: Warner Losh , Adrian Chadd , "freebsd-mips@freebsd.org" , Juli Mallett Message-Id: <71C512CD-0FB6-40D8-B46C-30467A245693@bsdimp.com> References: <201610191109.u9JB9TTC002727@repo.freebsd.org> <20161113065851.GD54029@kib.kiev.ua> <20161113071911.GF54029@kib.kiev.ua> <20161113075557.GH54029@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 08:13:28 -0000 --Apple-Mail=_070B6E65-8DF8-45E7-A09D-18C3A65DACF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [[ Moved to freebsd-mips and cc=E2=80=99d to Juli ]] > On Nov 13, 2016, at 12:55 AM, Konstantin Belousov = wrote: >=20 > On Sun, Nov 13, 2016 at 12:33:57AM -0700, Warner Losh wrote: >> On Sun, Nov 13, 2016 at 12:19 AM, Konstantin Belousov >> wrote: >>> On Sun, Nov 13, 2016 at 12:12:02AM -0700, Warner Losh wrote: >>>> On Sat, Nov 12, 2016 at 11:58 PM, Konstantin Belousov >>>> wrote: >>>>> On Sat, Nov 12, 2016 at 03:19:13PM -0800, Adrian Chadd wrote: >>>>>> hi! >>>>>>=20 >>>>>> This broke freebsd on mips24k. >>>>>>=20 >>>>>> BAD_PAGE_FAULT: pid 1 tid 100001 (init), uid 0: pc 0x4002a4 got a = read >>>>>> fault (type 0x2) at 0 >>>>>> Trapframe Register Dump: >>>>>> zero: 0 at: 0 v0: 0 v1: 0 >>>>>> a0: 0x7fffeecc a1: 0 a2: 0 a3: 0 >>>>>> t0: 0 t1: 0 t2: 0 t3: 0 >>>>>> t4: 0 t5: 0 t6: 0 t7: 0 >>>>>> t8: 0 t9: 0x400260 s0: 0x10 s1: 0x2 >>>>>> s2: 0x7fffeed0 s3: 0 s4: 0 s5: 0 >>>>>> s6: 0 s7: 0 k0: 0 k1: 0 >>>>>> gp: 0x4d55d0 sp: 0x7ffeee90 s8: 0 ra: 0 >>>>>> sr: 0xfc13 mullo: 0 mulhi: 0 badvaddr: 0 >>>>>> cause: 0x8 pc: 0x4002a4 >>>>>> Page table info for pc address 0x4002a4: pde =3D 0x809be000, pte = =3D 0xa001acda >>>>>> Dumping 4 words starting at pc address 0x4002a4: >>>>>> 8c420000 14400003 00908021 8f828024 >>>>>> Page table info for bad address 0: pde =3D 0, pte =3D 0 >>>>> MIPS24k has split I/D caches, and both are VIPT, am I right ? >>>>> I was not able to find the handling of cache aliasing in = mips/pmap.c. >>>>>=20 >>>>> Still, I am curious whether setting the loader tunable = vfs.buf_pager_relbuf >>>>> to 1 change anything. >>>>=20 >>>> MIPS caches are such that creating two virtual mappings to the same >>>> physical page will cause corruption. It's simply not allowed, at = least >>>> for the class of MIPS machines I used to bring up the port = originally. >>>=20 >>> Yes, caches are VIPT on 24k, according to the "MIPS32(R) 24K(R) >>> Processor Core Family Software User's Manual " rev 3.11. My = question is, >>> how is that handled in the mips pmap.c. I was not able to locate >>> the alias detection and prevention code, or e.g. switching to = uncached mode >>> for the page when aliasing is detected, after browsing pmap. >>=20 >> Aliases are not permitted. IIRC, there's no code that detects this >> condition. One must simply never ever have multiple cached mappings = of >> a page at once. A quick glance at the code doesn't locate anything. > Then, the obvious next question is what does prevent such aliased > mappings ? Not only usermode might establish such situation by > double-mapping, but also e.g. our coherent buffer/page cache maps page > into KVA and the same page might be mapped into usermode. The later > situation is my current thought about possible cause of the reported > init(8) fault. That=E2=80=99s a very good question. Unfortunately my memory here fails = me. I have a recollection that the various cache flushing that we do in = the map ensures that we don=E2=80=99t hit a problem. However, I = couldn=E2=80=99t construct a coherent answer to where this takes place = after a brief look at the code. Multiple mappings will cause data = corruption though. I wouldn=E2=80=99t have thought it causes the fault = in question, but MIPS errors can manifest in strange ways, so perhaps = you are correct. I don=E2=80=99t get how the fault address is 0 though = from that scenario. Maybe Adrian can recall. Or Juli can help. Warner --Apple-Mail=_070B6E65-8DF8-45E7-A09D-18C3A65DACF0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYKCClAAoJEGwc0Sh9sBEAIOsQAKWRViXd09yNuv77TI9EKmZi dqnuwrLBy8iuqQMvUQVvmEs/miOBarVZt/4HdrAaij3ruvDwK9XqbRZc8zs2UGI6 Ep5dAzuAXZr7hMJXFSr+5zlCdNaPui85AYCbOqcEEuZ34NNRrE4b3hPUsBd9dcMR ZCDu2wVlWhpZtsCJNohF/4SohU8W2qo7ZCSlpckR04yNsaQX+sxkwRopRGFSs101 wUihLKTto4Kj7Bhvpv8Up79AyIC9HelpZBPhTKOgq777YGrPlJdr1p7yKPfFogKh H+oVbKn+6mPcAYJ0845yz9x2l34WDgxzAKGoDacpPo5+n2W/oFx7uiifHx0j20Ak YYKSDcn/+MjgTGEargqSWxrFORJYhIDVromlMVBq81ENxLbT71xS6NUVczh/EJrr vv3RxBWbk2q05fzCaWzJVc/9f70JXfgwbWMhsn0Bv/NhC3SDrcd2teCTHBZAfCIn j1GlHpmA6pknwVK1lm9NBjeAhpG29jsttizr7C9TiRwOH3aNIBG27/KExSwHDGhz QYht1kp8yYdu6djsTbI+7mTEEWV5fv7qWw6NBHO0sM/GH3GstNNaP4Gw74XHq7Zi pp4tMFi/qacOSazYa+03E8B7Pi5K2vUt7c76kjTYzp3AQnsOglVUzE97LkRNDvIr VVtGxz3BG0UyepWmZoNr =fUMb -----END PGP SIGNATURE----- --Apple-Mail=_070B6E65-8DF8-45E7-A09D-18C3A65DACF0--