Re: ALPHA1 on Raspberry Pi 3B+ [added: and RPi4B]

Mike Karels <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
On 14 Aug 2023, at 10:07, Emmanuel Vadot wrote:

> On Mon, 14 Aug 2023 09:51:27 -0500
> Mike Karels <[email protected]> wrote:
>
>> On 14 Aug 2023, at 0:30, Emmanuel Vadot wrote:
>>
>>> On Mon, 14 Aug 2023 07:03:19 +0200
>>> Emmanuel Vadot <[email protected]> wrote:
>>>
>>>> On Sun, 13 Aug 2023 12:35:31 -0500
>>>> Mike Karels <[email protected]> wrote:
>>>>
>>>>> On 13 Aug 2023, at 12:19, Emmanuel Vadot wrote:
>>>>>
>>>>>> On Sun, 13 Aug 2023 11:25:25 -0500
>>>>>> Mike Karels <[email protected]> wrote:
>>>>>>
>>>>>>> On 13 Aug 2023, at 11:10, Mark Millard wrote:
>>>>>>>
>>>>>>>> On Aug 13, 2023, at 08:17, Warner Losh <[email protected]> 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 <[email protected]>
>>>>>>>>     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 <[email protected]> <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.