Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B]
- In reply to: Emmanuel Vadot : "Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B]"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 14 Aug 2023 15:44:05 UTC
On 14 Aug 2023, at 10:07, Emmanuel Vadot wrote: > On Mon, 14 Aug 2023 09:51:27 -0500 > Mike Karels <mike@karels.net> wrote: > >> On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote: >> >>> On Mon, 14 Aug 2023 07:03:19 +0200 >>> Emmanuel Vadot <manu@bidouilliste.com> wrote: >>> >>>> On Sun, 13 Aug 2023 12:35:31 -0500 >>>> Mike Karels <mike@karels.net> wrote: >>>> >>>>> On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote: >>>>> >>>>>> On Sun, 13 Aug 2023 11:25:25 -0500 >>>>>> Mike Karels <mike@karels.net> wrote: >>>>>> >>>>>>> On 13 Aug 2023, at 11:10, Mark Millard wrote: >>>>>>> >>>>>>>> On Aug 13, 2023, at 08:17, Warner Losh <imp@bsdimp.com> 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 <marklmi26-fbsd@yahoo.com> >>>>>>>> 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. Too bad. The new message is much more obvious, but that's a lot of spam. >> 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 ? They were not in ALPHA1, where gpioled0 did not configure. They happen once that problem was fixed, and before this patch. I don't remember if they happened in the 3 Aug snapshot; I can test that if it helps. I would have noticed if I was watching, but I don't always connect to the serial console or check dmesg.boot. Mike >> gpioled0: <GPIO LEDs> 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 <manu@bidouilliste.com> <manu@freebsd.org>