Date: Mon, 28 Oct 2019 14:10:32 +0100 From: Michal Meloun <meloun.michal@gmail.com> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: Michal Meloun <meloun.michal@gmail.com>, Sleep Walker <s199p.wa1k9r@gmail.com>, freebsd-arm@freebsd.org Subject: Re: FreeBSD 13-CURRENT download status on RK3399 SBC`s Message-ID: <d30b3292-1d66-9922-b97a-802c1eaf739b@freebsd.org> In-Reply-To: <20191028132358.cd225b5127fb7396c11c4585@bidouilliste.com> References: <CAHa8N8_s5Q2kgoMBnOtN3-QnJNaKWX13yDVOdVOOkcR-_Wfkjg@mail.gmail.com> <20191028121027.8c89aef2a2809cd844ccad80@bidouilliste.com> <150c9db3-26f9-bd3b-eb16-c2801d6944f6@freebsd.org> <20191028132358.cd225b5127fb7396c11c4585@bidouilliste.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28.10.2019 13:23, Emmanuel Vadot wrote: > On Mon, 28 Oct 2019 12:59:30 +0100 > Michal Meloun <meloun.michal@gmail.com> wrote: > >> >> >> On 28.10.2019 12:10, Emmanuel Vadot wrote: >>> On Mon, 28 Oct 2019 13:57:57 +0300 >>> Sleep Walker <s199p.wa1k9r@gmail.com> 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: <JetFlash Mass Storage Device> at usbus4 umass0 on uhub3 umass0: <JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 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: <JetFlash Transcend 4GB 1100> 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<NO_6_BYTE,NO_RC16> ugen0.2: <JetFlash Mass Storage Device> at usbus0 umass1 on uhub0 umass1: <JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d30b3292-1d66-9922-b97a-802c1eaf739b>