From nobody Mon Aug 14 15:07:41 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RPd76078Rz4qc41 for ; Mon, 14 Aug 2023 15:07:46 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RPd753pSmz3Qm1 for ; Mon, 14 Aug 2023 15:07:45 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1692025662; 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=gqV069R/LhKI0Pl9szovbsmljYvKNZulWhjdVeUQIuA=; b=Lll1cDCHvacJ3+tDk+baLwqpB3qt8suPcT+tJbvKDv/abths/uqAnRbIwM7PBIcwMXYt59 Ajc0IRLSkEsNqbAY7XfmRCrZxt6sd9Hu6g/HeEnbHOC5sSk7HbBuSR4HuhrGIAPGknLhwC 05kyrmElv8B5aPuYLxtmwm6Pncuyip0= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 7635cc31 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 14 Aug 2023 15:07:42 +0000 (UTC) Date: Mon, 14 Aug 2023 17:07:41 +0200 From: Emmanuel Vadot To: Mike Karels Cc: freebsd-arm Subject: Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B] Message-Id: <20230814170741.dab652fc3e9475620eae29ea@bidouilliste.com> In-Reply-To: <6877B734-A9F2-40FF-8176-6A0E5DC2BD2E@karels.net> References: <1C94FEAF-C616-498F-8562-2E99CF12417D@edc.ro> <4F7960AE-F607-4FEF-8A02-2013862A37E3@yahoo.com> <20230813191924.1b9b7927f0d98ce9937a571f@bidouilliste.com> <20230814070319.1d04005ae92b8c0bc0ccf025@bidouilliste.com> <20230814073025.c06a3d2fe2c766b179ab6d0c@bidouilliste.com> <6877B734-A9F2-40FF-8176-6A0E5DC2BD2E@karels.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4RPd753pSmz3Qm1 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] On Mon, 14 Aug 2023 09:51:27 -0500 Mike Karels wrote: > On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote: > > > On Mon, 14 Aug 2023 07:03:19 +0200 > > Emmanuel Vadot wrote: > > > >> On Sun, 13 Aug 2023 12:35:31 -0500 > >> Mike Karels wrote: > >> > >>> On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: > >>> > >>>> On Sun, 13 Aug 2023 11:25:25 -0500 > >>>> Mike Karels wrote: > >>>> > >>>>> On 13 Aug 2023, at 11:10, Mark Millard wrote: > >>>>> > >>>>>> On Aug 13, 2023, at 08:17, Warner Losh wrote: > >>>>>> > >>>>>>> Manu just updated Linux DTS in the tree. Maybe see if you revert that if the problem persists. > >>>>>> > >>>>>> git: 69f8cc60aa1e - main - ofw_firmware: Only match if there is no compatible > >>>>>> > >>>>>> is the fix that Manu has committed: > >>>>>> > >>>>>> QUOTE > >>>>>> ofw_firmware: Only match if there is no compatible > >>>>>> > >>>>>> If there is a compatible string it likely means that the firmware needs > >>>>>> a dedicated driver (like on RPI*). > >>>>>> > >>>>>> PR: 273087 > >>>>>> Tested-by: Mark Millard > >>>>>> Sponsored by: Beckhoff Automation GmbH & Co. KG > >>>>>> Fixes: fdfd3a90b6ce ("ofw: Add a ofw_firmware driver") > >>>>>> END QUOTE > >>>>> > >>>>> Just for completeness: that change fixes the bcm2835_cpufreq0/powerd > >>>>> problem and the gpioled0 problem, but not the clk_fixed2 problem > >>>>> (clk_fixed4 on rpi4). Installing an msdos boot partition from the > >>>>> 3 Aug image makes that problem disappear. > >>>>> > >>>>> Mike > >>>> > >>>> There is two fixed-clock in the DTB without clock-frequency property > >>>> and with a status set to "disabled", this isn't conforming to the > >>>> bindings > >>>> (https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/Bindings/clock/fixed-clock.yaml) > >>>> so we complain on this, this is normal. > >>> > >>> Would it be possible to detect the disabled status to prevent the errors > >>> (I'm guessing not) or to suppress the repeats? 150 lines of errors seems > >>> like a lot for an out-of-spec DTB entry, and makes it hard to ignore. > >>> > >>> Mike > >> > >> Detecting the disabled status makes no sense, a fixed clock cannot be > >> disable, it's always present and running. > >> But I think that if we check that clock-frenquency isn't present in > >> the probe function, print a message and bail we will not attempt to > >> attach the driver at each pass. > >> That's the only clean solution that I can see without making dirty > >> hacks for some non-conforming DTB. > > > > Something like this : > > https://people.freebsd.org/~manu/0001-clk-fixed-Bail-early-if-there-is-no-clock-frequency-.patch > > > > Please let me know if that works. > > Not exactly. This results in: > > clk_fixed4: clock-fixed have no clock-frequency > > but this appears 1562 times. btw, "have" should be "has". Then I don't know how to fix this properly. > I hadn't noticed them before, but there are a lock order reversal > and a malloc while holding a non-sleepable lock, associated with > the gpio fix: Are you sure that they are new ? > gpioled0: on ofwbus0 > lock order reversal: (sleepable after non-sleepable) > 1st 0xffff000000d0f6f8 LED mtx (LED mtx, sleep mutex) @ /usr/src/sys/dev/led/led.c:298 > 2nd 0xffffa00001857c10 Raspberry Pi firmware gpio (Raspberry Pi firmware gpio, sx) @ /usr/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.c:252 > lock order LED mtx -> Raspberry Pi firmware gpio attempted at: > #0 0xffff0000004d3984 at witness_checkorder+0xa98 > #1 0xffff00000046ecb4 at _sx_xlock+0x7c > #2 0xffff0000008b1700 at rpi_fw_gpio_pin_set+0xe0 > #3 0xffff0000001c7400 at led_create_state+0x158 > #4 0xffff0000001910d4 at gpioled_attach+0x290 > #5 0xffff00000049efa4 at device_attach+0x3f8 > #6 0xffff00000049eb14 at device_probe_and_attach+0x7c > #7 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > #8 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #9 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #10 0xffff00000049bd30 at bus_set_pass+0x4c > #11 0xffff0000003ea3bc at mi_startup+0x1fc > #12 0xffff0000000008ac at virtdone+0x70 > uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks held: > exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000d0f6f8) locked @ /usr/src/sys/dev/led/led.c:298 > stack backtrace: > #0 0xffff0000004d3dc8 at witness_debugger+0x5c > #1 0xffff0000004d4fcc at witness_warn+0x400 > #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 > #3 0xffff000000782c20 at uma_zalloc_arg+0x2c > #4 0xffff000000437abc at malloc+0x8c > #5 0xffff0000008a69b4 at bcm2835_firmware_property+0x44 > #6 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 > #7 0xffff0000001c7400 at led_create_state+0x158 > #8 0xffff0000001910d4 at gpioled_attach+0x290 > #9 0xffff00000049efa4 at device_attach+0x3f8 > #10 0xffff00000049eb14 at device_probe_and_attach+0x7c > #11 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > #12 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #13 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #14 0xffff00000049bd30 at bus_set_pass+0x4c > #15 0xffff0000003ea3bc at mi_startup+0x1fc > #16 0xffff0000000008ac at virtdone+0x70 > uma_zalloc_debug: zone "malloc-16" with the following non-sleepable locks held: > exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000d0f6f8) locked @ /usr/src/sys/dev/led/led.c:298 > stack backtrace: > #0 0xffff0000004d3dc8 at witness_debugger+0x5c > #1 0xffff0000004d4fcc at witness_warn+0x400 > #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 > #3 0xffff000000782c20 at uma_zalloc_arg+0x2c > #4 0xffff000000437abc at malloc+0x8c > #5 0xffff0000007ce15c at bounce_bus_dmamem_alloc+0x50 > #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc > #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 > #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 > #9 0xffff0000001c7400 at led_create_state+0x158 > #10 0xffff0000001910d4 at gpioled_attach+0x290 > #11 0xffff00000049efa4 at device_attach+0x3f8 > #12 0xffff00000049eb14 at device_probe_and_attach+0x7c > #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #16 0xffff00000049bd30 at bus_set_pass+0x4c > #17 0xffff0000003ea3bc at mi_startup+0x1fc > uma_zalloc_debug: zone "malloc-128" with the following non-sleepable locks held: > exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000d0f6f8) locked @ /usr/src/sys/dev/led/led.c:298 > stack backtrace: > #0 0xffff0000004d3dc8 at witness_debugger+0x5c > #1 0xffff0000004d4fcc at witness_warn+0x400 > #2 0xffff0000007830a0 at uma_zalloc_debug+0x30 > #3 0xffff000000782c20 at uma_zalloc_arg+0x2c > #4 0xffff000000437abc at malloc+0x8c > #5 0xffff0000007ce1ac at bounce_bus_dmamem_alloc+0xa0 > #6 0xffff0000008a9404 at bcm2835_mbox_property+0xdc > #7 0xffff0000008a69e8 at bcm2835_firmware_property+0x78 > #8 0xffff0000008b1718 at rpi_fw_gpio_pin_set+0xf8 > #9 0xffff0000001c7400 at led_create_state+0x158 > #10 0xffff0000001910d4 at gpioled_attach+0x290 > #11 0xffff00000049efa4 at device_attach+0x3f8 > #12 0xffff00000049eb14 at device_probe_and_attach+0x7c > #13 0xffff0000004a0e54 at bus_generic_new_pass+0xfc > #14 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #15 0xffff0000004a0e04 at bus_generic_new_pass+0xac > #16 0xffff00000049bd30 at bus_set_pass+0x4c > #17 0xffff0000003ea3bc at mi_startup+0x1fc > > Mike > -- Emmanuel Vadot