From owner-freebsd-arm@freebsd.org Mon Oct 28 13:21:54 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 942D71A2A60 for ; Mon, 28 Oct 2019 13:21:54 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 471wNf05xhz3xCM; Mon, 28 Oct 2019 13:21:53 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id a5363971; Mon, 28 Oct 2019 14:21:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=ndg5CY8OQ/ElZ25ododdYmM43Ag=; b=q+P4mPBXW7pWfz/Yg/tdEHdQnNvS zDVdK/DaMvUs57PXkAlzUU2301Tt8XKaCdgNzL330nqCmgv8p0Vf4BN2qsO5H9Jq gfCvOxDYRtZGRlijqsTC/8NvaB9y73vdFpfNw18w4gDzhQBismKEuoGmY03Av7aI v85Ci54rJWalhbk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=BIpv9u7ItjEJ3APTJbR8OX4A6QmKQdgHTSgy1WcDIjoZ01JryhfzJ4WD TULT997QXmGJgg0vdfxoC5Kp9ID0xhc0RnspiJ0p4oYZKKL5ZfFj+AMH5khnn1+R 9DZQxyt0ShwUP+Q5J8zZLV58HdDFusliPu0XKGWOtanOuiyeyYU= Received: from sonic.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 1daaf2f5 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 28 Oct 2019 14:21:52 +0100 (CET) Date: Mon, 28 Oct 2019 14:21:52 +0100 From: Emmanuel Vadot To: mmel@freebsd.org Cc: Michal Meloun , Sleep Walker , freebsd-arm@freebsd.org Subject: Re: FreeBSD 13-CURRENT download status on RK3399 SBC`s Message-Id: <20191028142152.a3147e5b4f7ef2a84a2502df@bidouilliste.com> In-Reply-To: References: <20191028121027.8c89aef2a2809cd844ccad80@bidouilliste.com> <150c9db3-26f9-bd3b-eb16-c2801d6944f6@freebsd.org> <20191028132358.cd225b5127fb7396c11c4585@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 471wNf05xhz3xCM X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; TAGGED_RCPT(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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:21:54 -0000 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 from > >>> 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 the > >>> 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_sdmmc > >> (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 = NULL and xin24m > > 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 = 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=0x12 > ugen0.2: at usbus0 > umass1 on uhub0 > umass1: 2> on usbus0 > umass1: SCSI over Bulk-Only; quirks = 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 = 0 > (0xfffffd0003fe7260) locked @ /usr2/Meloun/git/pmap/sys/cam/cam_xpt.c:1039 > exclusive sleep mutex XPT topology lock (XPT topology lock) r = 0 > (0xffff000000d0dee8) locked @ /usr2/Meloun/git/pmap/sys/cam/cam_xpt.c:5367 > exclusive sleep mutex CAM device lock (CAM device lock) r = 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