From owner-freebsd-arm@freebsd.org Mon Oct 28 13:28:13 2019 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 042C61A2E0B for ; Mon, 28 Oct 2019 13:28:13 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 471wWw26d8z3xYh; Mon, 28 Oct 2019 13:28:11 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: by mail-lj1-x244.google.com with SMTP id w8so6833744lji.13; Mon, 28 Oct 2019 06:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oOFiFlsSv+8ZL6awQ7UNJoRuF3JHPLU8WzH98DEqyao=; b=beEg1cusvumYN7FAO3AQTyMt960IKoK5wL4L+uucujqQqjIi/pko4gJxr/n/0cyTZJ EdxF8AZzfyWSMYZguGHcOsAAT5hQ+U5c7mEKe31Jx+Mrj0AW+4esT9lxq+meM3BPL+Al OppVXc+3I2agREe8Gj47U0HBnqRE+4+rkAreOcgCDI3K3ijZqNMwW3jlgfklYFZnW08a pkfgeVHw601JSWdiolnL9d7IuESy21FOygTpK8Yw0Ej8dUOS5fXWqxfnebKg4FCT+i2q zz0+cyE79g/Sjip1Q8XqqXUCYNkqoa3Kp9duZzZaaBPqiCJCqsqy6SxSnAyepqH0bLWq An3Q== 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:from:date :message-id:subject:to; bh=oOFiFlsSv+8ZL6awQ7UNJoRuF3JHPLU8WzH98DEqyao=; b=TzWv4JoWq2hi97aRZmZ4g2Io7yUebkkW0Ju6/X6cQA2SpGoNkVg1vjL0v7jc5Ki1d6 m+xMfTLsh2U2Py9e5VGO+sKhG94kJDceuKm7GcG5LuCTknjmoSw8+mVXzsnlCol/1OtC dBw7ckiNZeG2rWMkWYcrcUYnLqQOUgTqWsU6vpn3Ota+pVbRXhwUTTu+PBhjSfDCQL/v GLIYg57xpoULcO+iHEqeiTbyR61XyUgS2NqEmKAMyBMnU1iofI7ja/5kHyp39bueqTvD VYs8MgINsGzxOHWHVqktb1GeFoAOUrISMDgyJsbY+7SB3XgmkomMyp0uyN399AtV1bxa meOA== X-Gm-Message-State: APjAAAWp8GG4wCtTJ+iq8H3XeHCUTXcEzlI+igJ45sJvRS6D8GVQq6yu MYtycOHVyIC1dgYzQ5oWsD+mUNXiJfYfxR5Go7vkdD8phMY= X-Google-Smtp-Source: APXvYqzAevKmZ6NapxfvJLt9Rd2bmH6IBPZnFJweTcAMrUxCpK2n1sSfFf6/d80MjR15p0I4sDhBHL9BwLoPy2i/oIA= X-Received: by 2002:a2e:5b82:: with SMTP id m2mr12121448lje.184.1572269289450; Mon, 28 Oct 2019 06:28:09 -0700 (PDT) MIME-Version: 1.0 References: <20191028121027.8c89aef2a2809cd844ccad80@bidouilliste.com> <150c9db3-26f9-bd3b-eb16-c2801d6944f6@freebsd.org> <20191028132358.cd225b5127fb7396c11c4585@bidouilliste.com> <20191028142152.a3147e5b4f7ef2a84a2502df@bidouilliste.com> In-Reply-To: <20191028142152.a3147e5b4f7ef2a84a2502df@bidouilliste.com> From: Sleep Walker Date: Mon, 28 Oct 2019 16:27:58 +0300 Message-ID: Subject: Re: FreeBSD 13-CURRENT download status on RK3399 SBC`s To: Emmanuel Vadot , "mmel@freebsd.org" , freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 471wWw26d8z3xYh X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=beEg1cus; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of s199pwa1k9r@gmail.com designates 2a00:1450:4864:20::244 as permitted sender) smtp.mailfrom=s199pwa1k9r@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (2.90), ipnet: 2a00:1450::/32(-2.80), asn: 15169(-2.05), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 13:28:13 -0000 Will there be any recommendations on how to avoid a mistake clknode_init_parent_idx: Invalid parent index 5 for clock sclk_sdmmc You will offer some patches. I am ready to try them. =D0=BF=D0=BD, 28 =D0=BE=D0=BA=D1=82. 2019 =D0=B3. =D0=B2 16:21, Emmanuel Va= dot : > On Mon, 28 Oct 2019 14:10:32 +0100 > Michal Meloun wrote: > > > > > > > On 28.10.2019 13:23, Emmanuel Vadot wrote: > > > On Mon, 28 Oct 2019 12:59:30 +0100 > > > Michal Meloun wrote: > > > > > >> > > >> > > >> On 28.10.2019 12:10, Emmanuel Vadot wrote: > > >>> On Mon, 28 Oct 2019 13:57:57 +0300 > > >>> Sleep Walker wrote: > > >>> > > >>>> Hi All! > > >>>> > > >>>> On Khadas-EDGE-V > > >>>> > > >>>> - mainline uboot U-Boot TPL 2019.10-rc3 > > >>>> - bootup from SD > > >>>> - eth OK > > >>>> - uart OK > > >>>> - emmc OK > > >>>> - sd OK > > >>>> - USB 2.0 OK > > >>>> - USB 3.0 OK > > >>>> - USB HID OK > > >>>> - USB DISK OK > > >>> > > >>> Good to know that everything is working on this board too. > > >>> > > >>>> > > >>>> On Rock Pi4 > > >>>> > > >>>> UEFI booting, very cool. > > >>>> > > >>>> But I can not log into the console. > > >>>> > > >>>> it seems it keeps rebooting. > > >>>> > > >>>> Here is the log: > > >>>> https://pastebin.com/JFX7Ssnz > > >>> > > >>> This is known. Let me try to describe the problem. > > >>> So the sd and panic: clknode_init_parent_idx: Invalid parent index > 5 for clock sclk_sdmmc have multiple possible parent, one of them is > > >>> the usb clock that is generated by the usb controller. The problem = is > > >>> that when we create the clock domain of the CRU (Clock and Reset > > >>> Unit) the usb controller isn't probed yet because it needs clock fr= om > > >>> the CRU. When a clock domain is finished (by calling clkdom_finit) = we > > >>> need all the clocks to be present so we cannot add the unknown for > now > > >>> usb clock. > > >>> So to fix this issue we need a way to create a fake clock when the > CRU > > >>> clock domain is created that will be later replaced by the usb > > >>> controller. There is multiple approch to this and I'm not yet sure > > >>> which one will work best. > > >>> > > >>> 1) We allow to list non-existing clock as parent and don't throw > > >>> errors anymore at clkdom_finit but at some SYSINIT. > > >>> This will work well with a big static kernel but not if the clock = is > > >>> created by a kernel module. > > >>> 2) We create some fake clock domain where we can add clocks to it = so > > >>> it became a somewhat valid parent (but not usable so you cannot > select > > >>> it with clknode_set_parent for example) and when a clock domain is > > >>> finished we remove clock from the fake domain that are present in t= he > > >>> newly created one (as clock names are unique this should not cause > > >>> problem). The question is then what should we do when we still have > > >>> clock in the fake domain ? > > >>> > > >>> Maybe mmel@ have more ideas. > > >>> > > >> All above is right but is not related to this panic > > >> "panic: clknode_init_parent_idx: Invalid parent index 5 for clock > > >> sclk_sdmmc". In this case, the parent clock at index 5 for sclk_sdmm= c > > >> (named "clk_sdmmc in TRM) is CLK_24M (at least in my TRM). > > > > > > Mhm right, it's the clock parent id 4 ("upll" in the TRM) the one I > > > was talking about. So I guess that puttin parent 4 =3D NULL and xin24= m > > > for parent 5 should work. > > > > > >> Problem (for me) is that rockchip clock code is slightly incomplete > and it uses > > >> different nomenclature (naming) that is in TRM. > > >> Unfortunately, putting > > >> right clock for this index doesn't helps much, my RockPRo64 still > fails > > >> with another (not yet identified)problem. > > > > > > What are the symptoms ? > > > > > > > See attached log. It occurs on every second hard reboot (by pressing > > reset button) reboot, only if both clusters are enabled. And, please, > > don't ask me why :) > > Michal > > > > ---------------------------------------------------------------------- > > ... > > WARNING: WITNESS option enabled, expect reduced performance. > > uhub2: 1 port with 1 removable, self powered > > uhub4: 1 port with 1 removable, self powered > > uhub3: 2 ports with 2 removable, self powered > > Root mount waiting for: usbus4 usbus2 usbus0 > > uhub0: 1 port with 1 removable, self powered > > uhub1: 1 port with 1 removable, self powered > > Root mount waiting for: usbus4 usbus0 > > ugen4.2: at usbus4 > > umass0 on uhub3 > > umass0: > 1> on usbus4 > > umass0: SCSI over Bulk-Only; quirks =3D 0x8100 > > umass0:0:0: Attached to scbus0 > > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > > da0: Removable Direct Access SPC-2 SCSI > device > > da0: Serial Number 02UIG9DQD7J9880G > > da0: 40.000MB/s transfers > > da0: 3764MB (7708672 512 byte sectors) > > da0: quirks=3D0x12 > > ugen0.2: at usbus0 > > umass1 on uhub0 > > umass1: > 2> on usbus0 > > umass1: SCSI over Bulk-Only; quirks =3D 0x8100 > > umass1:1:1: Attached to scbus1 > > Kernel page fault with the following non-sleepable locks held: > > exclusive sleep mutex CAM bus lock (CAM bus lock) r =3D 0 > > (0xfffffd0003fe7260) locked @ > /usr2/Meloun/git/pmap/sys/cam/cam_xpt.c:1039 > > exclusive sleep mutex XPT topology lock (XPT topology lock) r =3D 0 > > (0xffff000000d0dee8) locked @ > /usr2/Meloun/git/pmap/sys/cam/cam_xpt.c:5367 > > exclusive sleep mutex CAM device lock (CAM device lock) r =3D 0 > > (0xfffffd000e02d4d0) locked @ > /usr2/Meloun/git/pmap/sys/cam/cam_xpt.c:5494 > > stack backtrace: > > #0 0xffff0000005b3ae0 at witness_checkorder+0xd04 > > #1 0xffff0000005b4afc at witness_warn+0x3f8 > > #2 0xffff000000899c6c at do_el1h_sync+0x318 > > #3 0xffff000000899a78 at do_el1h_sync+0x124 > > #4 0xffff000000880874 at handle_el1h_sync+0x74 > > #5 0xffff0000000161f0 at xpt_remove_periph+0x38 > > #6 0xffff000000012674 at cam_periph_release_locked_buses+0x158 > > #7 0xffff00000001284c at cam_periph_release_locked+0x1c > > #8 0xffff00000002de74 at nvme_get_identify_ns+0x6d18 > > #9 0xffff00000001b474 at xpt_done_direct+0x3b4 > > #10 0xffff00000001d26c at xpt_register_async+0x13fc > > #11 0xffff00000050b040 at fork_exit+0x7c > > x0: fffffd0003fe7260 > > Ah yes this is known too, I only use the small cluster. I've presume a > mutex problem between the clusters but I'm not sure. Not that this only > shows up if you use a usb disk (well anything CAM I guess). > > -- > Emmanuel Vadot >