From owner-freebsd-arm@freebsd.org Sun Jun 28 19:50:47 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E16313539CE for ; Sun, 28 Jun 2020 19:50:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49w1Sk4x32z3WNv for ; Sun, 28 Jun 2020 19:50:46 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 05SJohRZ011420 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 28 Jun 2020 12:50:44 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 05SJohV9011419; Sun, 28 Jun 2020 12:50:43 -0700 (PDT) (envelope-from fbsd) Date: Sun, 28 Jun 2020 12:50:43 -0700 From: bob prohaska To: Konstantin Belousov Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: panic: non-current pmap on RPI3 on CURRENT (GENERIC) #4 r356366 Message-ID: <20200628195043.GA10909@www.zefox.net> References: <20200108235630.GA17485@www.zefox.net> <20200109115123.GZ23031@kib.kiev.ua> <20200109172314.GA20008@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200109172314.GA20008@www.zefox.net> X-Rspamd-Queue-Id: 49w1Sk4x32z3WNv X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [2.17 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.09)[-0.093]; NEURAL_SPAM_LONG(0.55)[0.546]; NEURAL_HAM_MEDIUM(-0.19)[-0.187]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 19:50:48 -0000 On Thu, Jan 09, 2020 at 09:23:14AM -0800, bob prohaska wrote: > On Thu, Jan 09, 2020 at 01:51:23PM +0200, Konstantin Belousov wrote: > > > > It would be useful to see both the curcpu pc_curpmap content, > > and dump both *(struct pmap *)0xfffffd000385f5a0 and *pc_curpmap > > from the vmcore. The Pi3 is now up to r362283 and just reported: panic: non-current pmap 0xfffffd000142d440 cpuid = 0 time = 1593368952 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0xffff00000075e24c lr = 0xffff00000010a468 sp = 0xffff00005a86d2e0 fp = 0xffff00005a86d4e0 db_trace_self_wrapper() at vpanic+0x194 pc = 0xffff00000010a468 lr = 0xffff000000419dcc sp = 0xffff00005a86d4f0 fp = 0xffff00005a86d540 vpanic() at panic+0x44 pc = 0xffff000000419dcc lr = 0xffff000000419b74 sp = 0xffff00005a86d550 fp = 0xffff00005a86d600 panic() at pmap_remove_pages+0x908 pc = 0xffff000000419b74 lr = 0xffff000000776e00 sp = 0xffff00005a86d610 fp = 0xffff00005a86d680 pmap_remove_pages() at vmspace_exit+0x104 pc = 0xffff000000776e00 lr = 0xffff0000006f7024 sp = 0xffff00005a86d690 fp = 0xffff00005a86d6e0 vmspace_exit() at exit1+0x48c pc = 0xffff0000006f7024 lr = 0xffff0000003d13fc sp = 0xffff00005a86d6f0 fp = 0xffff00005a86d750 exit1() at sys_sys_exit+0x10 pc = 0xffff0000003d13fc lr = 0xffff0000003d0f6c sp = 0xffff00005a86d760 fp = 0xffff00005a86d7b0 sys_sys_exit() at do_el0_sync+0x3f8 pc = 0xffff0000003d0f6c lr = 0xffff00000077dac8 sp = 0xffff00005a86d7c0 fp = 0xffff00005a86d830 do_el0_sync() at handle_el0_sync+0x90 pc = 0xffff00000077dac8 lr = 0xffff000000760a24 sp = 0xffff00005a86d840 fp = 0xffff00005a86d980 handle_el0_sync() at 0x404bd678 pc = 0xffff000000760a24 lr = 0x00000000404bd678 sp = 0xffff00005a86d990 fp = 0x0000ffffffffe960 KDB: enter: panic [ thread pid 42572 tid 100137 ] Stopped at 0x4053fcfc db> This time it was in the early stages of compiling www/chromium. Boot and root are from a mechanical hard disk, the dying top page was: last pid: 42562; load averages: 1.40, 1.37, 1.38 up 8+22:05:11 11:29:10 47 processes: 3 running, 44 sleeping CPU: 27.1% user, 0.0% nice, 11.4% system, 0.4% interrupt, 61.0% idle Mem: 92M Active, 237M Inact, 1468K Laundry, 158M Wired, 77M Buf, 415M Free Swap: 6042M Total, 194M Used, 5849M Free, 3% Inuse packet_write_wait: Connection to 50.1.20.28 port 22: Broken pipe bob@raspberrypi:~ $ R PRI NICE SIZE RES STATE C TIME WCPU COMMAND 42514 root 1 88 0 111M 63M CPU2 2 0:08 100.21% c++ 81775 bob 1 52 0 13M 352K wait 0 9:50 0.35% sh 29366 bob 1 20 0 14M 1340K CPU0 0 3:00 0.22% top 29351 bob 1 20 0 20M 936K select 2 0:15 0.03% sshd 639 root 1 20 0 13M 972K select 3 0:28 0.01% syslogd 30908 root 1 52 0 194M 40M select 1 1:52 0.00% ninja 46086 bob 1 20 0 20M 312K select 0 1:48 0.00% sshd ...... I'll update OS sources and try again, if somebody can tell me how to capture more useful information I'll try that. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Mon Jun 29 00:21:38 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0C610359001 for ; Mon, 29 Jun 2020 00:21:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49w7TD3nzGz42H6 for ; Mon, 29 Jun 2020 00:21:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: TIyW5w4VM1mDlP9.riimGDLBkkJiCWoa1Sn_.Jsrnmsxw9pY1yS.Bu2id407SnF QYgmxYlNH_YxH.mAPkXMaxxYyj9N.WufaoMQxWuOKXVa8uBvqa7iDwfTylXO1Gux1N9.Q2dvTcii SwG8RpQ93ge7VGaHwueqRFAEVos1j3LK0LF.kvZk7B7gSbXCyHIzWmTQtuB2hnuj39YyTKaiDufH d0TEL_ZUqbCk6PXQopHcCFXJ8MI8CW.5gYpWww5NLaztxfzm6EFToqVdRttFo2sdKzK3xX7KmVdH KRS87a__A1AYvcuR0Qq.2ReGiV.Ppo4g.k6Wp6kYCrHE_di9R7l4T7UmgFbAbrk67UPmv2o3EQOg m_kBjr39GWpTcOz6BXbCcQheemkbyF6xMj09F0uNwU1mGHsXCQDa4t7qjYYLoA1ZILTMqOMnNL5q LXjlsBX2DKPtTrzcQ04L8YYXPgl6130vjaCCXOoYE01pGGRmXblPmxlZ5ovew3OBbGbIlnoivE8K 3Yq.4MrF9FNIJtjm2gjU42eHg3nQ2bPfKWGCVksqOQxjsXN93pimxWau2FgwvV26KHdkPIc177rF 7jv0dQb0ARYQwTQfgVk7.2m2N9IdKD60e5A7dsAHi7N6gwlpkANSAY4KpGJquZacmPrQIkzeKK0b ELW_AH7mRo.noLPLYuHDV7N_O02jOURyx_Q1J7C3g968h.ki163b4altVbtyvz2Yhz1whrBGppIu 1x2dorVVdN0A5nYCacMXLCjZO7jGNoyLZwop9UHN4fR4SzuYbDpVj3yuxrFOVcA1KGgnTv9LFUmD WKnMHVDfO4KqW.YbBimyKfjZ0dIWeR_wkB1z1Hb3BeWjloj8mI6PNiBHtd0SxO1029lk6tZp8BpG 01QVYcnhO5QN4rsBTw9sm6kYNhtyRiY7EvnGZOv7eHON6.uwtXMdl0gg9VbchItQ1hagBUUVT1gy 1BVGgoAuEm6g4eAtcSzzVLg2BN2uYsbsgidZaAPwgKFOOuLGQPjAOK_B7UzA89_xXOFgIhk.aGOu UBoYJA0RNgkeVW6obQRmPyEFCTg292U6q1yhcED5BJA7e18h9K83wssg295vwo6rWRGBw8I6vfJY FPBEIaLYU8SRjGnB7hW.cvr2RwYNti1EkxZaC3kssgG5n4dYajDQl6kZrUS1sBtGrlEq3ypL97Oe rzSkxYmfvAw02nGOhiWyT87bQutdQ4JTpx3pBUH6xVv3IEoDMBFklk3clxgN5zSgnq8kcoBzYpcT s6StEEe8bAdB.3BvOmZCA6n_AF3bEROhWMHqay9QyVPdorpA4nJg0oM3lZgi.bt2L_Yp45JtLplF w3z4KWfMurIoudgXpTIQDGm6gANx_XB5aeJPnF2jtWPmi8LGNLhjEGYDroOgwntzLztupbT1ddCd R2Sw0q9lwzM_FqmUIsuWGX_oPvpNmUsUDkgs1aucQOJm6LClQzXSnLh3.5mmw Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Mon, 29 Jun 2020 00:21:34 +0000 Received: by smtp418.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 885ce9d5ecd02d64230782c7cc6cecd1; Mon, 29 Jun 2020 00:21:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: panic: non-current pmap on RPI3 on CURRENT (GENERIC) #4 r356366 From: Mark Millard In-Reply-To: <20200628195043.GA10909@www.zefox.net> Date: Sun, 28 Jun 2020 17:21:33 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <875C12B8-1E71-4808-AD3E-1B44D0AD9AF4@yahoo.com> References: <20200108235630.GA17485@www.zefox.net> <20200109115123.GZ23031@kib.kiev.ua> <20200109172314.GA20008@www.zefox.net> <20200628195043.GA10909@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49w7TD3nzGz42H6 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.29 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.96)[-0.956]; NEURAL_HAM_MEDIUM(-0.96)[-0.962]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; NEURAL_HAM_SHORT(-0.87)[-0.874]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 00:21:38 -0000 On 2020-Jun-28, at 12:50, bob prohaska wrote: > On Thu, Jan 09, 2020 at 09:23:14AM -0800, bob prohaska wrote: >> On Thu, Jan 09, 2020 at 01:51:23PM +0200, Konstantin Belousov wrote: >>>=20 >>> It would be useful to see both the curcpu pc_curpmap content, >>> and dump both *(struct pmap *)0xfffffd000385f5a0 and *pc_curpmap >>> from the vmcore. >=20 > The Pi3 is now up to r362283 and just reported: >=20 > panic: non-current pmap 0xfffffd000142d440 > cpuid =3D 0 > time =3D 1593368952 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc =3D 0xffff00000075e24c lr =3D 0xffff00000010a468 > sp =3D 0xffff00005a86d2e0 fp =3D 0xffff00005a86d4e0 >=20 > db_trace_self_wrapper() at vpanic+0x194 > pc =3D 0xffff00000010a468 lr =3D 0xffff000000419dcc > sp =3D 0xffff00005a86d4f0 fp =3D 0xffff00005a86d540 >=20 > vpanic() at panic+0x44 > pc =3D 0xffff000000419dcc lr =3D 0xffff000000419b74 > sp =3D 0xffff00005a86d550 fp =3D 0xffff00005a86d600 >=20 > panic() at pmap_remove_pages+0x908 > pc =3D 0xffff000000419b74 lr =3D 0xffff000000776e00 > sp =3D 0xffff00005a86d610 fp =3D 0xffff00005a86d680 >=20 > pmap_remove_pages() at vmspace_exit+0x104 > pc =3D 0xffff000000776e00 lr =3D 0xffff0000006f7024 > sp =3D 0xffff00005a86d690 fp =3D 0xffff00005a86d6e0 >=20 > vmspace_exit() at exit1+0x48c > pc =3D 0xffff0000006f7024 lr =3D 0xffff0000003d13fc > sp =3D 0xffff00005a86d6f0 fp =3D 0xffff00005a86d750 >=20 > exit1() at sys_sys_exit+0x10 > pc =3D 0xffff0000003d13fc lr =3D 0xffff0000003d0f6c > sp =3D 0xffff00005a86d760 fp =3D 0xffff00005a86d7b0 >=20 > sys_sys_exit() at do_el0_sync+0x3f8 > pc =3D 0xffff0000003d0f6c lr =3D 0xffff00000077dac8 > sp =3D 0xffff00005a86d7c0 fp =3D 0xffff00005a86d830 >=20 > do_el0_sync() at handle_el0_sync+0x90 > pc =3D 0xffff00000077dac8 lr =3D 0xffff000000760a24 > sp =3D 0xffff00005a86d840 fp =3D 0xffff00005a86d980 >=20 > handle_el0_sync() at 0x404bd678 > pc =3D 0xffff000000760a24 lr =3D 0x00000000404bd678 > sp =3D 0xffff00005a86d990 fp =3D 0x0000ffffffffe960 >=20 > KDB: enter: panic > [ thread pid 42572 tid 100137 ] > Stopped at 0x4053fcfc > db>=20 >=20 >=20 > This time it was in the early stages of compiling www/chromium. > Boot and root are from a mechanical hard disk, the dying top page > was: >=20 > last pid: 42562; load averages: 1.40, 1.37, 1.38 = up 8+22:05:11 11:29:10 > 47 processes: 3 running, 44 sleeping > CPU: 27.1% user, 0.0% nice, 11.4% system, 0.4% interrupt, 61.0% idle > Mem: 92M Active, 237M Inact, 1468K Laundry, 158M Wired, 77M Buf, 415M = Free > Swap: 6042M Total, 194M Used, 5849M Free, 3% Inuse > packet_write_wait: Connection to 50.1.20.28 port 22: Broken pipe > bob@raspberrypi:~ $ R PRI NICE SIZE RES STATE C TIME WCPU = COMMAND > 42514 root 1 88 0 111M 63M CPU2 2 0:08 100.21% = c++ > 81775 bob 1 52 0 13M 352K wait 0 9:50 0.35% = sh > 29366 bob 1 20 0 14M 1340K CPU0 0 3:00 0.22% = top > 29351 bob 1 20 0 20M 936K select 2 0:15 0.03% = sshd > 639 root 1 20 0 13M 972K select 3 0:28 0.01% = syslogd > 30908 root 1 52 0 194M 40M select 1 1:52 0.00% = ninja > 46086 bob 1 20 0 20M 312K select 0 1:48 0.00% = sshd > ...... >=20 > I'll update OS sources and try again, if somebody can tell me > how to capture more useful information I'll try that. Do you have your system set up to allow it to dump to the swap/paging space for panics and then to put a copy in the /var/crash/ area during the next boot? Konstantin B. was asking for information from such a dump. Note: A dump can be requested at the db> prompt by typing a "dump" command at the prompt, if you have set up to have a dump target identified, usually a swap/paging partition. If it works, the next boot would take some time putting material into /var/crash. An example of such materials in /var/crash/ is (2 dumps): # ls -ldT /var/crash/* -rw-r--r-- 1 root wheel 2 Jun 16 19:58:17 2020 = /var/crash/bounds -rw-r--r-- 1 root wheel 32484 Jun 11 20:34:35 2020 = /var/crash/core.txt.3 -rw-r--r-- 1 root wheel 32498 Jun 16 19:58:47 2020 = /var/crash/core.txt.4 -rw------- 1 root wheel 561 Jun 11 20:34:04 2020 = /var/crash/info.3 -rw------- 1 root wheel 562 Jun 16 19:58:17 2020 = /var/crash/info.4 lrwxr-xr-x 1 root wheel 6 Jun 16 19:58:17 2020 = /var/crash/info.last -> info.4 -rw-r--r-- 1 root wheel 5 Feb 22 02:37:33 2016 = /var/crash/minfree -rw------- 1 root wheel 9424896 Jun 11 20:34:04 2020 = /var/crash/vmcore.3 -rw------- 1 root wheel 9424896 Jun 16 19:58:17 2020 = /var/crash/vmcore.4 lrwxr-xr-x 1 root wheel 8 Jun 16 19:58:17 2020 = /var/crash/vmcore.last -> vmcore.4 Do you have devel/gdb installed? It supplies a /usr/local/bin/kgdb for looking at such vmcore.* files. It is important that the kernel debug information still match the vmcore as I understand, even if that means needing to boot a different, sufficiently-working kernel that does not match the debug information in order to get the /var/crash materials in place and to inspect them. I'm not sure you could do as Konstantin requested based on a non-debug kernel build done the usual way, even with debug information present. Are you using a non-debug kernel? A debug-kernel? You might need to try reproducing with a debug kernel. (But that likely will make builds take longer.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Jun 29 01:11:21 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C9F0F35AB33 for ; Mon, 29 Jun 2020 01:11:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49w8Zc4DRgz47vj for ; Mon, 29 Jun 2020 01:11:20 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 05T1BNA0020738 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 28 Jun 2020 18:11:24 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 05T1BNLw020737; Sun, 28 Jun 2020 18:11:23 -0700 (PDT) (envelope-from fbsd) Date: Sun, 28 Jun 2020 18:11:23 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm Subject: Re: panic: non-current pmap on RPI3 on CURRENT (GENERIC) #4 r356366 Message-ID: <20200629011123.GB10909@www.zefox.net> References: <20200108235630.GA17485@www.zefox.net> <20200109115123.GZ23031@kib.kiev.ua> <20200109172314.GA20008@www.zefox.net> <20200628195043.GA10909@www.zefox.net> <875C12B8-1E71-4808-AD3E-1B44D0AD9AF4@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <875C12B8-1E71-4808-AD3E-1B44D0AD9AF4@yahoo.com> X-Rspamd-Queue-Id: 49w8Zc4DRgz47vj X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [3.59 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.39)[0.389]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.54)[0.537]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.77)[0.769]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 01:11:21 -0000 On Sun, Jun 28, 2020 at 05:21:33PM -0700, Mark Millard wrote: > On 2020-Jun-28, at 12:50, bob prohaska wrote: > > > I'll update OS sources and try again, if somebody can tell me > > how to capture more useful information I'll try that. > > Do you have your system set up to allow it to > dump to the swap/paging space for panics and > then to put a copy in the /var/crash/ area during > the next boot? Konstantin B. was asking for > information from such a dump. > Ahh, that might be a little beyond my skill level.... The system is basically default -current, no kernel options. In fact, I'm no longer sure where to put them when using buildkernel. > Note: A dump can be requested at the db> prompt > by typing a "dump" command at the prompt, if you > have set up to have a dump target identified, > usually a swap/paging partition. If it works, the > next boot would take some time putting material > into /var/crash. > I'll try next time it happens. Looks like the system defaults turn on dumpdev and savecore. > Do you have devel/gdb installed? It supplies a > /usr/local/bin/kgdb for looking at such vmcore.* > files. Not yet. > > It is important that the kernel debug information > still match the vmcore as I understand, even if > that means needing to boot a different, > sufficiently-working kernel that does not match the > debug information in order to get the /var/crash > materials in place and to inspect them. > > I'm not sure you could do as Konstantin requested > based on a non-debug kernel build done the usual > way, even with debug information present. > One step at a time..... 8-) > Are you using a non-debug kernel? A debug-kernel? The embarrasing truth is I don't know. Whatever is default in -current for the Pi3. > You might need to try reproducing with a debug > kernel. (But that likely will make builds > take longer.) > Any sense of how much longer? A chromium build, when it worked, took a week. Thanks for writing! bob prohaska From owner-freebsd-arm@freebsd.org Mon Jun 29 04:54:21 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 04CB835DCAE for ; Mon, 29 Jun 2020 04:54:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49wFWv5kzTz4JdR for ; Mon, 29 Jun 2020 04:54:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: EyC2U9sVM1mRX8TQFFsc6qIpFZB3aFD74jgD6bdQQ8SMNNTGe1loQaZsoGf8ICA F9CF4obZTM.hMfKG0Ruhvot1.2g7L9FQK9U9oBeOfPZxeDyJmbl0.JY2GEM5lxA5LfZyzvdX2FU6 RwjCDAAQlZv46GU3JQrZLUozE3DlArIDBwMlf4lOpZTlSmCSLELtKbVTkhdY_iR3CibpQaAmAA1a WgqLT_dqcazLangJlHZD_CS8oR.ByLQMvltWymZeWH03FvsTphZ2JLYyHtA.59WAtHnz2jsHFLuH wgoaQzNU9Kt4vOQfXg7UsyphflmFB2ElfjYK0y0buy.n6sgVk6eLd7GxyBrCRIrwFXlaL_AY1pZ7 d9qACrII2z7GZCfVSjqTXWyltVCyYKKjoNMJSmEshrxBtSzOPbD0aN1_zNNDRt84tb6JmL.JEgl1 ..A4gH8aTuqc_nFI6_6uOPGVz6Q0XnEa9.LIoCpKVg9F7njKew7.J8SJvE8uPQo2jApJ3CQPksWB zt36vayne0ZdUkcNixZ522nZlxQJbNZyn1wvYY1F9Kr16Xh3tuIZ6TsD52Kn5a0Axa4bP5QkLy.3 5u1Xft5_fY8f04_sUzPzbdwyK80s3HKYcphVzM5nTWjDswS8HymFxxzg9xhimwgr8MCvThhO5HBC yZe.7bxjAtvNO0rwnvOtKFiGZTIfaDnnYPuNtsfq6Oil6OYxt7iM.EpH4UdbOdWJHY93VTcaFI.e wG4SjlOHuoVaeHCUIbii1RT7nUp2a6vPFA.HkVSgeZDCZcalWPLyFMAvZCAz5e6MhByWNBwAVZ9t lHxmdtNIZyF1mSuF2Qj93NjPtJHXpCJCUAbiyBwbEB.f5Qu.MXO.62bylAncyajEGhMlU0GV.b7s a1Mdkn7.rbxbi6WMo_GfkPBCq_Mm00xgJb_wtwkzcvnZBqEIkNfgic4S1u_UbOVXQopqoSjhVzpJ nA61FNpYh7XKaySgLcMmdoTHgPrGrqxgNr67RrfO_ip2sUjcJYVLXLMcChxBMBx8BC8Zxg33yQDA epj2GnUndPWxCmN14rItfG1.jxXNUBu2lOd09JbNDVaSnMN9w9G9JBK1ofpNPK0Y2wF8qZX8cFSy ld.hdTXYXd0k5vA9stWVkkEeKBVj_ok76rCKgqGgl3YT2aw9cqphlzEcMyuZeUCZMLnHpbI_.n58 0xJbnqOZa.jOHgQ6MGUWmQKyKKwgL.c.hvfFSWV6CG9eO6dEfhRHehVS0byD8jn3hp07vxvDpycU .48I72YwCIt1U6WxpN8M7ePrUi5NhmuzVIVDoN8ngtOeuDs9FCRk8f5K9YJ9fc.rYYKeQ4jrbrto UZjNJhrLXAn6OVZ9m2u5MAiVhwnRjA8f4_en_bf8CXv6O6wX.CYz1Tg5I8Y2q2S30fdHfeJSPjR5 YFlH2UoN18pmyZllDM11nMbOI0A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Mon, 29 Jun 2020 04:54:18 +0000 Received: by smtp427.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8c08bebe47b4809dd7f3ae2f8de5dc35; Mon, 29 Jun 2020 04:54:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: panic: non-current pmap on RPI3 on CURRENT (GENERIC) #4 r356366 From: Mark Millard In-Reply-To: <20200629011123.GB10909@www.zefox.net> Date: Sun, 28 Jun 2020 21:54:12 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <5174EF62-E48B-4AB1-B11D-EAF5E08C74DB@yahoo.com> References: <20200108235630.GA17485@www.zefox.net> <20200109115123.GZ23031@kib.kiev.ua> <20200109172314.GA20008@www.zefox.net> <20200628195043.GA10909@www.zefox.net> <875C12B8-1E71-4808-AD3E-1B44D0AD9AF4@yahoo.com> <20200629011123.GB10909@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49wFWv5kzTz4JdR X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.41 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.146:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.96)[-0.957]; NEURAL_HAM_MEDIUM(-0.96)[-0.963]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.146:from]; NEURAL_HAM_SHORT(-0.99)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 04:54:21 -0000 On 2020-Jun-28, at 18:11, bob prohaska wrote: > On Sun, Jun 28, 2020 at 05:21:33PM -0700, Mark Millard wrote: >> On 2020-Jun-28, at 12:50, bob prohaska wrote: >> >>> I'll update OS sources and try again, if somebody can tell me >>> how to capture more useful information I'll try that. >> >> Do you have your system set up to allow it to >> dump to the swap/paging space for panics and >> then to put a copy in the /var/crash/ area during >> the next boot? Konstantin B. was asking for >> information from such a dump. >> > Ahh, that might be a little beyond my skill level.... > The system is basically default -current, no kernel > options. In fact, I'm no longer sure where to put them > when using buildkernel. Actually, head (i.e, current) by default builds a debug kernel. stable and release do not. (My builds usually have the debug disabled, but I explicitly cause that.) >> Note: A dump can be requested at the db> prompt >> by typing a "dump" command at the prompt, if you >> have set up to have a dump target identified, >> usually a swap/paging partition. If it works, the >> next boot would take some time putting material >> into /var/crash. >> > I'll try next time it happens. Looks like the system > defaults turn on dumpdev and savecore. Your swap partition where dumpdev points needs to be big enough. From past experience, your likely are. >> Do you have devel/gdb installed? It supplies a >> /usr/local/bin/kgdb for looking at such vmcore.* >> files. > > Not yet. These days head based builds do not provide their own kgdb support. It can be a good idea to have devel/gdb installed even if you do not normally use it. It gets messy if something goes wrong such that building and installing devel/gdb ends up then being a difficulty after the fact. >> >> It is important that the kernel debug information >> still match the vmcore as I understand, even if >> that means needing to boot a different, >> sufficiently-working kernel that does not match the >> debug information in order to get the /var/crash >> materials in place and to inspect them. >> >> I'm not sure you could do as Konstantin requested >> based on a non-debug kernel build done the usual >> way, even with debug information present. >> > One step at a time..... 8-) Looks like you have a debug kernel build, likely with the debug information. And your problem does not prevent you from booting the same kernel that panicked and using the system after that. >> Are you using a non-debug kernel? A debug-kernel? > > The embarrasing truth is I don't know. Whatever is > default in -current for the Pi3. Debug-kernel. >> You might need to try reproducing with a debug >> kernel. (But that likely will make builds >> take longer.) >> > Any sense of how much longer? A chromium build, > when it worked, took a week. You have already seen the time frames because you have been using the debug kernel. If you have noticed stable being faster then head, the kernel being non-debug for stable by default vs. debug for head by default is likely part of the issue. Witness checks, asserts, etc. take extra time. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jun 30 10:20:37 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 49CB13653B4 for ; Tue, 30 Jun 2020 10:20:37 +0000 (UTC) (envelope-from charlesr@scd-systems.net) Received: from mail.scd-systems.net (warbird.scd-systems.net [37.120.173.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.scd-systems.net", Issuer "mail.scd-systems.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49x0jw24p0z4DMD for ; Tue, 30 Jun 2020 10:20:35 +0000 (UTC) (envelope-from charlesr@scd-systems.net) Received: from mail.scd-systems.net (127.0.1.80 [127.0.1.80]) by mail.scd-systems.net (OpenSMTPD) with ESMTP id e6d54ce8 for ; Tue, 30 Jun 2020 10:20:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=scd-systems.net; h= reply-to:subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=default; bh=81mfZLEw7kRTLOLppXjQwKo1PuW2JMeww+AWKP1kKhY=; b=ZwtJMbfFmjg9 62EuNo4QCk4vFJV2yTzENMk+iGIypM0S7tQMFVINRlTfEM8UtgTdA4VIowagdmyX 4huGhhWLh8rFFVKtCVKcHnYAOCSmVLylNJW5Xk3dewwN6Q8LoOHD3As6Ie9qgy6m HEGnxluH+nCXwBYzVoQXBtlSxVzh94M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=scd-systems.net; h=reply-to :subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; q=dns; s= default; b=kTYvC5QWsAffeuIWF8AeL5eSuF9NWCOeBYCkeXOKDIYESoRtqlPja pIrkWeHHGiLUxTXJS1QM91U5LsXRhvoXWSW+Id6M0khsabqRdnDBIJ015+yy3WVM ZxGKroDWw6vA6bcIWP+iLCf1LzGQhmwbkoD6LP2WytxDmsfw+DHrh8= Received: from LT1006.fritz.box (127.0.1.254 [127.0.1.254]) by mail.scd-systems.net (OpenSMTPD) with ESMTPSA id e92a4781 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO for ; Tue, 30 Jun 2020 10:20:28 +0000 (UTC) Reply-To: charlesr@scd-systems.net Subject: Re: Rock64 dwc interface issues To: freebsd-arm@freebsd.org References: <877d6e2d-6cd8-30f3-08c3-60a2bacb5873@scd-systems.net> <7B4746AD-A8B7-43F0-B5EC-F3812A91F344@gmail.com> <20200619194222.73bc7dd705f6d80e63757796@bidouilliste.com> <48C101F9-9C1F-46EB-A092-EE903D5070D1@gmail.com> <20200621185402.9d40f269cb07706242622af6@bidouilliste.com> <9ca8c4b2-232f-a23e-fd1c-f3d93567977e@scd-systems.net> <20200622071600.GA41924@bluezbox.com> <20200622191015.GA55660@bluezbox.com> <20200624145257.d0287e2df67db3597ee59412@bidouilliste.com> From: Charles Message-ID: Date: Tue, 30 Jun 2020 12:20:27 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200624145257.d0287e2df67db3597ee59412@bidouilliste.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49x0jw24p0z4DMD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=scd-systems.net header.s=default header.b=ZwtJMbfF; dmarc=none; spf=pass (mx1.freebsd.org: domain of charlesr@scd-systems.net designates 37.120.173.96 as permitted sender) smtp.mailfrom=charlesr@scd-systems.net X-Spamd-Result: default: False [-2.40 / 15.00]; HAS_REPLYTO(0.00)[charlesr@scd-systems.net]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[scd-systems.net:s=default]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.02)[-1.018]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[scd-systems.net:+]; NEURAL_HAM_SHORT(-0.07)[-0.073]; DMARC_NA(0.00)[scd-systems.net: no valid DMARC record]; NEURAL_HAM_MEDIUM(-0.81)[-0.813]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:197540, ipnet:37.120.160.0/19, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 10:20:37 -0000 Hi, Short update. I tried the patch from gonzo and the "IP truncated-ip - 16384 bytes missing" messages from tcpdump disappeard. But the packet lost did still exists until I changed the value: hw.usb.dwc_otg.phy_type to 4 (UTMI+). Before it was set to 1 (DWC OTG PHY TYPE - 0/1/2/3 - ULPI/HSIC/INTERNAL/UTMI+) I tried all types, only the UTMI+ type seems to work stable with my rock64 board. Is that expected for this board with FreeBSD? I did not compared linux right now. Maybe linux use also the UTMI+ type for OTG. Best, C. Am 24.06.20 um 14:52 schrieb Emmanuel Vadot: > On Mon, 22 Jun 2020 12:10:15 -0700 > Oleksandr Tymoshenko wrote: > >> Charles (charlesr@scd-systems.net) wrote: >>> Hi gonzo, >>> >>> >>> In 100Mbit mode the interface does not respond to any arp who-is >>> requests (tcpdump). So no icmp request are send nor received the rock64. >>> Then I tried to connect the laptop directly to the rock64 (Interface to >>> interface connection 1GBit) --> Same packet lost issue as before. >>> >>> The tcpdump on dwc0 interface reports: >>> >>> IP truncated-ip - 16384 bytes missing >>> >>> >>> I also tried to replace the /boot/dtb/rockchip/rk3328-rock64.dtb against >>> the Linux version (75kb size instead 54kb size FreeBSD Version) without >>> success. >> >> Could you try this patch? >> >> https://people.freebsd.org/~gonzo/arm/patches/dwc-rk-delays.diff >> >> -- >> gonzo > > Hi gonzo, > > Just tested this patch on rockpro64 and rock64 and this works for me. > Whatever leads me to commit > https://svnweb.freebsd.org/base?view=revision&revision=335445 seems > fixed now ? > In rk3399_set_delays you print rk3328 btw. And both printfs that shows > the delay should be under bootverbose. > With that you can commit with Reviewed by: manu :) > > I don't think that it will help Charles but the code make sense and > matches the TRM. > > Thanks, > From owner-freebsd-arm@freebsd.org Tue Jun 30 10:23:26 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4C9763656AD for ; Tue, 30 Jun 2020 10:23:26 +0000 (UTC) (envelope-from mail@jboy.eu) Received: from christensen.uberspace.de (christensen.uberspace.de [185.26.156.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49x0n90C4Rz4F42 for ; Tue, 30 Jun 2020 10:23:23 +0000 (UTC) (envelope-from mail@jboy.eu) Received: (qmail 18887 invoked from network); 30 Jun 2020 10:23:16 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by christensen.uberspace.de with SMTP; 30 Jun 2020 10:23:16 -0000 From: Jeremy Boy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: RPi-B: lang/go fails to build with SIGFPE Message-Id: <0A05C8FD-1046-485B-A42D-20C42F7CBC33@jboy.eu> Date: Tue, 30 Jun 2020 12:23:14 +0200 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49x0n90C4Rz4F42 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mail@jboy.eu designates 185.26.156.203 as permitted sender) smtp.mailfrom=mail@jboy.eu X-Spamd-Result: default: False [-1.77 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[jboy.eu]; NEURAL_HAM_LONG(-1.02)[-1.016]; NEURAL_SPAM_SHORT(0.02)[0.023]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:205766, ipnet:185.26.156.0/24, country:DE]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 10:23:26 -0000 Has anyone tried to build lang/go on RPi-B lately? The build aborts with = SIGFPE on a vmrs instruction on 12.1-RELEASE, 12-STABLE and 13-CURRENT = for me. Works on RPi-2 with 12.1-RELEASE. I have already opened an = issue[0] on go's github, but without a solution so far. Any help would = be greatly appreciated. Regards, Jeremy 0: https://github.com/golang/go/issues/39816= From owner-freebsd-arm@freebsd.org Tue Jun 30 13:01:47 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9446534A5C8 for ; Tue, 30 Jun 2020 13:01:47 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49x4Hv17TCz4Nw9 for ; Tue, 30 Jun 2020 13:01:47 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 26AEF34A3CE; Tue, 30 Jun 2020 13:01:47 +0000 (UTC) Delivered-To: arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 265A734A3CC for ; Tue, 30 Jun 2020 13:01:47 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49x4Hr5dphz4P67 for ; Tue, 30 Jun 2020 13:01:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From; bh=dfgIwJ2offudOkO2O75EQfX/Auun/dKB9JPnhCfdYv4=; b=S8iEoyxLLIHaa6I8WEyU+QOkJs3JhLwO5gk6/sNLhuJd4UXFGzp0HUthTlknq1UfEP9j64yu4xN6ox48vN/n85aDAJgwCBuF6XXD+jgQjfOa1CyhRp65vxGk5HsHCrpe29hWt+ziWvNVAP2TCispBTkvJjHSmAMUHi9ZHG3UKPKfzcCD5wwv0pslf7Crhj/d7D5BZyWDfR7oSGrxFr9hzhs5H7XxNxi7PxPK+clnKk8jBZkFmnadGSKTTsmQhdi2TdZKPm2hLtSRn2VLFRxt2N0/1Yjz+xXCkQMSiAvt8gil1bAq8Al4eqtsCU0a6w2bC7G4YjVp+aV1h15npOFKvQ==; Received: from macmini.bk.cs.huji.ac.il ([132.65.179.19]) by kabab.cs.huji.ac.il with esmtp id 1jqFtN-0008ob-Ev for arm@freebsd.org; Tue, 30 Jun 2020 16:01:41 +0300 From: Daniel Braniss Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: allwinner/i2c interrupt storm detected Message-Id: <10ACCB56-E18D-4102-B4E2-094157854AB7@cs.huji.ac.il> Date: Tue, 30 Jun 2020 16:01:41 +0300 To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49x4Hr5dphz4P67 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=S8iEoyxL; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-2.26 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(0.02)[0.017]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; RCVD_IN_DNSWL_NONE(0.00)[132.65.116.210:from]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 13:01:47 -0000 Hi, after a long time I decided to try and upgrade to stable 12.1 r362793 = since I saw some changes where done=20 with respect to the DTS and twsi.c,=20 if nothing is connected to the i2c, i2c -s just hangs, if something is connected this is what i get on the console after typing = =E2=80=98i2c -s=E2=80=99 Hardware may not support START/STOP scanning; trinterrupt storm detected = on "gic0,s6:"; throttling interrupt source ying less-reliable read method. interrupt storm detected on "gic0,s6:"; throttling interrupt source interrupt storm detected on "gic0,s6:"; throttling interrupt source =E2=80=A6 and neo-04> vmstat -i interrupt total rate gic0,p13:-ic_timer0 16052 164 gic0,s0: uart2 318 3 gic0,s6: iichb0 13034 133 gic0,s60: aw_mmc0 1293 13 gic0,s82: awg0 334 3 gic0,s120: pmu0 49725 509 cpu0:rendezvous 18 0 cpu1:rendezvous 50 1 cpu2:rendezvous 51 1 cpu3:rendezvous 40 0 cpu0:preempt 2691 28 cpu1:preempt 3165 32 cpu2:preempt 2778 28 cpu3:preempt 2986 31 cpu0:hardclock 15 0 Total 92550 946 the hardware is an NanoPi Neo ---<>--- KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2020 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 12.1-STABLE #0 r362793M: Tue Jun 30 11:39:11 IDT 2020 = danny@nrnd:/home/obj/nrnd/arm/neo/vol/rnd/stable/12/arm.armv7/sys/AWGEN = arm FreeBSD clang version 10.0.0 (git@github.com = :llvm/llvm-project.git = llvmorg-10.0.0-0-gd32170dbd5b) VT: init without driver. No PSCI/SMCCC call function found CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) =E2=80=A6 From owner-freebsd-arm@freebsd.org Tue Jun 30 15:05:48 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E426234D752 for ; Tue, 30 Jun 2020 15:05:48 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49x72z3m0Dz4Wd4 for ; Tue, 30 Jun 2020 15:05:47 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Tue, 30 Jun 2020 15:05:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1593529543; bh=jwETArXxGRdhYPH2ABouzypRXwXMlF4Wcm5NC6sbs5U=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=IIDM4Jh2+XnUXrCn9Yb7RHQyCkhVRLcwjQa3xd2IxDhGbb5Ci9/hE71FvDWwKHRdT RMbe/De/g5EmKI7mVVoGe7Yul4Du5UpDx3/5HYIQBardUBOgsSlSPdKz5J4DK74fHI w2CGUQVgriLXIHzd0SNUuzbYwPxySrvuhUp9u9x8= To: myfreeweb From: Dan Kotowski Cc: freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: <71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology> References: <71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49x72z3m0Dz4Wd4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=IIDM4Jh2; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.131 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-4.16 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[185.70.40.131:from]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; NEURAL_HAM_LONG(-0.97)[-0.973]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-1.11)[-1.109]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.131:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 15:05:48 -0000 > We do not support the SMMU at all. (There is a patch for SMMUv3 support b= ut this chip has a v1/v2.) Appologies for still being new to this, but the following revision implies = to me that we do support SMMU? https://reviews.freebsd.org/D18002 I only barely know what I'm doing down at this level, so maybe I'm just not= reading it properly. I guess we could throw some debug prints in there too= ? From owner-freebsd-arm@freebsd.org Tue Jun 30 19:40:35 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 60F85354B80 for ; Tue, 30 Jun 2020 19:40:35 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49xF820RQNz3cmy for ; Tue, 30 Jun 2020 19:40:33 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Tue, 30 Jun 2020 19:40:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1593546031; bh=pMt/1RJYFC1Pzm5BkfGhw6Gs4jpghM3k8hYfACQc/aw=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=GDVHZ/vVGX/IrJobe1beR0qiMQDevdsPPdEU6MO3UXH2UQVkLlAJyOjJnrPatHxFC 1rjm4vjCa+9ZXN+eXfnY/GnTpam7uUfuwgwSt7SC6NTE2SqRSdEDW1qkT2zTLkYWFl vqM3zB4Q9yx0h5z1pKmbL+jd71fp7vf5ZF2n1emE= To: Dan Kotowski From: Dan Kotowski Cc: myfreeweb , freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: References: =?us-ascii?Q?________<71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology>_?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49xF820RQNz3cmy X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=GDVHZ/vV; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.134 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-3.34 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; NEURAL_HAM_LONG(-0.97)[-0.973]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.134:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.28)[-0.280]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.134:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 19:40:35 -0000 > > We do not support the SMMU at all. (There is a patch for SMMUv3 support= but this chip has a v1/v2.) > > Appologies for still being new to this, but the following revision implie= s to me that we do support SMMU? > > https://reviews.freebsd.org/D18002 > > I only barely know what I'm doing down at this level, so maybe I'm just n= ot reading it properly. I guess we could throw some debug prints in there t= oo? Appologies - you were right, the n00b was wrong. ``` #ifdef notyet /* * Not implemented, map a PCIe device to the SMMU it is associated with. */ int acpi_iort_map_smmu(u_int seg, u_int devid, void **smmu, u_int *sid) { =09/* XXX: convert oref to SMMU device */ =09return (ENXIO); } #endif ``` That's been effectively a stub since Nov 2018... I've been reading DEN 0029C on SBSA 6.0 but it's not clear to me whether we= need this for all SBSA-compliant systems or if this is just a decision Jon= and SR are making and claiming it's necessary. >From section 4.1.3: """ Non-secure off-chip devices that cannot directly address all of the Non-sec= ure address space must be placed behind a stage 1 System MMU compatible with the Arm SMMUv2 or SMMUv3 specif= ication """ And section 4.1.6 System MMU and Device Assignment """ If a device is assigned and passed through to an operating system under a h= ypervisor, then the memory transactions of the device must be subject to stage 2 translation, allocati= on of memory attributes, and application of permission checks, under the control of the hypervisor. This= specification collectively refers to this translation, attribution, and permission checking as policing. The act= of policing is referred to as stage 2 System MMU functionality. Stage 2 System MMU functionality must be provided by a System MMU compatibl= e with the Arm SMMUv2 specification """ I'm almost surprised that nobody has bumped into this before. How does the = IORT look on the MACCHIATObin if interrupts are NOT mapped behind SMMU? From owner-freebsd-arm@freebsd.org Tue Jun 30 20:51:30 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E65C7355B70 for ; Tue, 30 Jun 2020 20:51:30 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49xGjs6W82z3xZn for ; Tue, 30 Jun 2020 20:51:29 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92 (FreeBSD)) (envelope-from ) id 1jqNDt-0009Sv-W9; Tue, 30 Jun 2020 13:51:22 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id 05UKpKBl036388; Tue, 30 Jun 2020 13:51:20 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Tue, 30 Jun 2020 13:51:20 -0700 From: Oleksandr Tymoshenko To: Charles Cc: freebsd-arm@freebsd.org Subject: Re: Rock64 dwc interface issues Message-ID: <20200630205120.GA36236@bluezbox.com> References: <7B4746AD-A8B7-43F0-B5EC-F3812A91F344@gmail.com> <20200619194222.73bc7dd705f6d80e63757796@bidouilliste.com> <48C101F9-9C1F-46EB-A092-EE903D5070D1@gmail.com> <20200621185402.9d40f269cb07706242622af6@bidouilliste.com> <9ca8c4b2-232f-a23e-fd1c-f3d93567977e@scd-systems.net> <20200622071600.GA41924@bluezbox.com> <20200622191015.GA55660@bluezbox.com> <20200624145257.d0287e2df67db3597ee59412@bidouilliste.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.2-RELEASE-p10 (amd64) User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Charles (charlesr@scd-systems.net) wrote: > Hi, > > > Short update. > > I tried the patch from gonzo and the "IP truncated-ip - 16384 bytes > missing" messages from tcpdump disappeard. > But the packe [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Rspamd-Queue-Id: 49xGjs6W82z3xZn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of gonzo@bluezbox.com designates 45.55.20.155 as permitted sender) smtp.mailfrom=gonzo@bluezbox.com X-Spamd-Result: default: False [-2.12 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.943]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.02)[-1.017]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[bluezbox.com]; NEURAL_SPAM_SHORT(0.14)[0.142]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:45.55.0.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 20:51:31 -0000 Charles (charlesr@scd-systems.net) wrote: > Hi, > > > Short update. > > I tried the patch from gonzo and the "IP truncated-ip - 16384 bytes > missing" messages from tcpdump disappeard. > But the packet lost did still exists until I changed the value: > > hw.usb.dwc_otg.phy_type to 4 (UTMI+). > > Before it was set to 1 > > (DWC OTG PHY TYPE - 0/1/2/3 - ULPI/HSIC/INTERNAL/UTMI+) > > I tried all types, only the UTMI+ type seems to work stable with my > rock64 board. > > Is that expected for this board with FreeBSD? Not really. Given that hw.usb.dwc_otg.phy_type controls USB phy, not ethernet it shouldn't have any effect on networking. The reason it affects ethernet is probably because this configuration somehow reduces signal interference. I can reproduce the 1Gb problem with Rock64 locally, so I'll try dig deeper into it later this week. -- gonzo From owner-freebsd-arm@freebsd.org Wed Jul 1 17:45:10 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3CF6035858C for ; Wed, 1 Jul 2020 17:45:10 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out0.migadu.com (out0.migadu.com [94.23.1.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49xpXP0WMjz4p2n for ; Wed, 1 Jul 2020 17:45:07 +0000 (UTC) (envelope-from greg@unrelenting.technology) Date: Wed, 01 Jul 2020 17:44:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1593625500; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0OIN3EK1UlRcVt33kxQV+SxnBtjcCYFdFkLRY81Lrxc=; b=gXxA5uqeLLvQI5G1rkABrK+T9WWdpv5NRFNa1vnVtwkSrViHsMMoQvDQ8QMO5h1IiuQliE PvwsQgtSv5KIXDJQPgf2SM46NQfMDCUa4k/JXDdmSLvwRl5Rgha1HX8HrHyITOqPZ4WB2B KO/7x9Neqaygcax/2PVXtTjhU4MRJAY= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: myfreeweb To: Dan Kotowski CC: freebsd-arm Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X In-Reply-To: References: _____<71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology>_?= Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 49xpXP0WMjz4p2n X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=gXxA5uqe; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 94.23.1.103 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-3.71 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.030]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.23.1.103]; NEURAL_HAM_LONG(-0.99)[-0.987]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; NEURAL_HAM_SHORT(-0.69)[-0.689]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[94.23.1.103:from]; ASN(0.00)[asn:16276, ipnet:94.23.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 17:45:10 -0000 On June 30, 2020 7:40:26 PM UTC, Dan Kotowski wrote: >> > We do not support the SMMU at all=2E (There is a patch for SMMUv3 sup= port but this chip has a v1/v2=2E) >> >> Appologies for still being new to this, but the following revision impl= ies to me that we do support SMMU? >> >> https://reviews=2Efreebsd=2Eorg/D18002 >> >> I only barely know what I'm doing down at this level, so maybe I'm just= not reading it properly=2E I guess we could throw some debug prints in the= re too? > >Appologies - you were right, the n00b was wrong=2E > >``` >#ifdef notyet >/* > * Not implemented, map a PCIe device to the SMMU it is associated with= =2E > */ >int >acpi_iort_map_smmu(u_int seg, u_int devid, void **smmu, u_int *sid) >{ > /* XXX: convert oref to SMMU device */ > return (ENXIO); >} >#endif >``` > >That's been effectively a stub since Nov 2018=2E=2E=2E > >I've been reading DEN 0029C on SBSA 6=2E0 but it's not clear to me whethe= r we need this for all SBSA-compliant systems or if this is just a decision= Jon and SR are making and claiming it's necessary=2E > >From section 4=2E1=2E3: >""" >Non-secure off-chip devices that cannot directly address all of the Non-s= ecure address space must be placed >behind a stage 1 System MMU compatible with the Arm SMMUv2 or SMMUv3 spec= ification >""" Well, normally PCIe devices can address all the space, unless you have ter= ribly quirky hardware (on the RPi4, PCIe can address 3GB only=2E=2E) Also I would guess that like=2E=2E yes, even if PCIe goes through the SMMU= , if the SMMU is untouched by the OS, interrupts should arrive where the OS= expects it normally=2E >And section 4=2E1=2E6 System MMU and Device Assignment >""" >If a device is assigned and passed through to an operating system under a= hypervisor, then the memory We're running on bare metal, this is about VMs=2E >I'm almost surprised that nobody has bumped into this before=2E How does = the IORT look on the MACCHIATObin if interrupts are NOT mapped behind SMMU? There is no IORT on the mcbin=2E=2E armada8k has a GICv2 not v3 :D Socionext SynQuacer has the PCI node pointed to the ITS node=2E If I'm reading the table disassembly correctly, the Ampere eMAG has PCI no= des pointing to SMMU (v1/v2)=2E But FreeBSD works there fine! That means the "fallback" non-IORT calculation of RIDs works fine there=2E= But maybe it doesn't on the NXP chip because it's buggy=2E But there was *some* way to get the interrupts (without supporting SMMU) o= n this NXP chip =E2=80=93 as evidenced by NetBSD working! Again=2E=2E can you flash the firmware **where PCIe was working under NetB= SD**, dump the IORT there and also try patched (with D25179, e=2Eg=2E any o= f my recent builds I guess) FreeBSD there? From owner-freebsd-arm@freebsd.org Wed Jul 1 21:38:03 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E9EE835C3F1 for ; Wed, 1 Jul 2020 21:38:03 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49xvj66DKnz3ZB1 for ; Wed, 1 Jul 2020 21:38:02 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Wed, 01 Jul 2020 21:37:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1593639479; bh=ALEK/a7v1ioeX62AXHHzNnPyx6k7C4kzOl0H5GCgo3k=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=zi4VLzErM+BUkgzqo9jJtsPF+NZJFdJj2DiK5kr18IL/BHxrXgm16W/ZchQQA4TNj VElrdGqBA1SVPunVOTx0ChsD5ooYxAn9mPFF/aQl+DeUr2NYJnVNxdJ8jOSEpUpI9D ovKcAvutIUZp12mO3TX/M/hGDEUdI2INsBqUKRXc= To: myfreeweb From: Dan Kotowski Cc: freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: References: _____<71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49xvj66DKnz3ZB1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=zi4VLzEr; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.22 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-3.78 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.04)[-1.038]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.22:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.65)[-0.649]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.22:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 21:38:04 -0000 > Well, normally PCIe devices can address all the space, unless you have te= rribly quirky hardware (on the RPi4, PCIe can address 3GB only..) > > Also I would guess that like.. yes, even if PCIe goes through the SMMU, i= f the SMMU is untouched by the OS, interrupts should arrive where the OS ex= pects it normally. > > > And section 4.1.6 System MMU and Device Assignment > > """ > > If a device is assigned and passed through to an operating system under= a hypervisor, then the memory > > We're running on bare metal, this is about VMs. So even though that stub only returns ENXIO, it should not matter unless I = intend to use bhyve or something like that? > > I'm almost surprised that nobody has bumped into this before. How does = the IORT look on the MACCHIATObin if interrupts are NOT mapped behind SMMU? > > There is no IORT on the mcbin.. armada8k has a GICv2 not v3 :D I'm also interested in acquiring one of those as well at some point, but yo= ur posts indicate that the net ifaces on that are basically dead weight und= er FreeBSD as well :( > Socionext SynQuacer has the PCI node pointed to the ITS node. 24x A53 cores... hmmm... > If I'm reading the table disassembly correctly, the Ampere eMAG has PCI n= odes pointing to SMMU (v1/v2). But FreeBSD works there fine! > That means the "fallback" non-IORT calculation of RIDs works fine there. = But maybe it doesn't on the NXP chip because it's buggy. > > But there was some way to get the interrupts (without supporting SMMU) on= this NXP chip =E2=80=93 as evidenced by NetBSD working! > > Again.. can you flash the firmware where PCIe was working under NetBSD, d= ump the IORT there and also try patched (with D25179, e.g. any of my recent= builds I guess) FreeBSD there? https://gist.github.com/agrajag9/a59b6c440365745c5a4036e0faf6e23c With old and new firmwares: EFI shell acpiview output acpidump -b (tarred, gzipped, and uuencoded) acpidump -dt And in case you need it, here's the IORT aslc used in the old firmware buil= d: https://github.com/agrajag9/edk2-platforms/blob/master-lx2160a/Silicon/NXP/= LX2160A/AcpiTables/Iort.aslc From owner-freebsd-arm@freebsd.org Thu Jul 2 01:55:18 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3427136266D for ; Thu, 2 Jul 2020 01:55:18 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out1.migadu.com (out1.migadu.com [IPv6:2001:41d0:2:863f::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49y1Pw2qd2z46nG for ; Thu, 2 Jul 2020 01:55:15 +0000 (UTC) (envelope-from greg@unrelenting.technology) Date: Thu, 02 Jul 2020 01:55:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1593654908; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WDcOoAW8QPFRXrGd/FTmB37ibZrwoD8FF6PFrtiCwqM=; b=CadVDNIqIl8TGuuBkww9V0Sro1XatA1gP3OZVlO+Dk+jSDEpkifZKn6XF1Ez2aQiyfD9vp 2tyUbWF3N5tqAaTFCs+SzZ6w8dtdeZrmDgPYqSR8A8E3SDHWEuFM2RLPEEysynppFLWdTf QYVkhs18M9ubquRBinOF4XTiM1N7cnI= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: myfreeweb To: Dan Kotowski CC: freebsd-arm Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X In-Reply-To: References: _____<71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 49y1Pw2qd2z46nG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=CadVDNIq; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 2001:41d0:2:863f:: as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-3.97 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.04)[-1.036]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:863f::]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; NEURAL_HAM_SHORT(-0.94)[-0.940]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 01:55:18 -0000 On July 1, 2020 9:37:56 PM UTC, Dan Kotowski wrote: >> Well, normally PCIe devices can address all the space, unless you have = terribly quirky hardware (on the RPi4, PCIe can address 3GB only=2E=2E) >> >> Also I would guess that like=2E=2E yes, even if PCIe goes through the S= MMU, if the SMMU is untouched by the OS, interrupts should arrive where the= OS expects it normally=2E >> >> > And section 4=2E1=2E6 System MMU and Device Assignment >> > """ >> > If a device is assigned and passed through to an operating system und= er a hypervisor, then the memory >> >> We're running on bare metal, this is about VMs=2E > >So even though that stub only returns ENXIO, it should not matter unless = I intend to use bhyve or something like that? > >> > I'm almost surprised that nobody has bumped into this before=2E How d= oes the IORT look on the MACCHIATObin if interrupts are NOT mapped behind S= MMU? >> >> There is no IORT on the mcbin=2E=2E armada8k has a GICv2 not v3 :D > >I'm also interested in acquiring one of those as well at some point, but = your posts indicate that the net ifaces on that are basically dead weight u= nder FreeBSD as well :( For a desktop, USB Ethernet is enough :D >> Socionext SynQuacer has the PCI node pointed to the ITS node=2E > >24x A53 cores=2E=2E=2E hmmm=2E=2E=2E Yeah, very low single core perf, especially for that price :/ >> If I'm reading the table disassembly correctly, the Ampere eMAG has PCI= nodes pointing to SMMU (v1/v2)=2E But FreeBSD works there fine! >> That means the "fallback" non-IORT calculation of RIDs works fine there= =2E But maybe it doesn't on the NXP chip because it's buggy=2E >> >> But there was some way to get the interrupts (without supporting SMMU) = on this NXP chip =E2=80=93 as evidenced by NetBSD working! >> >> Again=2E=2E can you flash the firmware where PCIe was working under Net= BSD, dump the IORT there and also try patched (with D25179, e=2Eg=2E any of= my recent builds I guess) FreeBSD there? > >https://gist=2Egithub=2Ecom/agrajag9/a59b6c440365745c5a4036e0faf6e23c Yeah, so the "old" does have "Output reference : 0x30" under the PCIe root= s=2E So does NetBSD PCIe only work on "old"? FreeBSD still not working anywhere? I guess another interesting thing to check would be Linux configured witho= ut any SMMU support=2E=2E From owner-freebsd-arm@freebsd.org Thu Jul 2 16:18:16 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4159D35A428 for ; Thu, 2 Jul 2020 16:18:16 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49yNYf5dfQz42VQ for ; Thu, 2 Jul 2020 16:18:14 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: by mail-io1-xd2c.google.com with SMTP id v6so15807661iob.4 for ; Thu, 02 Jul 2020 09:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=aaCij4tCafGweUhfb0qBI1+OyHCbqhSiPVaqQQJJ9go=; b=GB77ROf7zT/BUFAGIjJQfmgmZ3FKdkZpHyphPDccspAQ8jXoahD5IcZSJNJMZV6MWJ rmSP2YBvmmf8o8Fi/En1A0msHw4r2On+j8Gbo7FoH79P+kYg2UtBV7fF90XiedAoMc71 z6XnFD+ntweRkBBOc+s53iDUMikI+FKLCR2rGTwjpF9x4Xhb3CuoFrMzvzQtFM1tBGXO UgKw6IX05ScNBcP/GZROjvC28o0wa2SA421u4Qfz6CLrQgMF4t6MekUvLm824/wPBlHg BqMlIKXVashLvWCcpD6FdbcVJnmRZL1QryuC3maEDQArco7wpRxoGdnAQMzFcu76Z5F+ bgdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=aaCij4tCafGweUhfb0qBI1+OyHCbqhSiPVaqQQJJ9go=; b=oO+Up1DbPDO4dVMlKzOmm23zloUsqoigpNDwDaxIKcnr+C2ADgRTAlxTc3z664LP2I Y/xYEdwgEZfM8lVigYq3OAQzXpr64SSuJWofUqFNQqDkoKqUEtw9Bo0/5lydagBX9A/4 IvX9urgtx7fKqFBAKOoa1XQCyrcMG3mnZcih+cZsNGhcHr/G/yS3UD7U8e6sB2vYGrSX df6RaQqePR5+uaw2qye632npkOCsIPj7oiWk2ErLoFwyT2wfwHfJt67rzFyGujGAfZ/d 12ZtkIGytWBc/GhOZrAoCtIWhd8b4tVWu0txLCD6HG04e5u5wX2ghNh6a6DWShv5Q4es 4KbQ== X-Gm-Message-State: AOAM533IyxSBAWyQY+AiJ1w+7w+XeSC9l7TTZZPbM8OJflzih2s3AyBK T98Pcwecp+0IAhptNLKLCdibXkvaZ7Y7+ZPtN4r7z0yE8jWC X-Google-Smtp-Source: ABdhPJya4lM0TBJcX5oGOpXE02DPj3tuD7gUWXIg3V+UwgVHly5G4ylo2MekJJwUcS1juyGonTiXGjLoEGpTfYBRUqQ= X-Received: by 2002:a6b:6f0d:: with SMTP id k13mr8005400ioc.119.1593706693052; Thu, 02 Jul 2020 09:18:13 -0700 (PDT) MIME-Version: 1.0 Reply-To: kamalp@acm.org From: "Kamal R. Prasad" Date: Thu, 2 Jul 2020 21:48:02 +0530 Message-ID: Subject: cv_wait To: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 49yNYf5dfQz42VQ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=GB77ROf7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kamalpr@gmail.com designates 2607:f8b0:4864:20::d2c as permitted sender) smtp.mailfrom=kamalpr@gmail.com X-Spamd-Result: default: False [-2.59 / 15.00]; HAS_REPLYTO(0.00)[kamalp@acm.org]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.89)[-0.886]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.98)[-0.981]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2c:from]; NEURAL_SPAM_SHORT(0.27)[0.273]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 16:18:16 -0000 hello, i have written a piece of code in a freebsd driver meant for arm. The first cv_wait(&sc->sc_cv, &sc->sc_mtx); keeps waiting indefinitely. If I use cv_timedwait() instead, it returns EWOULDBLOCK does someone know why this is happening? thanks -kamal From owner-freebsd-arm@freebsd.org Thu Jul 2 16:59:06 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D7BE935B402 for ; Thu, 2 Jul 2020 16:59:06 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49yPSp2Gr5z44Q4 for ; Thu, 2 Jul 2020 16:59:05 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1593709145; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=JbL9d7n0cEETDoJaBzxOX7MMW2ZWCI/DiTUrIOJNuFivZ8Ch40lA/6wo4sO8NqAdvi6sQqIxn9AEl rlP4RLxB/wDhQ72zRjdoD8gdSoKoyZsf/zohUkvqRnP8BpkZptfufxQhWKBwUQflQf39+Zg8hrBFHY XdLfFi3usLtfUhrWrEDhYroOxkqdepd0HVqO8n/lbuXPWJtVLHrHEp7bYI37kaM2MdSNsbyjF15Azs 3/RuOhLWDV3laaIOykbH8f5seyAF4qSY2Gs5P0lM2Fyk42CQYaSQG8dhLokwXskJsYuBwsWJ2ramYq USONsG+n+9nukRFiWXSCFn19IiD+Q5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=ydlH5oe/RcTLAnsjFp/R3+qY4SfeWlrRjKLIkW5UxWs=; b=PJE80zSh+78ZgGIY2x3feBcsabv/fFwv99+g2XIMoPRhGvpBSkImL+Lm2unGwMCOTE1ZSkNqVbHql 6/A8aC7mmuQdkk7KB/4h0t5lq7e9BcTg2q6Vo3NTHRWE4jcaqSLKbv2Tmw+YG0kA7FfseksqiXNJtS W2p+GEpNcUO9MMsWPN3u5V+wloiXnrUuYreGp5pgT3P5Lhry5fAGVrDV7A+ZRfJOHFCrOAQDY+hSYO JMrhDkaAwVUYAl3IiC0qOL9MEaRkfhiCL0p6vu67zgViL5VWe7De7hiVT0fondTTbz5eRi9rPjtyHB Lvckr/dR7Dv4dTaHyJSPurS/WiYL4/Q== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=ydlH5oe/RcTLAnsjFp/R3+qY4SfeWlrRjKLIkW5UxWs=; b=en+E8kW49IBOYewaPUINOUQZPjGObsfdCF0NmtttRF8a3U5+jyqpG/vvbREWn1g3rBX7NB+VleAMf RSPTXj5+aCMruxnOUDzH0aePXKtwXkhTpb8OpQa4FmQ1VKhm2QwIVKr11lMJTSXVvY4ToCZk3p7AX/ pBcAlsD1hoJTMKMQ4aql/0i38Ae5g5UahSpudDO8Fp0I95l/s5t8WKMB5XMh4DC2EkV1vEFolnR4Fs uQCPlgqkcFtuUapAVr2duae2mblOrhejMHI7+FqDi6w/8rxmKZxFpg+kV7xcNr/gpgfPZEryHBIRmL IlIIi0qi7wvcwceI8ijgWeQwmTv6CzQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: 54c57959-bc85-11ea-b630-6b8aa7872eb8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 54c57959-bc85-11ea-b630-6b8aa7872eb8; Thu, 02 Jul 2020 16:59:03 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 062Gx2SG099561; Thu, 2 Jul 2020 10:59:02 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: cv_wait From: Ian Lepore To: kamalp@acm.org, freebsd-arm@freebsd.org Date: Thu, 02 Jul 2020 10:59:02 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49yPSp2Gr5z44Q4 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 16:59:06 -0000 On Thu, 2020-07-02 at 21:48 +0530, Kamal R. Prasad wrote: > hello, > > i have written a piece of code in a freebsd driver meant for arm. The > first > cv_wait(&sc->sc_cv, &sc->sc_mtx); > keeps waiting indefinitely. If I use cv_timedwait() instead, it > returns > > EWOULDBLOCK > > > does someone know why this is happening? > > > thanks > > -kamal > That would imply that nothing is ever calling cv_signal(&sc->sc_cv) or cv_broadcast(&sc->sc_cv). -- Ian From owner-freebsd-arm@freebsd.org Thu Jul 2 18:46:55 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 19E9A35DA26 for ; Thu, 2 Jul 2020 18:46:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49yRsB5rqHz4Bnw for ; Thu, 2 Jul 2020 18:46:54 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1593715613; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=vxCDuL1ZoOaYzWCsChEVmXv/BFmpFk2Cx5WUQCw+Ap0qMNufs+xeeXG4jX6kz+1jAqgxtF5OSe3v9 udMCY5gjUBG6K8wxphjEKE/0EmzZu/oDBKKdEGmeAd55Ro+oQzjmAEvl9xmbgR675y2yeDGILJrB5d aggysuZfleZd0kEv14JdXMMbFqNWFI6QOHGRyBTfQ+rEj3mzOgLb6427iKsz32HgPfM6wWKtJYc4Wm +kSkaCdXeiUYYr19xBo3BIfKHmLK57gZ8qM+y6RIydHpQXw599iaBYdlV8HCRTAkpFLqqQe9elF88t AajR5J5Q0VtlrpnOW1tPUkv7Sd9gIsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=WsMbrBdS0r4w1btedE0v/2eQZx/QUhWuU0t+SlIdGe0=; b=sYhuzlVcuH2BXKrhxQ47fVivfZJkAgSjucxJZj2Jyz0W4rxzsQy94tgysl1mnayAReE+Gg4zlQbRN bcdwyS2pGuX4Z5gOZGrKXk1vVDjo2BP9VUrWd02LRapwm+k+yrkQyfn5EsAwDQRUUy3Ep1Sdt9bceT hQCMks7ifDzOThKCZc/rCaStpvQV+X2TT8QKQdeHmTqxM2BvSJv0NoerXsihKztp1PKiQ2Aeox5uas KieLfZDMZFJ252vSi7k3OC7S8jwPN6hVeY8KUlxcGupHdEx1VoTCSNbxiIteQ0QDBUHVpLHpoiGBG6 n+2O4rXfOo/Qf0Pkq4i2q6ziCoF+hjg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=WsMbrBdS0r4w1btedE0v/2eQZx/QUhWuU0t+SlIdGe0=; b=bFr8auzAXrER9CEq+Hg3H8QGynpEfhIepKXUz+GZuXpGEGJUvo/oVblP3oHErZiTHyysPv1X4Vf1u kBeWMGaOsDIqGgwWnwyIAsRlN04+NLlwVBdN6Cd7hcCHiBRtw/r3uio/+1adyZ2Zs/7GMkNQ0Sxt9p cdGL1k8nhUeNPCcR6lmlM3oN5bWE7ERr4tQgh3c3pxjoWApQcF9qg0nijXbKBe2RLxTVG0sje9ZYVb VJshw6W88+0NzylZkBQiAAgT5qRqLP4ss38osQ8/t+UlM20QbLGC7Al4TuBHvzxl4nij3ta49ovrIg e3QEG6XsIUREP+W//Kan2acKlRPL1TA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 645a633b-bc94-11ea-b630-6b8aa7872eb8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 645a633b-bc94-11ea-b630-6b8aa7872eb8; Thu, 02 Jul 2020 18:46:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 062Ikpxt099881 for ; Thu, 2 Jul 2020 12:46:51 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <951e9225efae61050c20831c13fe5f82bfdddd2e.camel@freebsd.org> Subject: Re: cv_wait From: Ian Lepore To: freebsd-arm@freebsd.org Date: Thu, 02 Jul 2020 12:46:51 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49yRsB5rqHz4Bnw X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 18:46:55 -0000 On Thu, 2020-07-02 at 21:48 +0530, Kamal R. Prasad wrote: > hello, > > i have written a piece of code in a freebsd driver meant for arm. The > first > cv_wait(&sc->sc_cv, &sc->sc_mtx); > keeps waiting indefinitely. If I use cv_timedwait() instead, it > returns > > EWOULDBLOCK > > > does someone know why this is happening? > > > thanks > > -kamal > Kamal, You replied to my last mail privately, without including freebsd-arm@. I can't reply to you directly, because your mail server is bouncing the replies [1], please re-send your last reply to the public list so I can reply to it. [1] failed: acm.org: 554 5.7.1 : Recipient address rejected: Access denied -- Ian From owner-freebsd-arm@freebsd.org Thu Jul 2 19:06:18 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 134A735DB6A for ; Thu, 2 Jul 2020 19:06:18 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49ySHY5Hz2z4CQj; Thu, 2 Jul 2020 19:06:17 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: by mail-io1-xd42.google.com with SMTP id f23so30070397iof.6; Thu, 02 Jul 2020 12:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=Cma6ccFh5HErJjSjfadXByH+agn5cSMTre1dRpvIJmM=; b=s29FSG1lTYObid1VedaFmL9UORC5C7q/sQR6JBqq+0recmotnxieTXCqv5Q1SC6e6G TVYcth0Ppqz0G7bbtUCfnwdU7MLIXwmP2JLVy4HSoyUVIf8dvcfFM+a23Jgwqrz7mOqt VNkJ7mJ5NH/vwccQngkYxj4QZ37XkQEGwxffbXUrCLM8R62gmMObH3Co3IONZAEo4sQ5 qKnFJMyqTRf71D/EaNUB7toKXFTj26NgwP1wcrvMeYnpd7znStdZru8kr8+PcAoC+JmS tMGp0fJPBzRAIYIC5+zvf4UtAIvYZkMM+rp4ROrN3Ww4CBfO+WPJgwl7oAIjJUrmGVZm ltDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=Cma6ccFh5HErJjSjfadXByH+agn5cSMTre1dRpvIJmM=; b=AgmxGVynmKTu9sGIk3gwgCfO1mmIMftn6BYkxiXy+328fq8VM/oKGN/ozohYH6Ksv5 9imz9Mr623r1Q5jNObpvfLgKbgNVYRpRTZSDSdXPnsl0OY14DdKtYDfQdQ9gNAzuZSCz 9fjbm6lbBieRmHcGcZ8vbb0C2v03WJyggIj4jqKnOLmVfrtPMKllKOMuNfaCAAh4jUpa bm6s/ENcbtWIhb3v96rrMXj6qPP+FLSRV0Adn6nwBdvGN1uHtr6Bjkb7w15W4qGoVh0X 8B47f+aAMyHy9QeM8nsYTRm9j6YY9RJvbvblgPd3kmTJLUe7AUd5wLVdZ97+wJh73QaJ BtTw== X-Gm-Message-State: AOAM531JYBkWHhrWP7a0tl64fzqDiP8DqkkgUH78e5fLDAV7yA25U8y9 9Ob3DL+EPI+kT7Ir+PFOflhmh9gApO6xO9LFtXL2LFt6K4Md X-Google-Smtp-Source: ABdhPJzbc8PPjyOKlXfFD+9KE7i/1xwGogSVPynBsK4Qd9XcA8Zw/nTRXs1dfhowkt6xm3wg7GNY1Hxtkj1WnywP3fE= X-Received: by 2002:a6b:7d02:: with SMTP id c2mr8869701ioq.146.1593716776654; Thu, 02 Jul 2020 12:06:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: kamalp@acm.org From: "Kamal R. Prasad" Date: Fri, 3 Jul 2020 00:36:05 +0530 Message-ID: Subject: Re: cv_wait To: Ian Lepore Cc: kamalp@acm.org, freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 49ySHY5Hz2z4CQj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 19:06:18 -0000 but if i am doing cv_wait() for the first time, should someone be calling cv_signal for it to proceed? my algo is something like this in my driver:- function1() { mtx_lock(&sc->sc_mtx); cv_wait(&sc->sc_cv); mtx_unlock(&sc->sc_mtx); .... critical section .... cv_signal(&sc->sc_cv); } function2() { mtx_lock(&sc->sc_mtx); cv_wait(&sc->sc_cv); mtx_unlock(&sc->sc_mtx); .... critical section .... cv_signal(&sc->sc_cv); } --------------------- i want to protect critical section. The critical section calls a common piece of code which has some locks. if i put in locks to guard the cs, it triggers a call to witness(). Update: i saw an implementation wherein they used a callout to periodically send a cv_signal(). i could do that but the pt of this implementation is that cs in either of these functions should not be eecuting at the same time. thanks -kamal On Thu, Jul 2, 2020 at 10:29 PM Ian Lepore wrote: > On Thu, 2020-07-02 at 21:48 +0530, Kamal R. Prasad wrote: > > hello, > > > > i have written a piece of code in a freebsd driver meant for arm. The > > first > > cv_wait(&sc->sc_cv, &sc->sc_mtx); > > keeps waiting indefinitely. If I use cv_timedwait() instead, it > > returns > > > > EWOULDBLOCK > > > > > > does someone know why this is happening? > > > > > > thanks > > > > -kamal > > > > That would imply that nothing is ever calling cv_signal(&sc->sc_cv) or > cv_broadcast(&sc->sc_cv). > > -- Ian > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Thu Jul 2 19:07:32 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5C0C235DE45 for ; Thu, 2 Jul 2020 19:07:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49ySJz6LrNz4Csf for ; Thu, 2 Jul 2020 19:07:31 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1593716851; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=GbTfCRJAAW1pgMZgnWnJ4XxY3nyN0O6tc/IJADJ7aw8Qb+MjADsonYxasmk5tBKt0YH7UEKXnmXrs o+4w8sjTFmfi4r/MfmC6dqglLtcDZR0GvwjoUYoxRQk9DwtbXIrAc9XHaiC1qQDmBxtS1b6SD4aWI4 TP5hObj4RaHaugJO2XNUoYKjPKaj98VX/SCqppwPHHmnsZ6CZYE9jW7YBhwLjhuxcJ6wztG4bZBO0P e5Tw7uNNFPtCC1b+DW5qFo+wdRYIKGLZoU89kpAbt5eZqRS/oJNp1OeAEg/tBxYxpjCR65PERqCz5F r6zKVJWuCMVtuix4CmOOhHkgvK4Hnow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=g8q+WV5AkbpnwCy02psPQ/XT+eazsdRMDY5sI8xaR4s=; b=KVKzcw/pZzgAxfFBMxTSCR1+Zr5Ujg2MvN//aCKRnleyuTgF0gfhMxQMmHtzDX/yd++DMKUpv0r3X +Tfb19oxGtYFRZengxl7X1Zg3bdHt97xyMRvXO+VgTvGQavcdfTP7+Wd19VnPuSqmkF5ELOvCK+Kpo IE37kLQjYC7uIho702UkpiRUHXYSjyfPDLMfJ/q2v9BclxNheYdaLgA8yEtp8p4AVfWo1AZfq4EJ/v 73dLHEQxPsXf7J5ZYoL5LJ8nBPHT/2bipzBY+aVlNmB8gF9X1PzWf0DC51bwqeXNUJeoCznzxw+ODE e80zgFjGe6sAGOe7gzL3zhvyP13pFkw== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=g8q+WV5AkbpnwCy02psPQ/XT+eazsdRMDY5sI8xaR4s=; b=cmEN55yRK/GyOAEbnZonsoQWCjsbUHey3uDE8ZTBNhetd2B4w4l8uoz64RMUt5ck5q5BBRnbNul// AGbDUBW/uooPrdrmg4zimnMWVXVHoc3XKJCo1+buk+PwXwiKSxy2rSZYUDhHKd7hYucRhyPFdXNaeP fdkXW0a3bOAFjLfc+fxXBxC1YEvDnQva4zU2xx+PjmtQ65gf2nh+rwk16U6HSOq9qOf2L4g23B25+H aG+VnIhqZrF0wqyWu+x/lkYFDDMg9GFfqx3g7JUtv0sqUPDvG/4TM1YBrCKEdekIPSeibHLYSR8azW Sm8ULZlibpp4JUquMsGTMuNsXuUUUng== X-MHO-RoutePath: aGlwcGll X-MHO-User: 463b2423-bc97-11ea-b630-6b8aa7872eb8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 463b2423-bc97-11ea-b630-6b8aa7872eb8; Thu, 02 Jul 2020 19:07:30 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 062J7T4n099945; Thu, 2 Jul 2020 13:07:29 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <28698f3e3db608dceee910a8ba62ad7b6be0769f.camel@freebsd.org> Subject: Re: cv_wait From: Ian Lepore To: kamalp@acm.org Cc: freebsd-arm@freebsd.org Date: Thu, 02 Jul 2020 13:07:29 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49ySJz6LrNz4Csf X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 19:07:32 -0000 On Fri, 2020-07-03 at 00:36 +0530, Kamal R. Prasad wrote: > but if i am doing cv_wait() for the first time, should someone be > calling cv_signal for it to proceed? > my algo is something like this in my driver:- > function1() > { > mtx_lock(&sc->sc_mtx); > cv_wait(&sc->sc_cv); > mtx_unlock(&sc->sc_mtx); > .... > critical section > .... > cv_signal(&sc->sc_cv); > } > > function2() > { > mtx_lock(&sc->sc_mtx); > cv_wait(&sc->sc_cv); > mtx_unlock(&sc->sc_mtx); > .... > critical section > .... > cv_signal(&sc->sc_cv); > } > --------------------- > i want to protect critical section. The critical section calls a > common > piece of code which has some locks. if i put in locks to guard the > cs, it > triggers a call to witness(). > > Update: i saw an implementation wherein they used a callout to > periodically > send a cv_signal(). i could do that but the pt of this implementation > is > that cs in either of these functions should not be eecuting at the > same > time. > > thanks > -kamal > A condition variable doesn't work the way you're trying to use it. What is the complaint from witness? What type of locks are used in the common code that causes a complaint? Are any of these functions involved called from interrupt handlers (that also imposes restrictions on what kind of locking you can do)? -- Ian From owner-freebsd-arm@freebsd.org Thu Jul 2 19:23:01 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C2B5035E2FB for ; Thu, 2 Jul 2020 19:23:01 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49ySfs2xp3z4Dn4; Thu, 2 Jul 2020 19:23:01 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: by mail-il1-x130.google.com with SMTP id r12so18020160ilh.4; Thu, 02 Jul 2020 12:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=kDPLCJtSliJYZFy5wWYoh3ZYpgCITr3fGgfghRxmdhg=; b=NQ2kE0TI323RYqGFPYnFjnvOU9YVwXVoVphR5caclhNoZ0RhLj53rwAcU5Xz4NKHyJ VD/eAikyoiL0h7lBaSQP2lu4oUs8DVo5icrVdTH4kTsJXRZUQVLrZ2prajq+ZvZGFmyB 15lmlohq+4uYG4KwnsbnnUSX3Q+Ag9B97OtAnLrfu8FDyGoLzYe3zp/JuDTKKs5UOVQV pybgikuvbuknmsdfx9xW3/WJP3NJgEum3ob2gqUDREpwN4pXqy1fl6D+h5q3GdFyNJSm 38apAh3+kdWlPWSY8AbVFEyZbDxyNpojjo5zlHWIrhK0Ug+RzkhGm4Os4uWlq0UDz5mG iU8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=kDPLCJtSliJYZFy5wWYoh3ZYpgCITr3fGgfghRxmdhg=; b=B/8BnjpZhn3J46ZtLZFuS/1GhD3BjcQ+t2ezODaOy9Qax++qQUKXOrsiSMp+ZtBkoh nNuqOfFVorH14k2GSTZ+lTSxABXoBlb+tJp6H4z9rHdLohpEa0k8h0A5tCvICl8+LyWG X57Jhs7ymJq+3YWnXkw7ehDlDZjVZKBfSXAIcY0mcRv9AC+BjAOYHlNSBgBBxXvJhc9j mYAY3Jra4o9KjGr2Ar8OjaBy+53i18dukP5aXfz9iSoN0+GdVN8w5NYv8ZOXko8D29hE H3FtmQGM69/BUc6pPQsVlakEV/0v/b2rEJVkbroNeOyTZe/xsOijWOOxiLag/dzrj1dT giiA== X-Gm-Message-State: AOAM5333VXmOTMoM7zGWrvf8/pveDjWrc8LOn5xTmKHReWdYTeBtewCG HsYkkdKzoR0B4AcNMN9Dvk3x5yI86qJKmOmJ9x2Q/iDLeA== X-Google-Smtp-Source: ABdhPJyhghmxz4rybRzwekk9E2za4SGuPmodmyWNBzPFUnWer7dyLyEsp5fmNI6yHgM0kMOmUt6YFL/9Dkx4NFcCvpA= X-Received: by 2002:a92:cacf:: with SMTP id m15mr13622361ilq.34.1593717779749; Thu, 02 Jul 2020 12:22:59 -0700 (PDT) MIME-Version: 1.0 References: <28698f3e3db608dceee910a8ba62ad7b6be0769f.camel@freebsd.org> In-Reply-To: <28698f3e3db608dceee910a8ba62ad7b6be0769f.camel@freebsd.org> Reply-To: kamalp@acm.org From: "Kamal R. Prasad" Date: Fri, 3 Jul 2020 00:52:49 +0530 Message-ID: Subject: Re: cv_wait To: Ian Lepore Cc: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 49ySfs2xp3z4Dn4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 19:23:01 -0000 witness threw a panic saying that there is a potential deadlock. I dont have the exact msg as I changed the algo and lost the console logs. the common code has a mtx_lock() and mtx_unlock() to guard against race conditions. i just want to use a synchrnization primitive that will not hold any locks when calling the common code from the cs. so, pl feel free to suggest any alernativves. thanks -kamal On Fri, Jul 3, 2020 at 12:37 AM Ian Lepore wrote: > On Fri, 2020-07-03 at 00:36 +0530, Kamal R. Prasad wrote: > > but if i am doing cv_wait() for the first time, should someone be > > calling cv_signal for it to proceed? > > my algo is something like this in my driver:- > > function1() > > { > > mtx_lock(&sc->sc_mtx); > > cv_wait(&sc->sc_cv); > > mtx_unlock(&sc->sc_mtx); > > .... > > critical section > > .... > > cv_signal(&sc->sc_cv); > > } > > > > function2() > > { > > mtx_lock(&sc->sc_mtx); > > cv_wait(&sc->sc_cv); > > mtx_unlock(&sc->sc_mtx); > > .... > > critical section > > .... > > cv_signal(&sc->sc_cv); > > } > > --------------------- > > i want to protect critical section. The critical section calls a > > common > > piece of code which has some locks. if i put in locks to guard the > > cs, it > > triggers a call to witness(). > > > > Update: i saw an implementation wherein they used a callout to > > periodically > > send a cv_signal(). i could do that but the pt of this implementation > > is > > that cs in either of these functions should not be eecuting at the > > same > > time. > > > > thanks > > -kamal > > > > A condition variable doesn't work the way you're trying to use it. > > What is the complaint from witness? What type of locks are used in the > common code that causes a complaint? Are any of these functions > involved called from interrupt handlers (that also imposes restrictions > on what kind of locking you can do)? > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Thu Jul 2 19:45:23 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8CAA335EB22 for ; Thu, 2 Jul 2020 19:45:23 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound5a.ore.mailhop.org (outbound5a.ore.mailhop.org [44.233.67.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49yT8f6cPvz4FLk for ; Thu, 2 Jul 2020 19:45:22 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1593719115; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=wK+yDgH6jqlozpyhxgI/YyelSawkfENci45ms5mpI9i1vaX+sFmun/T+ag7Thc5gI6TeUvepLFXqM zhOLC1N0Z7zZKC6BzsuFEwwELFCuKMNGQOeqZJEKfqoCNRL3geK5WJufsw6PwVHABkS9BZDfm7Yx0W LLD6MiUUZgo2M9o5bog5PM9rOo8M5q2GoCKW9KbaEAoHftnyRPTTCZNMsRw/enPG5x3xQOI+Ewatqn +uyqdj+ol1rriBwy7VdRG6oFXEhAjXdhJHfnaDapFEdfuEwiNugpXvXQizXvEdJVZ0Ia3uypAE0/mo ovbyxNtTt5IRAmxSvGtJDgCHyO3KaUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=bx6qQlEuaxagILqJn0IsXX6E6HBEZvdtxu26Re37cUw=; b=C1LN+GN4o8MK2hAiCM5vZNxHt9qTS/UME1zDeHat1OKn20CIHyytcZgtpjROPqP0/lnOAcLi/iemf EH3n41OZDitT3sNs661xm45qTJkG0jnab4Ay3/BDeV2J5ab6Z0C1dqz9B2DwZi9kx2YsHUcgcCtVaa tFRMgUc4ENIwwwN9uvNHHhnuEvbVHNrlSMcWlyJ3yOwkv/hFT4nv9HBVCl5R7aaQq8SvSTF8yARWJl Hj2/VhaReA5lms2NahIkNNETXbS0PzJMWZSLMHIJ7PrI1UiXONepGGgflHJ6ohDVvLDseCZTmHKPxO MuKMQA9/FKcFeQu1LpxrFPNqne4JdWQ== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=bx6qQlEuaxagILqJn0IsXX6E6HBEZvdtxu26Re37cUw=; b=mGys5VogonFAvS607snJrpSM7oXTYneiAlI5VLYFMHDrqZE6p9ZasvVG9UYm9yGSi4EoqBU5+FUR5 6Qi6KPzQw5MBYjuTIxEryVMi2Evd6kY67nev3vaTnL8AWQBa9USovVkj4cbif+v5D1uJ/2IwAv3Wk2 ANUtfgKAaS10uIqcmJdcGxKD+Y9F0h01tV48VKCDZiR5oydyJrezYN/GoL5+tgXJcXXZTc6RlcYsZT 3xRSpNv2NCNxwISTSExXUB0TkDZNxHnn6EEPrsLpSvJgzgR5clUSbuO7gdyrOHQpP1+VIrkGqC+vEB lbYE0DQMmIQk0k9WRahrkBOGE++yHuA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 8b9bd7dc-bc9c-11ea-a2ba-9f0c275c2f69 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 8b9bd7dc-bc9c-11ea-a2ba-9f0c275c2f69; Thu, 02 Jul 2020 19:45:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 062JjCob000159; Thu, 2 Jul 2020 13:45:12 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: cv_wait From: Ian Lepore To: kamalp@acm.org Cc: freebsd-arm@freebsd.org Date: Thu, 02 Jul 2020 13:45:12 -0600 In-Reply-To: References: <28698f3e3db608dceee910a8ba62ad7b6be0769f.camel@freebsd.org> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49yT8f6cPvz4FLk X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:16509, ipnet:44.224.0.0/11, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 19:45:23 -0000 On Fri, 2020-07-03 at 00:52 +0530, Kamal R. Prasad wrote: > witness threw a panic saying that there is a potential deadlock. I > dont > have the exact msg as I changed the algo and lost the console logs. > the common code has a mtx_lock() and mtx_unlock() to guard against > race > conditions. > i just want to use a synchrnization primitive that will not hold any > locks > when calling the common code from the cs. > so, pl feel free to suggest any alernativves. > > thanks > -kamal > Maybe an sxlock is what you're looking for. void function1() { sx_xlock(&sc->cs_lock); common_func(); sx_unlock(&sc->cs_lock); } void function2() { sx_xlock(&sc->cs_lock); common_func(); sx_unlock(&sc->cs_lock); } That would ensure that only one caller at a time is in the critical section that calls common_func() (if it's just common_func() that needs protecting, I'd put the sx_xlock in there). But I'm not sure how that's different than using a standard mutex, unless your common code was trying to sleep (or use malloc with WAIT_OK). If using a standard mutex caused witness to warn about an unbounded sleep while holding a mutex, then using the sxlock should fix that. Also, you should look at 'man locking' if you haven't already. -- Ian > > > On Fri, Jul 3, 2020 at 12:37 AM Ian Lepore wrote: > > > On Fri, 2020-07-03 at 00:36 +0530, Kamal R. Prasad wrote: > > > but if i am doing cv_wait() for the first time, should someone be > > > calling cv_signal for it to proceed? > > > my algo is something like this in my driver:- > > > function1() > > > { > > > mtx_lock(&sc->sc_mtx); > > > cv_wait(&sc->sc_cv); > > > mtx_unlock(&sc->sc_mtx); > > > .... > > > critical section > > > .... > > > cv_signal(&sc->sc_cv); > > > } > > > > > > function2() > > > { > > > mtx_lock(&sc->sc_mtx); > > > cv_wait(&sc->sc_cv); > > > mtx_unlock(&sc->sc_mtx); > > > .... > > > critical section > > > .... > > > cv_signal(&sc->sc_cv); > > > } > > > --------------------- > > > i want to protect critical section. The critical section calls a > > > common > > > piece of code which has some locks. if i put in locks to guard > > > the > > > cs, it > > > triggers a call to witness(). > > > > > > Update: i saw an implementation wherein they used a callout to > > > periodically > > > send a cv_signal(). i could do that but the pt of this > > > implementation > > > is > > > that cs in either of these functions should not be eecuting at > > > the > > > same > > > time. > > > > > > thanks > > > -kamal > > > > > > > A condition variable doesn't work the way you're trying to use it. > > > > What is the complaint from witness? What type of locks are used in > > the > > common code that causes a complaint? Are any of these functions > > involved called from interrupt handlers (that also imposes > > restrictions > > on what kind of locking you can do)? > > > > -- Ian > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to " > > freebsd-arm-unsubscribe@freebsd.org" > > From owner-freebsd-arm@freebsd.org Thu Jul 2 21:04:15 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C472835FFED for ; Thu, 2 Jul 2020 21:04:14 +0000 (UTC) (envelope-from furkan@fkardame.com) Received: from sender4-of-o53.zoho.com (sender4-of-o53.zoho.com [136.143.188.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49yVvd5cXmz4Jgj for ; Thu, 2 Jul 2020 21:04:13 +0000 (UTC) (envelope-from furkan@fkardame.com) ARC-Seal: i=1; a=rsa-sha256; t=1593723851; cv=none; d=zohomail.com; s=zohoarc; b=kyIsrwf1bhtF+b906tMg8WjX2NO4O5x4WxFkDEToU5UzEoXuSHLhMYMibfd6rtBQzBL8j0/D4HxTIG6BUGNoUSXpmPbtcUjiNqLcIPbsadHf+/rgWtcY5Qebh62ZfDI5kJby0BGZaHD4wabggOCnTQBY4bWlHb0th8v/+tIxUy0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1593723851; h=Content-Type:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=XWG3zg9Sfbf+aIY73ChLilUp657rOYMC1m8Zk5AfR8Y=; b=fpDkv3hTo8QFxKWKSgQFzqyG9HqOdS6nEvJ4vwJ1MJN+NkYsIpwWdsjzp/awbNtJQN8i9Nk0kS5VsRKSpbG5jyeknWdEpDVfRdMJi2CmbtqNszZm2m6yBATvzoK7ypcQGs3M7Tx9xbn5d1Axty24R1Nh1sabUyIGqyDIMZeVDF0= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=fkardame.com; spf=pass smtp.mailfrom=furkan@fkardame.com; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1593723851; s=fktech; d=fkardame.com; i=furkan@fkardame.com; h=Date:From:To:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; bh=XWG3zg9Sfbf+aIY73ChLilUp657rOYMC1m8Zk5AfR8Y=; b=IB9fHMZf0exOdAgIY1uF/rEI96t0dNvC5uDp2eioH/xNoMDxoi30G0gOA7kOnx/r s4T3dJgEbHWORiC/hYIssSYzUP1mOw5NgJ3SPvzk0oNAxhe6SgUImXFcx7JUHxYaruI TTEVXKpQYl9bHL3+cWKMBRCTb+Xx87Fn+ZOjlRb8= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 15937238489196.354157089030878; Thu, 2 Jul 2020 14:04:08 -0700 (PDT) Date: Fri, 03 Jul 2020 00:04:08 +0300 From: Furkan Salman To: "freebsd-arm" Message-Id: <173115808d3.f2327534108660.257113843983027589@fkardame.com> In-Reply-To: References: Subject: Re: Add Support for Radxa RockPi E MIME-Version: 1.0 Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Rspamd-Queue-Id: 49yVvd5cXmz4Jgj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=fkardame.com header.s=fktech header.b=IB9fHMZf; dmarc=pass (policy=none) header.from=fkardame.com; spf=pass (mx1.freebsd.org: domain of furkan@fkardame.com designates 136.143.188.53 as permitted sender) smtp.mailfrom=furkan@fkardame.com X-Spamd-Result: default: False [-4.82 / 15.00]; NEURAL_HAM_MEDIUM(-0.98)[-0.979]; RWL_MAILSPIKE_VERYGOOD(0.00)[136.143.188.53:from]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:136.143.188.0/23]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-0.99)[-0.987]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[fkardame.com:~]; DMARC_POLICY_ALLOW(-0.50)[fkardame.com,none]; RCVD_IN_DNSWL_NONE(0.00)[136.143.188.53:from]; NEURAL_HAM_SHORT(-1.06)[-1.063]; R_DKIM_PERMFAIL(0.00)[fkardame.com:s=fktech]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; ARC_ALLOW(-1.00)[zohomail.com:s=zohoarc:i=1] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 21:04:15 -0000 Hello Team, With the help of Sergey (S199pWa1k9r), I was able to boot into RockPi E and= have both lan card detected, but one of the lan cannot detect a cable conn= ected to it which means it is always down and doesn't come up. Here is the Boot log=C2=A0https://hastebin.com/olehocidib.makefile When I connect the lan on RTL8211E (GMAC) then it can get ip address from t= he dhcp server but when I connect lan to PHY (10/100) then it is not coming= up. ifconfig can be found here=C2=A0https://hastebin.com/ecazezikih.xml=C2=A0= =C2=A0 I think gonzo will be looking into this on the weekend, but if there is any= one else who is aware of this issue then kindly guide us. Thanks. ---- On Thu, 25 Jun 2020 17:49:51 +0300 Aleksandr Rybalko wrote ---- Hmmm, I see only GMAC (10/100/1000) and PHY(10/100) that can be configured = as connected to GMAC in=C2=A0Datasheet. =D1=87=D1=82, 25 =D1=87=D0=B5=D1=80=D0=B2. 2020 =D0=BE 02:17 Sleep Walker <= mailto:s199p.wa1k9r@gmail.com> =D0=BF=D0=B8=D1=88=D0=B5: >From TRM =E2=80=94=E2=80=94=E2=80=94 =20 There are two independent GMAC controllers named GMAC2IO and GMAC2PHY: =EF=81=AC GMAC2IO Supports 10/100/1000-Mbps data transfer rates with the R= GMII interfaces and Supports 10/100-Mbps data transfer rates with the RMII = interfaces =EF=81=AC GMAC2PHY Supports 10/100-Mbps data transfer rates with the RMII = interfaces =E2=80=94=E2=80=94=E2=80=94- =20 =20 =D0=9E=D1=82=D0=BF=D1=80=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=D0=BE =D1=81 iPad =20 > 24 =D0=B8=D1=8E=D0=BD=D1=8F 2020 =D0=B3., =D0=B2 19:29, Ganbold Tsagaank= huu =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(= =D0=B0): >=20 > =EF=BB=BFOn Wed, Jun 24, 2020 at 10:12 PM Furkan Salman wrote: >=20 >> Hello, >>=20 >> I was able to boot FreeBSD on Radxa RockPi E over emmc with the help of >> Sergey (sl199pwa1k9r). >> Details of the device can be found here >> https://wiki.radxa.com/RockpiE/getting_started. It have removable emmc. >>=20 >>=20 >>=20 >>=20 >>=20 >> Boot Logs: https://hastebin.com/eyokuqoyif.coffeescript >>=20 >>=20 >>=20 >> Things not working yet: >>=20 >> RK3328 onboard Lan. >>=20 >> Micro-Hdmi connector (Only used for debugging and not MP) >>=20 >> Boot from SD Card, Pin detection fails, Was able to boot into it manual= ly. >>=20 >> As per Sergey, we might need some help understanding how the Lan is >> working on rock64 board using onboard Lan driver. >>=20 >>=20 >>=20 >> Can anyone advice us on how can we add onboard lan driver. >>=20 >>=20 > Their wiki page doesn't say anything about 100M LAN in detail. Maybe it = is > better either to ask them or boot linux and see what Ethernet > chipset/controller it says in log/dmesg. >=20 > Ganbold >=20 >=20 >=20 >>=20 >>=20 >> Thanks. >> Furkan K. >> _______________________________________________ >> mailto:freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "mailto:freebsd-arm-unsubscribe@freebs= d.org" >>=20 > _______________________________________________ > mailto:freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "mailto:freebsd-arm-unsubscribe@freebsd= .org" _______________________________________________ mailto:freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "mailto:freebsd-arm-unsubscribe@freebsd.o= rg" From owner-freebsd-arm@freebsd.org Fri Jul 3 07:58:52 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2AA5936DC33 for ; Fri, 3 Jul 2020 07:58:52 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: from mail-il1-x142.google.com (mail-il1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49ynQz5Yb0z3fwj; Fri, 3 Jul 2020 07:58:51 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: by mail-il1-x142.google.com with SMTP id i18so26573961ilk.10; Fri, 03 Jul 2020 00:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=gwi6r7Y5JCzFUgWHR5Ui4fU4NmZCS0fwC//QymVyoFg=; b=mBpTTVgryK958apz3xuQXDmnLRDVASTKbr95wsTVCmkBDxl4b+p2mwl7QRFGi3jc+P 2GWBr5381LPqCXm/6hclzUoait0FMo1713yNDv1qtODcAWmP1M5BwoykS9g26bUTfWun BOueZ6zdgiY8/8avPFG0r16FUaqqx4lYGSolvhVoBwi7G5tZHPqMfSDBMZ3VbtuXgds8 Mlpnw92Geun7Kgn666QogHDNCTwsOLl7LjX1exoGcgkaU2zUTEAP9I7UcVSTNpIJbPm0 Q2jDPDbFX+a1P04nrpLrDz0Qdaso68N5ryP3ARY9OIv1Q7Rh70cKXa0cMJpd+ItG67UP kmhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=gwi6r7Y5JCzFUgWHR5Ui4fU4NmZCS0fwC//QymVyoFg=; b=kFeNaDsLYgWi59oETevgQqwSj6DN5AXZhAP93TVdwsz5grsD4Ej4SapHDz85Qtel9y 8zrg78D2z4gAnIgiuNhiAe014qeEB+9KO/P4Yp/f6TjecjgNypTiEumYpDP99/WO4dHs EIKBREyOdbAM/uz9v8EBPiriCN/ul4Lkw5yqSj292OvqxPuAi6ftOt5ExjLBK2bFnq56 nObPO+Xf12S3QEg8Cc/n8m9BMaD+noPvZ1MWeFe7A0CeeRhNeqmDzLPOnJ867icnr0Q5 KOFq4dF4bA7aV/eaSvjc0clB0V54yQs/pKaK0UNm8rDmeAX2ztO7nZ71Xf8opyfcIppN VxZg== X-Gm-Message-State: AOAM533AnNUiTZJrtf1pVnBqggig3npzMG4I48bQs+c4J2yIJkrqjQQ5 dmhB15xvvTfKQeUn4zxljpuLUh7uiSkmfPJfakvAQhtC2Kg7 X-Google-Smtp-Source: ABdhPJyaaUJTido/V14wtgQUks1ydomtPxBkgceON308EoGeiEdmstq25N32cJDlisxjoeccPw/y5jYf505wIrunHxU= X-Received: by 2002:a92:cacf:: with SMTP id m15mr15923197ilq.34.1593763128490; Fri, 03 Jul 2020 00:58:48 -0700 (PDT) MIME-Version: 1.0 References: <28698f3e3db608dceee910a8ba62ad7b6be0769f.camel@freebsd.org> In-Reply-To: Reply-To: kamalp@acm.org From: "Kamal R. Prasad" Date: Fri, 3 Jul 2020 13:28:37 +0530 Message-ID: Subject: Re: cv_wait To: Ian Lepore Cc: kamalp@acm.org, freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 49ynQz5Yb0z3fwj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 07:58:52 -0000 i implemented your suggestion nd when system ws going down, i got this stack trace lock order reversal: (sleepable after non-sleepable) 1st 0xffff000001302990 umtxql (umtxql) @ /b/kamal/stable11/src/sys/kern/kern_umtx.c:499 2nd 0xffff000001c656a0 allproc (allproc) @ /b/kamal/stable11/src/sys/kern/kern_proc.c:399 stack backtrace: #0 0xffff0000001d54d0 at witness_debugger+0x58 #1 0xffff000000181514 at _sx_slock+0x6c #2 0xffff000000163efc at pget+0x38 #3 0xffff00000018ce54 at kern_clock_gettime+0x3cc #4 0xffff00000019c2bc at do_sem2_wait+0x494 #5 0xffff00000019cc7c at __umtx_op_sem2_wait_compat32+0x80 #6 0xffff0000002e2f90 at do_el0_sync+0x9c8 #7 0xffff0000002c8200 at handle_el0_sync+0x84 thanks -kamal On Fri, Jul 3, 2020 at 1:15 AM Ian Lepore wrote: > On Fri, 2020-07-03 at 00:52 +0530, Kamal R. Prasad wrote: > > witness threw a panic saying that there is a potential deadlock. I > > dont > > have the exact msg as I changed the algo and lost the console logs. > > the common code has a mtx_lock() and mtx_unlock() to guard against > > race > > conditions. > > i just want to use a synchrnization primitive that will not hold any > > locks > > when calling the common code from the cs. > > so, pl feel free to suggest any alernativves. > > > > thanks > > -kamal > > > > Maybe an sxlock is what you're looking for. > > void function1() > { > sx_xlock(&sc->cs_lock); > common_func(); > sx_unlock(&sc->cs_lock); > } > > void function2() > { > sx_xlock(&sc->cs_lock); > common_func(); > sx_unlock(&sc->cs_lock); > } > > That would ensure that only one caller at a time is in the critical > section that calls common_func() (if it's just common_func() that > needs protecting, I'd put the sx_xlock in there). But I'm not sure how > that's different than using a standard mutex, unless your common code > was trying to sleep (or use malloc with WAIT_OK). If using a standard > mutex caused witness to warn about an unbounded sleep while holding a > mutex, then using the sxlock should fix that. > > Also, you should look at 'man locking' if you haven't already. > > -- Ian > > > > > > > On Fri, Jul 3, 2020 at 12:37 AM Ian Lepore wrote: > > > > > On Fri, 2020-07-03 at 00:36 +0530, Kamal R. Prasad wrote: > > > > but if i am doing cv_wait() for the first time, should someone be > > > > calling cv_signal for it to proceed? > > > > my algo is something like this in my driver:- > > > > function1() > > > > { > > > > mtx_lock(&sc->sc_mtx); > > > > cv_wait(&sc->sc_cv); > > > > mtx_unlock(&sc->sc_mtx); > > > > .... > > > > critical section > > > > .... > > > > cv_signal(&sc->sc_cv); > > > > } > > > > > > > > function2() > > > > { > > > > mtx_lock(&sc->sc_mtx); > > > > cv_wait(&sc->sc_cv); > > > > mtx_unlock(&sc->sc_mtx); > > > > .... > > > > critical section > > > > .... > > > > cv_signal(&sc->sc_cv); > > > > } > > > > --------------------- > > > > i want to protect critical section. The critical section calls a > > > > common > > > > piece of code which has some locks. if i put in locks to guard > > > > the > > > > cs, it > > > > triggers a call to witness(). > > > > > > > > Update: i saw an implementation wherein they used a callout to > > > > periodically > > > > send a cv_signal(). i could do that but the pt of this > > > > implementation > > > > is > > > > that cs in either of these functions should not be eecuting at > > > > the > > > > same > > > > time. > > > > > > > > thanks > > > > -kamal > > > > > > > > > > A condition variable doesn't work the way you're trying to use it. > > > > > > What is the complaint from witness? What type of locks are used in > > > the > > > common code that causes a complaint? Are any of these functions > > > involved called from interrupt handlers (that also imposes > > > restrictions > > > on what kind of locking you can do)? > > > > > > -- Ian > > > > > > > > > _______________________________________________ > > > freebsd-arm@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > To unsubscribe, send any mail to " > > > freebsd-arm-unsubscribe@freebsd.org" > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Fri Jul 3 14:52:24 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C7352350951 for ; Fri, 3 Jul 2020 14:52:24 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49yyc74GQyz4MfX for ; Fri, 3 Jul 2020 14:52:23 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Fri, 03 Jul 2020 14:52:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1593787940; bh=sH4UU7CqvTRZK/9uWBKdUJ+r4l0kriDcqA6MN1LMMe4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=JsaqwV9Wv4CuQgdUDCzxymPIYkBRPY9nRd+xNsIGKotBNnCZvvB4nzG2mzh9LKQ/P Pr6cQMDr+/2A3mZS/5Rj7JG5y1opLZMnNmSXFCoYIOnpIn7cwyZ9IA1jR28nhk4Q9g J0oFb46Xt44ZOlR8omczFl0aqjI//7GxwVHIYk38= To: myfreeweb From: Dan Kotowski Cc: freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: References: _____<71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49yyc74GQyz4MfX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=JsaqwV9W; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.18 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-3.80 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; NEURAL_HAM_LONG(-1.00)[-1.003]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.02)[-1.023]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.68)[-0.678]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[185.70.40.18:from]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.18:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 14:52:24 -0000 > > > Well, normally PCIe devices can address all the space, unless you hav= e terribly quirky hardware (on the RPi4, PCIe can address 3GB only..) > > > Also I would guess that like.. yes, even if PCIe goes through the SMM= U, if the SMMU is untouched by the OS, interrupts should arrive where the O= S expects it normally. > > > > > > > And section 4.1.6 System MMU and Device Assignment > > > > """ > > > > If a device is assigned and passed through to an operating system u= nder a hypervisor, then the memory > > > > > > We're running on bare metal, this is about VMs. > > > > So even though that stub only returns ENXIO, it should not matter unles= s I intend to use bhyve or something like that? > > > > > > I'm almost surprised that nobody has bumped into this before. How d= oes the IORT look on the MACCHIATObin if interrupts are NOT mapped behind S= MMU? > > > > > > There is no IORT on the mcbin.. armada8k has a GICv2 not v3 :D > > > > I'm also interested in acquiring one of those as well at some point, bu= t your posts indicate that the net ifaces on that are basically dead weight= under FreeBSD as well :( > > For a desktop, USB Ethernet is enough :D > > > > Socionext SynQuacer has the PCI node pointed to the ITS node. > > > > 24x A53 cores... hmmm... > > Yeah, very low single core perf, especially for that price :/ > > > > If I'm reading the table disassembly correctly, the Ampere eMAG has P= CI nodes pointing to SMMU (v1/v2). But FreeBSD works there fine! > > > That means the "fallback" non-IORT calculation of RIDs works fine the= re. But maybe it doesn't on the NXP chip because it's buggy. > > > But there was some way to get the interrupts (without supporting SMMU= ) on this NXP chip =E2=80=93 as evidenced by NetBSD working! > > > Again.. can you flash the firmware where PCIe was working under NetBS= D, dump the IORT there and also try patched (with D25179, e.g. any of my re= cent builds I guess) FreeBSD there? > > > > https://gist.github.com/agrajag9/a59b6c440365745c5a4036e0faf6e23c > > Yeah, so the "old" does have "Output reference : 0x30" under the PCIe roo= ts. For my own edification, let me know if I'm reading this all correctly. >From DEN0049D: "A reference to the output IORT Node. This field contains the address offs= et of the IORT Node relative to the start of the IORT. For example, if this= ID mapping is for a root complex outputting to an SMMU, the value of this field isthe difference between the start ofthe SMMU IORTnode and the start of the IORT." In the old firmware, under the Root Complex Nodes, `Output reference: 0x30`= points to the ITS Node with node offset 0x30. Then in the new firmware, under the Root Copmlex Nodes, `Output reference: 0x48` points to the SMMU with node offset 0x48. Is this what you meant when you said everything is "behind the SMMU"? > So does NetBSD PCIe only work on "old"? Correct. > FreeBSD still not working anywhere? Also correct :( > I guess another interesting thing to check would be Linux configured with= out any SMMU support.. Probably a good test! I'll see if I can make a build without it. As for building my own world... What patches are we applying right now? I think some new builds would be go= od, including one with all the stuff we've fixed - like AHCI - but with the= NXP PCIe code so I can test on the old firmware. If I'm keeping track corr= ectly, this includes: - D20835: enable tagged pointers - D20974: Port sbsawdt drive from NetBSD - D21017: armv8crypto: add AES-XTS support - D24423: arm/pmu: add ACPI attachment, more FDT names - D25145: acpi_resource: support multiple IRQs - D25157: ahci_generic: add quirk for NXP0004 - D25179: acpi_iort: fix mapping end calculation Any others? From owner-freebsd-arm@freebsd.org Fri Jul 3 22:44:37 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E22A035B6A7 for ; Fri, 3 Jul 2020 22:44:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49z9505NtLz3byS for ; Fri, 3 Jul 2020 22:44:36 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 063MiY8n036601 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 3 Jul 2020 15:44:34 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 063MiXZM036600; Fri, 3 Jul 2020 15:44:33 -0700 (PDT) (envelope-from fbsd) Date: Fri, 3 Jul 2020 15:44:33 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: 1341MB swap in use with half gig of free memory Message-ID: <20200703224433.GA36511@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 49z9505NtLz3byS X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [3.90 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.92)[0.925]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.53)[0.532]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.54)[0.544]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 22:44:37 -0000 In watching wwwchromium (very) slowly compile on a Pi3 running r362742-current something strange showed up: It had half a gig of "free" memory, but still has over a gig of swap in use. The swap device is saturated. Here's snippet of top output: last pid: 77187; load averages: 0.56, 0.80, 0.82 up 4+19:29:15 14:39:56 39 processes: 1 running, 38 sleeping CPU: 0.1% user, 0.0% nice, 0.2% system, 0.1% interrupt, 99.6% idle Mem: 80M Active, 63M Inact, 3508K Laundry, 176M Wired, 97M Buf, 580M Free Swap: 3547M Total, 1341M Used, 2206M Free, 37% Inuse, 1188K In It isn't entirely stuck, every few minutes free memory wanders down to 20MB and one core reaches 100% use, but in general it seems to keep considerable free memory in preference to reducing swap use. That would seem to be unhelpful in this use case. The machine has a 1TB mechanical hard disk with a single root partition and single swap partition. Make is running without explicit -j value, and appears to be attempting -j4. Earlier in the build it seemed to be running more rapidly, but over the last day or so it has gone from mostly busy to mostly idle with not much change in swap use. There are no errors or warnings on the console, and no complaint about swap quantitiy on boot. Obviously it's possible to use -j or MAX_JOBS_NUMBER, but reluctance to keep all memory in use makes me wonder if something else is amiss. Looking at man tuning revealed nothing I recognized as relevant. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Fri Jul 3 23:27:58 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6826035BA7D for ; Fri, 3 Jul 2020 23:27:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49zB311Fzvz3dVw for ; Fri, 3 Jul 2020 23:27:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: X6Am4a4VM1mh6LXsvLSP.ChLnM0h1BaRqO.EA14twhzcpViLa_L1BOCxr3jPzRf P21Ri9ms7Y.wwLMZ..CUfQJd2THDrkL_l1Dyxt6qYoAbVqWhbGRPeDBuKDhQkuLEKsNvNDO3K5UO HkI88j964.Ne9fLknjBepxHht85BfvszdZ14EEz9qNId2zhP50jh49ghNkjSAprRjLFmbMS1KDdh iHM3CgLC.zKfKBA0BdOizXOQWLNEe417hw.c8_EBgJKyDC6hFxx406yzqwjcV03.maNioFcUxpuM 4siuGg9tZYkhYY5V.yeYleSTCmTCZTBApiVaRLYf5CNzDSv5SAGfV2_j7Qu3qxz3NSZyrTaO4AHw eAZsWqygRc7.resBzCxJpWnLPw1tcz8zpNjAPETb0Gdb5ewDCpRS_3UoKB28n9tNdSsm5hpgxVzD oGeenrtGkoQgEtJXlQ2eqGDsC9C.k8m5aFNv41l.EjM4vBGbNUHzqURYahJcDFMl57iM4Cf227op xXTq9NH6VvJf2h69sDmbdkRsNB6PHUjd3MM_GjmWQ5Wv3u4n1EGMOF0puP5H1vopoezq4fjKwBdX EPCOFB22pgsnFNov6Ax_qRYMFt0q_HRsUkeu05T2pvDLzJZUogQ8ot3XDCVYSm3q1V9rrGMJa47W llKK0N0VCdjdz.5Kt7C_6k5sFIKJEvUGMyiRVdLGPuWAPb809c7NO5YczBSKVqOT3F_g9Z2G1EbJ N0fC_FJk3sMGQSdLprLsFJb.cYLctz.iFJuAGBGoBidXmuTX3Y8lEtpv.tuFCxa9pwRJjWUmykZo Fy_KXRJMN_vpMtcWJM4TQhM7H_EnHeNpKCG_IO1HUUNuUc1LF40FiBxr5N9q_ZVUvg49m7fJRj7V d7OCBbriDPvpwzBC3MwBanunKWNzs5By5HE2nrc32jTBJfhYR8OMdYbPiAJ2x6ruNQL5P8YCXXI6 j4_D5lbDgWYjKATYRD8sjF3YB_O5_hTBLdz9a8.Lu_UrMAwiVKWGAgAy2jVsnEkvvpaQwpDPv.Zz sfRluGFBMoraSeM5DoWNVdQNSuLMgCTup17nHBu3JFBNaEZTnk_1931vpN9iZZNy3dHrOE0yyy5u aJJo885wTXGTE0pXDzYpCT7ZY46luuIq22uQMDJ8AlfuGWBVXEEVA2vuwwt0UskIJ.sS6qL3BqkX t45GZuyh4oTLLdj7xVm5SwBb8GC5py_THxhmDBN6UpyQdmdYWCSldfTG7HTvOk.uInuxP.FcuNUS fNWux7IvHGybbGJedY6imYYBAxJugOlw0JXOAhXn1f5Mc7KHNOkzKyohBiIuuVHzYB.9tgDZY42P Uk5gwZ36d1EXV4cZJ6yeeNRAUU5X1sZDB3oXhG9PWGKb8D6P4zUV46lUhOxFKUSq4orWOKtl_kG6 vR7FCd97ayiyUdJ0WcUk- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 3 Jul 2020 23:27:55 +0000 Received: by smtp418.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9b87479623f69d52ef85cfc66af8e3e5; Fri, 03 Jul 2020 23:27:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: 1341MB swap in use with half gig of free memory From: Mark Millard In-Reply-To: <20200703224433.GA36511@www.zefox.net> Date: Fri, 3 Jul 2020 16:27:49 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <69F3DAD2-9BFD-4D74-8E80-E8761E740606@yahoo.com> References: <20200703224433.GA36511@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49zB311Fzvz3dVw X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.28 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.01)[-1.011]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; NEURAL_HAM_SHORT(-0.78)[-0.783]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 23:27:58 -0000 On 2020-Jul-3, at 15:44, bob prohaska wrote: > In watching wwwchromium (very) slowly compile on a Pi3 running > r362742-current something strange showed up: It had half a gig=20 > of "free" memory, but still has over a gig of swap in use. The=20 > swap device is saturated. >=20 > Here's snippet of top output: >=20 > last pid: 77187; load averages: 0.56, 0.80, 0.82 = up 4+19:29:15 14:39:56 > 39 processes: 1 running, 38 sleeping > CPU: 0.1% user, 0.0% nice, 0.2% system, 0.1% interrupt, 99.6% idle > Mem: 80M Active, 63M Inact, 3508K Laundry, 176M Wired, 97M Buf, 580M = Free > Swap: 3547M Total, 1341M Used, 2206M Free, 37% Inuse, 1188K In >=20 > It isn't entirely stuck, every few minutes free memory wanders down to=20= > 20MB and one core reaches 100% use, but in general it seems to keep > considerable free memory in preference to reducing swap use. That = would > seem to be unhelpful in this use case. =20 >=20 > The machine has a 1TB mechanical hard disk with a single root = partition > and single swap partition. Make is running without explicit -j value, > and appears to be attempting -j4. Earlier in the build it seemed to be > running more rapidly, but over the last day or so it has gone from = mostly > busy to mostly idle with not much change in swap use. There are no = errors > or warnings on the console, and no complaint about swap quantitiy on = boot. >=20 > Obviously it's possible to use -j or MAX_JOBS_NUMBER, but reluctance = to > keep all memory in use makes me wonder if something else is amiss. > Looking at man tuning revealed nothing I recognized as relevant.=20 I'll remind of past discussions of how long paging out and paging in large mounts of swap/paging content can take. So, say, a process finishes and frees memory and another process starts demand paging in pages that had been paged out and sends most of its time doing that to establish a better sized working set for its large amount of RAM use. Say it tries to page in 512 GiBytes or so, for simplicity. For your combination of devices, how long would that take? Quoting an older message exchange that had old gstat and other information information about the amount of time spent reading and how fast the reading activity was going in such a context: QUOTE > As for being "saturated": >=20 > At 321 KB/s (the example in the gstat output), if it was loading > something large, such as 512 MiBytes, just basically reading that > much material at a mean of such a rate would be over 25 minutes: >=20 > 512*1024*1024_bytes * (1sec/(321*1024_bytes)) * (1minute/(60sec)) >=20 > (Not that I know the 512 MiByte is realistic or that the 321 > KiBYtes/sec is a realistic mean rate.) This just gives an idea > what might be involved and that being beyond seconds or even a > small number of minutes for the general time scale may well be > possible. >=20 > Extensive paging/swapping can vastly slow things down. >=20 That is a startling realization.=20 END QUOTE I'm not saying that 321 KiB/s or so is what you were seeing this time. But seeing how much time is going to read in from the swap/paging device (processes waiting on paging I/O) and what sort of I/O rates it is experiencing for the swapping/paging device(s) (gstat) for the overall effect is relevant information. A way to avoid such issues is to use systems with enough RAM to avoid needing 1341M of swap being in use for the same -jN. Another way is to use a device with better I/O characteristics for the swapping and paging activity, such as avoiding seek times being nearly as large (and more). Or both. As stands you are not just keeping all RAM in use, you are keeping much of the swap/paging space in heavy use as well. Both CPUs and RAM end up waiting on paging/swapping I/O in order to deal with the original memory access requests by programs. Without other details, such generic points are all that I have. But they may point a direction for your activity or your investigations of the issue. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Jul 3 23:40:03 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3E70335C30A for ; Fri, 3 Jul 2020 23:40:03 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49zBJy0JfFz3ddC for ; Fri, 3 Jul 2020 23:40:01 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) by vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id 063NdjFg098100 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 4 Jul 2020 09:39:50 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id 063NdcMH020332 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Jul 2020 09:39:38 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id 063Ndcwo020331; Sat, 4 Jul 2020 09:39:38 +1000 (AEST) (envelope-from peter) Date: Sat, 4 Jul 2020 09:39:38 +1000 From: Peter Jeremy To: bob prohaska Cc: freebsd-arm@freebsd.org Subject: Re: 1341MB swap in use with half gig of free memory Message-ID: <20200703233938.GB30039@server.rulingia.com> References: <20200703224433.GA36511@www.zefox.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <20200703224433.GA36511@www.zefox.net> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp X-Rspamd-Queue-Id: 49zBJy0JfFz3ddC X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com X-Spamd-Result: default: False [-4.78 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.016]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.02)[-1.016]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[rulingia.com]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.35)[-0.345]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 23:40:03 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-Jul-03 15:44:33 -0700, bob prohaska wrote: >In watching wwwchromium (very) slowly compile on a Pi3 running >r362742-current something strange showed up: It had half a gig=20 >of "free" memory, but still has over a gig of swap in use. "Swap in use" relates to memory that has been pushed out to the swap device and not referenced since. There can be both lots of swap used and lots of free memory if the system has been under memory pressure (eg a large process) in the past but isn't now. The system will not move data from swap back into RAM unless it's referenced. A typical FreeBSD system will have lots of mostly idle processes and it's fairly normal for them to get paged out. > The swap device is saturated. > >Here's snippet of top output: > >last pid: 77187; load averages: 0.56, 0.80, 0.82 up = 4+19:29:15 14:39:56 >39 processes: 1 running, 38 sleeping >CPU: 0.1% user, 0.0% nice, 0.2% system, 0.1% interrupt, 99.6% idle >Mem: 80M Active, 63M Inact, 3508K Laundry, 176M Wired, 97M Buf, 580M Free >Swap: 3547M Total, 1341M Used, 2206M Free, 37% Inuse, 1188K In That shows page in only - so the system is trying to get data out of swap to fill the free memory. And >1MBps means it's not stuck. >It isn't entirely stuck, every few minutes free memory wanders down to=20 >20MB and one core reaches 100% use, but in general it seems to keep >considerable free memory in preference to reducing swap use. That would >seem to be unhelpful in this use case. =20 The "every few minutes ... one core reaches 100%" implies that every few minutes one process manages to get hold of enough RAM to work through a compiling a file. That process then exits and all the RAM it was using returns to the free pool. >Obviously it's possible to use -j or MAX_JOBS_NUMBER, but reluctance to >keep all memory in use makes me wonder if something else is amiss. I don't think so. The default "run one build process per core" assumes that there's adequate RAM. It's really difficult for the build process to know how big a process will get, and so automatically cut back on the number of parallel processes it spawns. This is one case where I don't believe there is any alternative to manually specifying "-j1" or equivalent. Note that Chromium is a massive chunk of code. A more normal build environment would be several dozen quite fast cores with around 3GB RAM per core. You are really stressing the VM system by trying to build it with ~256MB/core. No. =20 >Looking at man tuning revealed nothing I recognized as relevant.=20 > >Thanks for reading! > >bob prohaska > >_______________________________________________ >freebsd-arm@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-arm >To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Peter Jeremy --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE2M6l8vfIeOACl4uUHZIUommfjLIFAl7/wa9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQ4 Q0VBNUYyRjdDODc4RTAwMjk3OEI5NDFEOTIxNEEyNjk5RjhDQjIACgkQHZIUommf jLKfQA/+JATJK6hQSEq2hLAH+dWaNfdDh8ML6ivc5KTlFJAuBtl0x5Mi3x1qu74z 9cYroDwJJIfjLRS28allmf9NPMKLlx0OXNSVnieF2eNglJaH9Pk9wWwJDdn28rYK k/quWwFUVCZaMO7KQhwFrWKBKMGCna+OMgu9mX4TKA1SdmBpy45QDHBwbubl+m18 TdkMbkZCgEEunAUFwLrpW55W5FD+GWzNsXMbcGs/YlqBNzBHPhsjKTp1OR57Xd2L +8xhGMPodWoT08DW4mGbyI53hbvTdIQkUyZjhgHrFy5hhHOQN80WjgKyUrXBRCBD ldMsei9Jn6E4rd5FzVgX7XVIAR4q9u0ih4ZlQ/l52XaqItMcbYc970XHo/bqjINP nUXEfz1syWs8ZxXCgtXDEVeI3dwnVoPzg5flIWbnH3lW9jsz8NAtZ6/tCAz7XfGU R7rJ3KhgATQdOKuYgcXyYWvXlq88hW3ymNrm/oIDj84aKIBkwapQ3nosvzwoJfRo kLuEoere9om0amVeSAR6xX5ENsK/NScR9jEd5NAMBW10IgxJj6P/qYA7MwpaPIYy iVOw3Q+K6Y8gjWVRBYs7eYY/rkeHkstW2pKUNT2IU3O3PBxXP1dXeucQYRJSJ1Dz gyKo5oPabQuBfohvEOKMu34cHP+7FZ17Qn5YL26pF94ID5Z4xs0= =h6NF -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From owner-freebsd-arm@freebsd.org Fri Jul 3 23:43:13 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8343435C29D for ; Fri, 3 Jul 2020 23:43:13 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out1.migadu.com (out1.migadu.com [IPv6:2001:41d0:2:863f::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49zBNc3thVz3f8M for ; Fri, 3 Jul 2020 23:43:12 +0000 (UTC) (envelope-from greg@unrelenting.technology) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1593819784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V7pmJVEa8unIqFULTrMxTh0gPaW1VolbqSYAJHA7YIo=; b=h2sLYgCcxZ/2TygoP78kei7QM8r75qY+f9RLH2ONqEXvMJCzGUSjCz5Qwd17CLb4Vl6Epa KnR8zBHaoThe3gUIcDJ00wy4cZtXw/Z4XJD8006C3DM0JYh6P+oN0IRfPu6WyCqfKR8fzI lLqqa1qDvz20nS6o5dOlQ0MTuJ6HUfY= Date: Fri, 03 Jul 2020 23:43:03 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: greg@unrelenting.technology Message-ID: <8a3f78ddd5136ef22c59e9f7b1b23ca6@unrelenting.technology> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X To: "Dan Kotowski" Cc: "freebsd-arm" In-Reply-To: References: _____<71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology> X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 49zBNc3thVz3f8M X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=h2sLYgCc; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 2001:41d0:2:863f:: as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-3.43 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.967]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:863f::]; NEURAL_HAM_LONG(-0.99)[-0.989]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-0.47)[-0.472]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 23:43:13 -0000 July 3, 2020 5:52 PM, "Dan Kotowski" wro= te:=0A=0A> In the old firmware, under the Root Complex Nodes, `Output ref= erence: 0x30` points to the ITS Node=0A> with node offset 0x30.=0A> =0A> = Then in the new firmware, under the Root Copmlex Nodes, `Output reference= :=0A> 0x48` points to the SMMU with node offset 0x48.=0A> =0A> Is this wh= at you meant when you said everything is "behind the SMMU"?=0A=0AYes.=0A= =0A> What patches are we applying right now? I think some new builds woul= d be good, including one with=0A> all the stuff we've fixed - like AHCI -= but with the NXP PCIe code so I can test on the old=0A> firmware. If I'm= keeping track correctly, this includes:=0A> =0A> - D20835: enable tagged= pointers=0A> - D20974: Port sbsawdt drive from NetBSD=0A> - D21017: armv= 8crypto: add AES-XTS support=0A> - D24423: arm/pmu: add ACPI attachment, = more FDT names=0A=0AThese are not directly related to running on NXP, jus= t random improvements :)=0A=0A> - D25145: acpi_resource: support multiple= IRQs=0A> - D25157: ahci_generic: add quirk for NXP0004=0A> - D25179: acp= i_iort: fix mapping end calculation=0A=0AYes, these three.=0A=0AHere's th= e pci_layerscape patch:=0A=0Ahttps://github.com/DankBSD/base/commit/c1ea4= 4aa33b29f74daed89eee82b3dfeb105d376.patch=0A=0AIf we haven't tried it + a= cpi_iort fix before, which is quite likely, maybe that's a combination th= at would work.=0A(I remember when we tried it only, there was only the sa= me interrupt problem as usual..)=0A=0AIt's honestly kinda weird that "old= " FW requires the custom controller access while "new" FW requires *not* = doing it >_< From owner-freebsd-arm@freebsd.org Sat Jul 4 01:15:57 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2933135E051 for ; Sat, 4 Jul 2020 01:15:57 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49zDRb6r3hz40rj for ; Sat, 4 Jul 2020 01:15:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 0641FwcS036992 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 3 Jul 2020 18:15:59 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 0641Fwnq036991; Fri, 3 Jul 2020 18:15:58 -0700 (PDT) (envelope-from fbsd) Date: Fri, 3 Jul 2020 18:15:58 -0700 From: bob prohaska To: Peter Jeremy Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: 1341MB swap in use with half gig of free memory Message-ID: <20200704011558.GA36886@www.zefox.net> References: <20200703224433.GA36511@www.zefox.net> <20200703233938.GB30039@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200703233938.GB30039@server.rulingia.com> X-Rspamd-Queue-Id: 49zDRb6r3hz40rj X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [3.18 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.40)[0.398]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.59)[0.585]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.30)[0.300]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 01:15:57 -0000 On Sat, Jul 04, 2020 at 09:39:38AM +1000, Peter Jeremy wrote: > > The "every few minutes ... one core reaches 100%" implies that every few > minutes one process manages to get hold of enough RAM to work through a > compiling a file. That process then exits and all the RAM it was using > returns to the free pool. > That's one point I was entirely missing. When the only runnable thread finishes, nothing else can run till a working set has been swapped back into ram. As Mark reminds me, at 2MB a second, it easily takes minutes of doing nothing but reading swap to be able to run anything. Thus, the long interval of seeming inactivity. > > I don't think so. The default "run one build process per core" assumes > that there's adequate RAM. It's really difficult for the build process > to know how big a process will get, and so automatically cut back on the > number of parallel processes it spawns. This is one case where I don't > believe there is any alternative to manually specifying "-j1" or > equivalent. > In this case (essentially that of a batch job with no interactive use) would using -j1 or -j2 reduce the overall compilation time? If I'm understanding correctly the answer is "no", -j1 precludes using extra cores when it's possible. From time to time it uses all four. > Note that Chromium is a massive chunk of code. A more normal build > environment would be several dozen quite fast cores with around 3GB RAM > per core. You are really stressing the VM system by trying to build it > with ~256MB/core. > A smaller browser would be a very welcome discovery. So far, chromium is the only one that has worked well enough to be useful. Thanks for writing.... bob prohaska From owner-freebsd-arm@freebsd.org Sat Jul 4 01:43:00 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 843CC35EAD3 for ; Sat, 4 Jul 2020 01:43:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49zF2p6Ft4z41r9 for ; Sat, 4 Jul 2020 01:42:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: T3Np228VM1nnmxg4CBg6VkTkBhCy2DQabrAS.jxHItDeuq.Mpwb3p3wwBGU4nWS 2GWaZQLALwoRnqmMCtDg4LKY6pTdFg_9vbmx0ZhJ9XUELZIxyWhhYR.92Q7h7EKjYzUKt_Zz8jqk fxWl.qLprPGl.76CQcLZ_Nv8782VK0_DmLM.qtlHOwKRiMyjDPlqykB06rss8iNx9b4iUGNQlQkV f78cRSZPUc0Ko7x6K_kn27uMejO7kSz_gyB95Uq.WZUcqomS0TjSLffe2Xyo1FznqilckRq5VETS XT9gCfNNxtkm4AybpcPWOBlNUxulWCyvXa08zJU__.IKaZmmtiL5UbqeLA1XyLtFl_qFqnqlLM_E nWgnutemPxkeCpcV3Xtu15usWUHc9fIvzljBpoqTsXG4KWqeAtYNvC8ZAQG9duNFV1EkYpp1GTt5 IXKxarwhlpGiShEjqz2Q0gaxtoUzT_4Sx3ffkraBgGDDxXXt.Uylu.OlDFiFAkiiWTVzK.2eNwVj 6e0il_PwVqfCW6uVZgIZg8ieeV6m99SbVWuetKthNtoOpp_vbGIELvX8ekglRAYTzp.bXx_jM.as HlqM7TJpnKq1bPtMzONVCxo03aJLQ1k9oLm_Gml.eWZ7MwXVVerG2c65rCAu5jV54VBZ4rHvIKDd x1VI8_OI2l4iNELmw6Ww4AQI_KMhVsVMPA.L_MtkQSbELhkeSwNwOs5UY_Jr0YxqnRei2z2wyvMA PJ3N8lmgXbg7um8IN6bPf1O7hCVFqc8TzDNjjrEJi9xODLN7fiJaOOAs_QjXMMMS_Icc7fYeqjxq 99DtviwS2m95LihHgMQ8U6JvCe9V3E.FkG9OXq.eFBkcvvv2wlGTkQtiCtl8LjBK1qraQx.ivuZz I9hEHbqhbjyvPVzP3rUc9rjLfz0h67UPxmVgmK840YA0gt9u0hJaoXRLq.WMK9Re3gocPbPV.2Zz dKIR3_6FoMHTpTVIKMDouWszCyXOtVacrdpAw3vy9h4V7_DGKuqXINLS..8b0hKN.FQnw.e8Si7P sj.EldJkhOhGTOYLgBVLzhfZ5V5rA0sKbwhLuq7Lcydzk2U8T8iofEXNbQ5hBW0e32ziD31l0W3w .MeZuLnINfjEuEm.XtMFjMSAYUkG2oXetF6rFXQZVZIYS9YdKd1BQgyT8Ovy.P5eT9uar6whBbEJ 9BrRjyySChcWtvq6nnDr7iPeWo2TzWFbwc4NZCulZpx8G48YyCJ0s46t7dEtIDvjz6zazsHFqBtL 1gzsRQYq5K.tZVZ7ELZ91z63adUWuw.KC5po2yLzpHlmn.d66573M8g3zaJ.Dgpc016JEqszCsi2 pyIx_TPkJ0LalS5Q9LFKvagzqDtjvKWmd325VosIkv2EdHB9yg7a.ttix0jDgtwtRBG9Q4GqptUi ScwJKL4rsKJUrV76jF6aoUNn9Y0Jq7wrvEx4lA7QsUG6nKcOv6EKVwkZsovkFwro- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 4 Jul 2020 01:42:57 +0000 Received: by smtp402.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2b3be4f77de2ddc6a94e5c2513c86278; Sat, 04 Jul 2020 01:42:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: 1341MB swap in use with half gig of free memory From: Mark Millard In-Reply-To: <20200704011558.GA36886@www.zefox.net> Date: Fri, 3 Jul 2020 18:42:51 -0700 Cc: Peter Jeremy , freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <55D7CE27-DEA4-4F58-904A-D68D33845922@yahoo.com> References: <20200703224433.GA36511@www.zefox.net> <20200703233938.GB30039@server.rulingia.com> <20200704011558.GA36886@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49zF2p6Ft4z41r9 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.43 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.02)[-1.015]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; NEURAL_HAM_SHORT(-0.92)[-0.925]; NEURAL_HAM_MEDIUM(-0.99)[-0.988]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 01:43:00 -0000 On 2020-Jul-3, at 18:15, bob prohaska wrote: > On Sat, Jul 04, 2020 at 09:39:38AM +1000, Peter Jeremy wrote: >> >> The "every few minutes ... one core reaches 100%" implies that every few >> minutes one process manages to get hold of enough RAM to work through a >> compiling a file. That process then exits and all the RAM it was using >> returns to the free pool. >> > That's one point I was entirely missing. When the only runnable thread > finishes, nothing else can run till a working set has been swapped back > into ram. As Mark reminds me, at 2MB a second, it easily takes minutes > of doing nothing but reading swap to be able to run anything. Thus, > the long interval of seeming inactivity. Where you actually seeing a sustained 2 MiByte/sec rate over some significant amount of time during a "busy reading" activity? With paging/swapping being 4 KiByte random access I/O based (or some small multiple of that), I do not expect fast I/O from spinning-rust stye media. The amount of data that seems to be involved seems a bit much for drive-internal caching to well cover it. >> >> I don't think so. The default "run one build process per core" assumes >> that there's adequate RAM. It's really difficult for the build process >> to know how big a process will get, and so automatically cut back on the >> number of parallel processes it spawns. This is one case where I don't >> believe there is any alternative to manually specifying "-j1" or >> equivalent. >> > > In this case (essentially that of a batch job with no interactive use) > would using -j1 or -j2 reduce the overall compilation time? If I'm > understanding correctly the answer is "no", -j1 precludes using extra > cores when it's possible. From time to time it uses all four. The tradeoff structure is to complicated for me to predict specific time relationship. But I'd not be surprised to find that -j3 or -j2 would spend enough less time on paging/swapping I/O to end up using less overall time: higher fraction of the time able to work from RAM. To figure out the tradeoff's overall result would likely require experimenting/measuring the alternatives. Figuring out a better tradeoff combination for a tight-fit context such as this can be its own time-consuming activity. >> Note that Chromium is a massive chunk of code. A more normal build >> environment would be several dozen quite fast cores with around 3GB RAM >> per core. You are really stressing the VM system by trying to build it >> with ~256MB/core. >> > A smaller browser would be a very welcome discovery. So far, chromium > is the only one that has worked well enough to be useful. Not in my area of experience, I'm afraid. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Jul 4 02:08:43 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1190F35EC21 for ; Sat, 4 Jul 2020 02:08:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49zFcT5tF4z42jN for ; Sat, 4 Jul 2020 02:08:41 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 06428jDE037070 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 3 Jul 2020 19:08:45 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 06428jQA037069; Fri, 3 Jul 2020 19:08:45 -0700 (PDT) (envelope-from fbsd) Date: Fri, 3 Jul 2020 19:08:45 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: 1341MB swap in use with half gig of free memory Message-ID: <20200704020845.GB36886@www.zefox.net> References: <20200703224433.GA36511@www.zefox.net> <69F3DAD2-9BFD-4D74-8E80-E8761E740606@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69F3DAD2-9BFD-4D74-8E80-E8761E740606@yahoo.com> X-Rspamd-Queue-Id: 49zFcT5tF4z42jN X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [2.83 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.67)[0.667]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.21)[-0.209]; NEURAL_SPAM_LONG(0.47)[0.474]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 02:08:43 -0000 On Fri, Jul 03, 2020 at 04:27:49PM -0700, Mark Millard wrote: > > As stands you are not just keeping all RAM in use, you are > keeping much of the swap/paging space in heavy use as well. > Both CPUs and RAM end up waiting on paging/swapping I/O in > order to deal with the original memory access requests by > programs. > In fact I'd forgotten how long it takes to swap in enough data to re-start a thread. That idle time was what made me think something was wrong. My mistake. But, would restricting the number of usable cores using -j1 or -j2 reduce the overall compile time? Clearly, it would make the system more responsive to new demands by keeping resources in reserve, but this is basically a batch job. There are no other users to placate. So long as it doesn't get stuck more cores in use seem better. Thanks for writing! bob prohaska From owner-freebsd-arm@freebsd.org Sat Jul 4 02:22:34 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E4A0535F2A0 for ; Sat, 4 Jul 2020 02:22:34 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49zFwT6sMjz433j for ; Sat, 4 Jul 2020 02:22:33 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) by vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id 0642MOso098849 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 4 Jul 2020 12:22:29 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id 0642MIaH029804 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Jul 2020 12:22:18 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id 0642MIne029803; Sat, 4 Jul 2020 12:22:18 +1000 (AEST) (envelope-from peter) Date: Sat, 4 Jul 2020 12:22:18 +1000 From: Peter Jeremy To: bob prohaska Cc: freebsd-arm@freebsd.org Subject: Re: 1341MB swap in use with half gig of free memory Message-ID: <20200704022218.GD30039@server.rulingia.com> References: <20200703224433.GA36511@www.zefox.net> <20200703233938.GB30039@server.rulingia.com> <20200704011558.GA36886@www.zefox.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="t0UkRYy7tHLRMCai" Content-Disposition: inline In-Reply-To: <20200704011558.GA36886@www.zefox.net> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp X-Rspamd-Queue-Id: 49zFwT6sMjz433j X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com X-Spamd-Result: default: False [-5.51 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.018]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.02)[-1.015]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[rulingia.com]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.08)[-1.078]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 02:22:35 -0000 --t0UkRYy7tHLRMCai Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Something I missed before: When you say "Pi3", I presume you mean Raspberry Pi 3 Model B. None of the Raspberry Pi variants have provision for sanely attaching mass storage so I presume your 1TB HDD is attached via USB 2.0 - which is a further impediment to tranferring data fast. On 2020-Jul-03 18:15:58 -0700, bob prohaska wrote: >On Sat, Jul 04, 2020 at 09:39:38AM +1000, Peter Jeremy wrote: >In this case (essentially that of a batch job with no interactive use) >would using -j1 or -j2 reduce the overall compilation time? If I'm=20 >understanding correctly the answer is "no", -j1 precludes using extra=20 >cores when it's possible. From time to time it uses all four.=20 As Mark mentions, about the only real way to find out would be to actually try building with different -j options and see which is fastest. So long as the total working set size remains below the ~800MB usable RAM limit then more cores will speed it up. Once the system starts thrashing then goodput[1] drops to roughly zero. Unfortunately, the working set size varies widely. >A smaller browser would be a very welcome discovery. So far, chromium >is the only one that has worked well enough to be useful. If you just want to render HTML, images and some trivial JS, then something like links might do. Unfortunately, the modern Web has shifted to the point where the HTML is irrelevant and the actual content is mostly the result of executing quite complex JS within the browser - for those pages, you'll probably need Chrom{e,ium}, Edge, Firefox or Safari. [1] Useful throughput --=20 Peter Jeremy --t0UkRYy7tHLRMCai Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE2M6l8vfIeOACl4uUHZIUommfjLIFAl7/59RfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQ4 Q0VBNUYyRjdDODc4RTAwMjk3OEI5NDFEOTIxNEEyNjk5RjhDQjIACgkQHZIUommf jLLyGBAAsY6mFrOvl8Ui4v6rnOvH+I6s7/mvjnkNkbnR/FEHCI9sS17eP5Hxp/H7 c9N+oh7vhKf06T0jQ3Nvi0oqJyz1lIzNRU7HURYVAQkxxTGzSi4917v6K9S+834o OJcl/Sa0j1qFMVu3+j3S5FTH5UsdwxQWwG2EzCw+4+niOmoAJi1+BkMewqs10UiQ sa+N6LnfJHt+GTiSFbs6V5t+evUtpe9pRdApgxIe2s8IwwcrG6VlWBV+nWzJqXDa dKoeQ+NlDV4NZWcwcCEvRxSeegPRGVq6AY32UTTyPotJKrtqLglLVmKPZONq/Zut WyO8kkPFQ4wZ3EQAjyBoMXp6KQWcFK+K4mmzISwUOa6psL0L9Z2b3lwD5j7XzadX Y8JrG6dhOhW0Ubh5iw+ZW1BrCa3l7zIHmYu8ZYvzS0ROol+oPzqNaqMFf+4nGj4r qqAFER6kI0L6UYX1nySXZTOltbUPfVceVErkwt5rxTGT0ddFVJqD+w+L2iqFMbug DtBDV5jD6Xn/9mBxd7JFtLz6OXWrulmNOnCBkGBaidZhdLioUEpPOWAdeDKcqz/d Wvryv3BG8zRgxW72TQREO3Fw6P1WG0/dqM5lWFZ5cCTAWjDIq+nVIqaXGdqmar7p 5qmbTnoxI/YI+gkKraEeUoIBExkML5gBVVzBKT2K1D1q4VpkCaA= =F+cz -----END PGP SIGNATURE----- --t0UkRYy7tHLRMCai-- From owner-freebsd-arm@freebsd.org Sat Jul 4 04:37:05 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0869B361621 for ; Sat, 4 Jul 2020 04:37:05 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49zJvg2FLDz492x for ; Sat, 4 Jul 2020 04:37:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 0644b6Qu037430 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 3 Jul 2020 21:37:06 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 0644b61e037429; Fri, 3 Jul 2020 21:37:06 -0700 (PDT) (envelope-from fbsd) Date: Fri, 3 Jul 2020 21:37:05 -0700 From: bob prohaska To: Peter Jeremy Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: 1341MB swap in use with half gig of free memory Message-ID: <20200704043705.GC36886@www.zefox.net> References: <20200703224433.GA36511@www.zefox.net> <20200703233938.GB30039@server.rulingia.com> <20200704011558.GA36886@www.zefox.net> <20200704022218.GD30039@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200704022218.GD30039@server.rulingia.com> X-Rspamd-Queue-Id: 49zJvg2FLDz492x X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [2.39 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.53)[0.534]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.19)[-0.189]; NEURAL_SPAM_LONG(0.15)[0.147]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 04:37:05 -0000 On Sat, Jul 04, 2020 at 12:22:18PM +1000, Peter Jeremy wrote: > Something I missed before: When you say "Pi3", I presume you mean > Raspberry Pi 3 Model B. None of the Raspberry Pi variants have > provision for sanely attaching mass storage so I presume your 1TB > HDD is attached via USB 2.0 - which is a further impediment to > tranferring data fast. > Alas, little about my enterprise is sane 8-) These experiments are all on a Pi3B (not plus). The HDD is attached via a jmicron usb-sata adapter. However, the Pi4 at least in principle claims to support UASP. Unfortunately, it seems FreeBSD does not. That is a pity. > On 2020-Jul-03 18:15:58 -0700, bob prohaska wrote: > >On Sat, Jul 04, 2020 at 09:39:38AM +1000, Peter Jeremy wrote: > > As Mark mentions, about the only real way to find out would be to > actually try building with different -j options and see which is > fastest. So long as the total working set size remains below the ~800MB > usable RAM limit then more cores will speed it up. Once the system > starts thrashing then goodput[1] drops to roughly zero. Unfortunately, > the working set size varies widely. > Up to now I've only restricted -j values when trying to avert panics. Perhaps the experiment is worth a try even if nothing else goes wrong. Have you a notion whether adding additonal swap on microSD would do any good? Earlier experiments included it. This one omitted it by chance, never expecting the build to get this far. Knowing what to look for is helpful. > >A smaller browser would be a very welcome discovery. So far, chromium > >is the only one that has worked well enough to be useful. > > If you just want to render HTML, images and some trivial JS, then > something like links might do. Unfortunately, the modern Web has > shifted to the point where the HTML is irrelevant and the actual > content is mostly the result of executing quite complex JS within > the browser - for those pages, you'll probably need Chrom{e,ium}, > Edge, Firefox or Safari. It appears that links is a close relative of lynx. Both seem to work at www.freebsd.org, but the loss of layout information makes both rather hard to use. Firefox isn't much more compact than chromium, is Safari good anywhere but on a Mac? Edge is new to me. It shows up as /usr/ports/games/edge, but I don't think that's what you meant.... Any hints? Thanks for writing! bob prohaska From owner-freebsd-arm@freebsd.org Sat Jul 4 05:00:17 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BFB95361C04 for ; Sat, 4 Jul 2020 05:00:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49zKQS5W4pz49MN for ; Sat, 4 Jul 2020 05:00:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: oWquSeUVM1nEAsKs2HuNBUrMJ4MmQs7xIJVSWwKCzG9PBE.MjffVXTkg7eANjfw TklXhgQfFIFaQy5VqW8DY5Y2y6wXx8_i56h47s9Hglsjx2pb_ofR5ZdtYjrJUBKkgUoxUo2DWvJq jtmf6e1AJRnYFJUTPDe1Esyj3loCnIcUpAqBFdy.VW2idZ9zu5rK5d6SPeJJCFh8lTr.mpFmsTPU 5y1CYYZdaan5scw3SS8uoNG_q.UMKTntaaFz.e9G.E44POnhi43jZTWFLuHR.BjuK2I10J0zGYxB 3hdDYSPznhCo3hcE503Ox1wQtHxkU8wjnPP66fJeNPDqTYUYNk9PqgwxiKAJygRuBEWCgH9tlt60 p_h51hiSuBX3Dces5j46Ps_cEQfOsd_ISF7mHQCZnxZV3iHRERVCMR9b2PraM01jYId91tb7M.q9 3jVKg2.De18Y_rI8OvGwUUR85CQtqoukxBqLFVuylMIiWGDYFepWeXlaIaTpb1m3Qr.ISHKtxlqQ RGusfltvDDRFID_F6hIhy6kj9hMWIpX33MYBKELQTXSx8ITwPsbfGn8x9HcjRSztFGEMAWYNlb3w 91JGsRsWNWPJpuxvKTBD0nQXPiwtqDHaXrb57cUgqBtb3Vt_HHj4Y17gCVFGvEiSB_eOZiacYQwf ossZT4DY5oH1Uz7UYuFw_U8qBse8MkCFY4mgJBsF90jPyzbKrKcOrRI93kM1QqraIBNjr9JhWmfU xFFQSKsJ1ADskV37DjMy60cGjfxjLoLfLFbvmFHZ7uLJlY4V.tSGa67RHI_GXYZz4aj6Mtrf3Mo6 BQIhIxdAPkw76JzIilxTwGK9in.1xIMi9n6V3A8wpGcP85Z9fWdl13MZO9pB9Fmw0QYOC4lfzAdC oWhNzWhue4lw9ATyL5VVXPpXCtKRFZkeUIQIF97COAwaY1v.SYEuPi.TCVi3jVIU_re0KqZtFlU3 3JN4H5n804P9keqJx3BFkLRkLW3biswjX5J9i0beuKCE27OpNeR8fTQbCpJ_d8WM9t3kvkjtYYtT yJZdH0PbXIS8QTKHS89LbAK5Xfle1knJXvIZDNR4k8A8gi3AG3yCmWepM3HF51G8D2.EYHw69_Ch H2uVC0KTHSM24KeYLU42kasEizXr8bb_jYFfxvnPTiefOYwzRvLACNpSHweTMynA2J5PFrhDhhBc hfoiLVPatxJM9v6ngQ8iW5PmJthzA0pJaTh1PE1YuTtcx78nveU1RhfR9PB81035kWQxWeWLR1Wa lqfPA.Maf5hEFlGSXrNtPjlzXZRmuiiqOoQSX1Gbg9.tpUrX6lzEygYKPwuuhcymbg_YywfzosdD 7JYWq4rAH2jjrf7fhaT0pi4qgF8fqbURuU62IJ4cmH86FKQb3X6_VyxxyH0Td76xuZdGsPB6ODV7 eGQley07ofYlMN3TF5hBVqoBeMB0pPioANR3lnS2vOjd0dZw.XgyPi9S2b1c1Wv6LeOhG7oTfoSb qaTd_Sh8mOXj0DQ4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sat, 4 Jul 2020 05:00:14 +0000 Received: by smtp415.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 52699458de2a01821064462e1f430e3d; Sat, 04 Jul 2020 05:00:09 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: 1341MB swap in use with half gig of free memory From: Mark Millard In-Reply-To: <20200704043705.GC36886@www.zefox.net> Date: Fri, 3 Jul 2020 22:00:07 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <466762C6-D20A-410A-BF44-CD6ED8EC70AA@yahoo.com> References: <20200703224433.GA36511@www.zefox.net> <20200703233938.GB30039@server.rulingia.com> <20200704011558.GA36886@www.zefox.net> <20200704022218.GD30039@server.rulingia.com> <20200704043705.GC36886@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49zKQS5W4pz49MN X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.95 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.01)[-1.014]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from]; NEURAL_HAM_SHORT(-0.46)[-0.455]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 05:00:17 -0000 On 2020-Jul-3, at 21:37, bob prohaska wrote: > On Sat, Jul 04, 2020 at 12:22:18PM +1000, Peter Jeremy wrote: >> Something I missed before: When you say "Pi3", I presume you mean >> Raspberry Pi 3 Model B. None of the Raspberry Pi variants have >> provision for sanely attaching mass storage so I presume your 1TB >> HDD is attached via USB 2.0 - which is a further impediment to >> tranferring data fast. >>=20 >=20 > Alas, little about my enterprise is sane 8-) These experiments > are all on a Pi3B (not plus). The HDD is attached via a jmicron > usb-sata adapter.=20 >=20 > However, the Pi4 at least in principle claims to support UASP. > Unfortunately, it seems FreeBSD does not. That is a pity.=20 Even with umass/non-UASP, USB3 can transfer much faster than USB2. >> On 2020-Jul-03 18:15:58 -0700, bob prohaska = wrote: >>> On Sat, Jul 04, 2020 at 09:39:38AM +1000, Peter Jeremy wrote: >>=20 >> As Mark mentions, about the only real way to find out would be to >> actually try building with different -j options and see which is >> fastest. So long as the total working set size remains below the = ~800MB >> usable RAM limit then more cores will speed it up. Once the system >> starts thrashing then goodput[1] drops to roughly zero. = Unfortunately, >> the working set size varies widely. >>=20 > Up to now I've only restricted -j values when trying to avert panics. > Perhaps the experiment is worth a try even if nothing else goes wrong. >=20 > Have you a notion whether adding additonal swap on microSD would do > any good? Unlikely. You need to avoid paging I/O, not use a possibly even slower I/O mechanism. I'm not aware of the RPi3 having any likely "dual I/O channels" based improvement of note. > Earlier experiments included it. This one omitted it by > chance, never expecting the build to get this far. Knowing what to > look for is helpful. =46rom what I know of your past with microsd card based swap, it would not suggest the alternative. >>> A smaller browser would be a very welcome discovery. So far, = chromium >>> is the only one that has worked well enough to be useful. >>=20 >> If you just want to render HTML, images and some trivial JS, then >> something like links might do. Unfortunately, the modern Web has >> shifted to the point where the HTML is irrelevant and the actual >> content is mostly the result of executing quite complex JS within >> the browser - for those pages, you'll probably need Chrom{e,ium}, >> Edge, Firefox or Safari. >=20 > It appears that links is a close relative of lynx. Both seem to > work at www.freebsd.org, but the loss of layout information makes > both rather hard to use.=20 >=20 > Firefox isn't much more compact than chromium, is Safari good anywhere > but on a Mac?=20 >=20 > Edge is new to me. It shows up as /usr/ports/games/edge, but I don't > think that's what you meant.... Any hints? >=20 Edge is Microsoft's. Windows 10, 8.1, 8, 7; iOS, Android. (iOS might include iPadOS?) There is a legacy version as well. Edge is Chromium based. See the 1st paragraph of: https://docs.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Jul 4 10:32:08 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EE7F2348D64 for ; Sat, 4 Jul 2020 10:32:08 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49zSnN5Qvhz4Tyn for ; Sat, 4 Jul 2020 10:32:08 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: by mailman.nyi.freebsd.org (Postfix) id BA348348E2B; Sat, 4 Jul 2020 10:32:08 +0000 (UTC) Delivered-To: arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B9FCE348F8B for ; Sat, 4 Jul 2020 10:32:08 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49zSnM74sWz4Tq7 for ; Sat, 4 Jul 2020 10:32:07 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.163] (helo=mjail0.freenet.de) by mout2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.92 #3) id 1jrfSm-0001g8-NZ; Sat, 04 Jul 2020 12:32:04 +0200 Received: from [::1] (port=45056 helo=mjail0.freenet.de) by mjail0.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.92 #3) id 1jrfSm-0005fn-Mu; Sat, 04 Jul 2020 12:32:04 +0200 Received: from sub0.freenet.de ([195.4.92.119]:41728) by mjail0.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.92 #3) id 1jrfQY-0004Rl-01; Sat, 04 Jul 2020 12:29:46 +0200 Received: from p4fd9e4db.dip0.t-ipconnect.de ([79.217.228.219]:14274 helo=freebsd-t450.fritz.box) by sub0.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256) (port 465) (Exim 4.92 #3) id 1jrfQX-0000fY-Ta; Sat, 04 Jul 2020 12:29:45 +0200 Date: Sat, 4 Jul 2020 12:29:44 +0200 From: Manuel =?ISO-8859-1?Q?St=FChn?= To: "freebsd-arm@freebsd.org" Subject: Re: allwinner/i2c interrupt storm detected Message-Id: <20200704122944.64723bbb606d6e73128d2568@freenet.de> In-Reply-To: <10ACCB56-E18D-4102-B4E2-094157854AB7@cs.huji.ac.il> References: <10ACCB56-E18D-4102-B4E2-094157854AB7@cs.huji.ac.il> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Originated-At: 79.217.228.219!14274 X-Rspamd-Queue-Id: 49zSnM74sWz4Tq7 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsdnewbie@freenet.de designates 2001:748:100:40::2:4 as permitted sender) smtp.mailfrom=freebsdnewbie@freenet.de X-Spamd-Result: default: False [-1.91 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[freenet.de]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2001:748:100:40::2:0/112]; ARC_NA(0.00)[]; DMARC_NA(0.00)[freenet.de]; NEURAL_HAM_LONG(-0.94)[-0.937]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.81)[-0.810]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2001:748:100:40::2:4:from]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; R_MIXED_CHARSET(0.62)[subject]; ASN(0.00)[asn:5430, ipnet:2001:748::/32, country:DE]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[freenet.de]; RECEIVED_SPAMHAUS_PBL(0.00)[79.217.228.219:received] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 10:32:09 -0000 On Tue, 30 Jun 2020 16:01:41 +0300 Daniel Braniss wrote: > Hi, >=20 > after a long time I decided to try and upgrade to stable 12.1 r362793 sin= ce I saw some changes where done=20 > with respect to the DTS and twsi.c,=20 >=20 > if nothing is connected to the i2c, i2c -s just hangs, >=20 > if something is connected this is what i get on the console after typing = ?i2c -s? >=20 >=20 > Hardware may not support START/STOP scanning; trinterrupt storm detected = on "gic0,s6:"; throttling interrupt source > ying less-reliable read method. > interrupt storm detected on "gic0,s6:"; throttling interrupt source > interrupt storm detected on "gic0,s6:"; throttling interrupt source > ? >=20 > and > neo-04> vmstat -i > interrupt total rate > gic0,p13:-ic_timer0 16052 164 > gic0,s0: uart2 318 3 > gic0,s6: iichb0 13034 133 > gic0,s60: aw_mmc0 1293 13 > gic0,s82: awg0 334 3 > gic0,s120: pmu0 49725 509 > cpu0:rendezvous 18 0 > cpu1:rendezvous 50 1 > cpu2:rendezvous 51 1 > cpu3:rendezvous 40 0 > cpu0:preempt 2691 28 > cpu1:preempt 3165 32 > cpu2:preempt 2778 28 > cpu3:preempt 2986 31 > cpu0:hardclock 15 0 > Total 92550 946 >=20 >=20 > the hardware is an NanoPi Neo > ---<>--- > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2020 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 12.1-STABLE #0 r362793M: Tue Jun 30 11:39:11 IDT 2020 > danny@nrnd:/home/obj/nrnd/arm/neo/vol/rnd/stable/12/arm.armv7/sys/AWGE= N arm > FreeBSD clang version 10.0.0 (git@github.com :llvm= /llvm-project.git llvmorg-10.0.0-0-gd32170dbd5b) > VT: init without driver. > No PSCI/SMCCC call function found > CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) > ? >=20 I do not have a IRQ-Storm on my NanoPI NEO2, but a "i2s -s" does never retu= rn. Commit v356609 broke i2c-support on my hardware (reverting this single = commit fixed it, bugreport filed: https://bugs.freebsd.org/bugzilla/show_bu= g.cgi?id=3D247576). Perhaps it is worth a try for you also to revert this commit and test again= ... BR Manuel From owner-freebsd-arm@freebsd.org Sat Jul 4 10:45:57 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4B174348FF7 for ; Sat, 4 Jul 2020 10:45:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49zT5J3Bzpz4V8F for ; Sat, 4 Jul 2020 10:45:56 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 6DCF1348FF6; Sat, 4 Jul 2020 10:45:56 +0000 (UTC) Delivered-To: arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6D8C73493D4 for ; Sat, 4 Jul 2020 10:45:56 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49zT5G2sFXz4VRj for ; Sat, 4 Jul 2020 10:45:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=LHgBe2VvajuahoV0sJX9YvHkfPvqdHYvmFfrW28Asno=; b=tnC3Haf51DrOxvVUc6TJKXdBBHnCaBT4EZ0GoQ9lMPHXKxwz5RL+9Qc4uHNCijXrzaQAHjlVsDAT8kmHVq+Jt3fN5SLcy9CJ4khuZfPP0/BhqL3LaLM9zOeGwzpO43lvbiGYYTUBxnxECUznrQI7019pEJurQzFX/Adb2lyQvVvdEONwZBtUAtCrmJs3n75vqeRcukP2p8a9OLmvBBowdPrR/DwvNqYcFCTHl5tv67wEt7ZVW41SXQ99aYh75VQYHRGzGen6bW03j1DiKC9xBGr0VFSqQLoGoN9c5KgGrLM0f0/q1h1crQSYa0hN2lbl6txHbIiM14LLf+z/NzAKNg==; Received: from macmini.bk.cs.huji.ac.il ([132.65.179.19]) by kabab.cs.huji.ac.il with esmtp id 1jrfg7-000NNn-Dt; Sat, 04 Jul 2020 13:45:51 +0300 From: Daniel Braniss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: allwinner/i2c interrupt storm detected Date: Sat, 4 Jul 2020 13:45:50 +0300 In-Reply-To: <20200704122944.64723bbb606d6e73128d2568@freenet.de> Cc: "freebsd-arm@freebsd.org" To: =?utf-8?Q?Manuel_St=C3=BChn?= References: <10ACCB56-E18D-4102-B4E2-094157854AB7@cs.huji.ac.il> <20200704122944.64723bbb606d6e73128d2568@freenet.de> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 49zT5G2sFXz4VRj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=tnC3Haf5; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-2.58 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.01)[-1.007]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[132.65.116.210:from]; NEURAL_HAM_SHORT(-0.28)[-0.282]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[freenet.de]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 10:45:57 -0000 > On 4 Jul 2020, at 13:29, Manuel St=C3=BChn = wrote: >=20 > On Tue, 30 Jun 2020 16:01:41 +0300 > Daniel Braniss > = wrote: >=20 >> Hi, >>=20 >> after a long time I decided to try and upgrade to stable 12.1 r362793 = since I saw some changes where done=20 >> with respect to the DTS and twsi.c,=20 >>=20 >> if nothing is connected to the i2c, i2c -s just hangs, >>=20 >> if something is connected this is what i get on the console after = typing ?i2c -s? >>=20 >>=20 >> Hardware may not support START/STOP scanning; trinterrupt storm = detected on "gic0,s6:"; throttling interrupt source >> ying less-reliable read method. >> interrupt storm detected on "gic0,s6:"; throttling interrupt source >> interrupt storm detected on "gic0,s6:"; throttling interrupt source >> ? >>=20 >> and >> neo-04> vmstat -i >> interrupt total = rate >> gic0,p13:-ic_timer0 16052 = 164 >> gic0,s0: uart2 318 = 3 >> gic0,s6: iichb0 13034 = 133 >> gic0,s60: aw_mmc0 1293 = 13 >> gic0,s82: awg0 334 = 3 >> gic0,s120: pmu0 49725 = 509 >> cpu0:rendezvous 18 = 0 >> cpu1:rendezvous 50 = 1 >> cpu2:rendezvous 51 = 1 >> cpu3:rendezvous 40 = 0 >> cpu0:preempt 2691 = 28 >> cpu1:preempt 3165 = 32 >> cpu2:preempt 2778 = 28 >> cpu3:preempt 2986 = 31 >> cpu0:hardclock 15 = 0 >> Total 92550 = 946 >>=20 >>=20 >> the hardware is an NanoPi Neo >> ---<>--- >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2020 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 12.1-STABLE #0 r362793M: Tue Jun 30 11:39:11 IDT 2020 >> = danny@nrnd:/home/obj/nrnd/arm/neo/vol/rnd/stable/12/arm.armv7/sys/AWGEN = arm >> FreeBSD clang version 10.0.0 (git@github.com = :llvm/llvm-project.git = llvmorg-10.0.0-0-gd32170dbd5b) >> VT: init without driver. >> No PSCI/SMCCC call function found >> CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) >> ? >>=20 >=20 > I do not have a IRQ-Storm on my NanoPI NEO2, but a "i2s -s" does never = return. Commit v356609 broke i2c-support on my hardware (reverting this = single commit fixed it, bugreport filed: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247576 = ). >=20 > Perhaps it is worth a try for you also to revert this commit and test = again... >=20 before the latest changes it works fine, and if you add my patch to it, = i2s -s will not hang: > -- twsi.c (revision 346538) > +++ twsi.c (working copy) > @@ -458,8 +458,15 @@ > if (sc->msg->len =3D=3D 1) > sc->control_val &=3D ~TWSI_CONTROL_ACK; > TWSI_WRITE(sc, sc->reg_control, sc->control_val | = TWSI_CONTROL_START); > - while (sc->error =3D=3D 0 && sc->transfer !=3D 0) { > - pause_sbt("twsi", SBT_1MS * 30, SBT_1MS, 0); > + { > + int count =3D 10; > + while (sc->error =3D=3D 0 && sc->transfer !=3D = 0) { > + pause_sbt("twsi", SBT_1MS * 30, = SBT_1MS, 0); > + if(count-- =3D=3D 0) { > + sc->error =3D EDEADLK; > + break; > + } > + } > } >=20 > debugf(dev, "Done with msg[%d]\n", i); cheers, danny >=20 > BR > Manuel From owner-freebsd-arm@freebsd.org Sat Jul 4 19:07:59 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 846853560A6 for ; Sat, 4 Jul 2020 19:07:59 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [95.85.46.90]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49zhDZ2drQz433q for ; Sat, 4 Jul 2020 19:07:58 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.192] (176-93-197-160.bb.dnainternet.fi [176.93.197.160]) (authenticated bits=0) by mail.kronometrix.org (8.15.2/8.15.2) with ESMTPSA id 064J7n76028865 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 4 Jul 2020 19:07:51 GMT (envelope-from sparvu@kronometrix.org) X-Authentication-Warning: mail.kronometrix.org: Host 176-93-197-160.bb.dnainternet.fi [176.93.197.160] claimed to be [192.168.1.192] From: Stefan Parvu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: RBPI3B/3B+ builtin WIFI support Message-Id: Date: Sat, 4 Jul 2020 22:07:44 +0300 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49zhDZ2drQz433q X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sparvu@kronometrix.org designates 95.85.46.90 as permitted sender) smtp.mailfrom=sparvu@kronometrix.org X-Spamd-Result: default: False [-1.59 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.95)[-0.948]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_SHORT(-0.01)[-0.013]; DMARC_NA(0.00)[kronometrix.org]; NEURAL_HAM_MEDIUM(-0.83)[-0.832]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:95.85.0.0/18, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 19:07:59 -0000 Hi, Is there any progress to have support for the built-in Wifi on RBPI3/3B+ = ?=20 We want to test our product based on FreeBSD for IoT. Preferable we dont = want to use any additional USB dongles. Thank you, Stefan=20=