Date: Mon, 28 Oct 2019 15:00:40 +0100 From: Michal Meloun <meloun.michal@gmail.com> To: Sleep Walker <s199p.wa1k9r@gmail.com>, Emmanuel Vadot <manu@bidouilliste.com>, freebsd-arm@freebsd.org Subject: Re: FreeBSD 13-CURRENT download status on RK3399 SBC`s Message-ID: <6a757be7-79ec-3b95-f3d4-373cdc519836@freebsd.org> In-Reply-To: <CAHa8N8-rsefXz_muz62KaKVqoWzFYW6-OB0ZAY_KgAtZ6Dag9Q@mail.gmail.com> References: <CAHa8N8_s5Q2kgoMBnOtN3-QnJNaKWX13yDVOdVOOkcR-_Wfkjg@mail.gmail.com> <20191028121027.8c89aef2a2809cd844ccad80@bidouilliste.com> <150c9db3-26f9-bd3b-eb16-c2801d6944f6@freebsd.org> <20191028132358.cd225b5127fb7396c11c4585@bidouilliste.com> <d30b3292-1d66-9922-b97a-802c1eaf739b@freebsd.org> <20191028142152.a3147e5b4f7ef2a84a2502df@bidouilliste.com> <CAHa8N8-rsefXz_muz62KaKVqoWzFYW6-OB0ZAY_KgAtZ6Dag9Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------472F11F4BA34F8B3CFD02AC3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 28.10.2019 14:27, Sleep Walker wrote: > 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. Only gross hack, nothing which can be committed. (added clock at index 4 is wrong (it should be 'upll'. But we don't have this branch defined at all, and rk_clk_composite don't likes sparse clock arrays...) Michal > пн, 28 окт. 2019 г. в 16:21, Emmanuel Vadot <manu@bidouilliste.com>: > >> On Mon, 28 Oct 2019 14:10:32 +0100 >> Michal Meloun <meloun.michal@gmail.com> wrote: >> >>> >>> >>> 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 >> >> 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 <manu@bidouilliste.com> >> > --------------472F11F4BA34F8B3CFD02AC3 Content-Type: text/plain; charset=UTF-8; name="temp.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="temp.diff" ZGlmZiAtLWdpdCBhL3N5cy9hcm02NC9yb2NrY2hpcC9jbGsvcmszMzk5X2NydS5jIGIvc3lz L2FybTY0L3JvY2tjaGlwL2Nsay9yazMzOTlfY3J1LmMKaW5kZXggMzE2ZWZlZGYzZTIuLmEx OWM4YThmYjllIDEwMDY0NAotLS0gYS9zeXMvYXJtNjQvcm9ja2NoaXAvY2xrL3JrMzM5OV9j cnUuYworKysgYi9zeXMvYXJtNjQvcm9ja2NoaXAvY2xrL3JrMzM5OV9jcnUuYwpAQCAtMTcz OSw3ICsxNzM5LDcgQEAgc3RhdGljIHN0cnVjdCBya19jbGtfY29tcG9zaXRlX2RlZiBoY2xr X3NkID0gewogCiAjZGVmaW5lCVNDTEtfU0RNTUMJCTc2CiAKLXN0YXRpYyBjb25zdCBjaGFy ICpzY2xrX3NkbW1jX3BhcmVudHNbXSA9IHsiY3BsbCIsICJncGxsIiwgIm5wbGwiLCAicHBs bCJ9Oworc3RhdGljIGNvbnN0IGNoYXIgKnNjbGtfc2RtbWNfcGFyZW50c1tdID0geyJjcGxs IiwgImdwbGwiLCAibnBsbCIsICJwcGxsIiwgInhpbjI0bSIsICJ4aW4yNG0ifTsKIAogc3Rh dGljIHN0cnVjdCBya19jbGtfY29tcG9zaXRlX2RlZiBzY2xrX3NkbW1jID0gewogCS5jbGtk ZWYgPSB7Cg== --------------472F11F4BA34F8B3CFD02AC3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6a757be7-79ec-3b95-f3d4-373cdc519836>