dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5708
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Common firmware testing

Fri Mar 27, 2020 12:10 pm

DougieLawson wrote:
Fri Mar 27, 2020 11:52 am
I'm just relaying what Github tells me.
https://githhub.com/hexxeh/rpi-firmware wrote:This branch is 198 commits ahead, 766 commits behind master.
for your next branch. So it needs some synchronisation.
That doesn't mean anything (except that next branch has had 198 commits and master has had 766 commits since next was created).
Everything is up to date and synchronised.

mby
Posts: 45
Joined: Sat Dec 15, 2018 3:05 pm

Re: Common firmware testing

Fri Mar 27, 2020 2:37 pm

Interesting phenomenon here: since the last probably two commits, my Pi 4 (running the 64-bit kernel) randomly loses connection to the SSD drive containing /root and connected via USB3 with a Geekworm X856 Raspberry Pi 4 mSATA Shield; prior to the update, it ran rock solid, now it is probably just disconnected (blue LED off) and does not get back up again while the Pi 4 continues to run whatever is still accessible (no SSH but standard Apache error website; sadly nothing in syslog.

If hard pressed, I'd say it started around 22-Mar-2020 (I'm performing daily updates), but I'm probably wrong as it does not related to any kernel commit...

Reverting to 4.19.97 seems to eliminate the issue.

User avatar
DougieLawson
Posts: 40810
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Common firmware testing

Sat Mar 28, 2020 1:05 pm

DougieLawson wrote:
Fri Mar 27, 2020 11:24 am
dom wrote:
Fri Mar 27, 2020 11:12 am
There is an update to next branch which should fix wifi regressions.
Have you fixed the system clock regression in that version?
Are you going to merge in the missing 766 commits?
My 3B (not plus) with the official display is still showing the system clock regression

Code: Select all

root@tranquility:~ # sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"
Sat 28 Mar 13:03:26 GMT 2020
root@tranquility:~ # date
Sat 28 Mar 13:03:27 GMT 2020
root@tranquility:~ # ntpq -p -n
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
 162.159.200.1   10.21.8.251      3 u   7h   64    3    4.062  2595154 116125.
 81.21.76.27     202.70.69.81     2 u   7h   64    7    9.230  2595699 224917.
 109.74.206.120  140.203.204.77   2 u   7h   64    7    7.667  2596242 221498.
 195.171.43.10   .PPS.            1 u   7h   64    7    5.929  2595154 217923.
 162.159.200.123 10.21.8.251      3 u   7h   64    3    4.002  2595879 112493.
 178.79.145.244  232.6.188.111    2 u   7h   64    3    7.467  2596242 117887.
 138.68.183.179  217.114.59.3     3 u   7h   64    3    7.428  2596061 113211.
 185.111.204.220 10.0.0.241       2 u   7h   64    3    8.771  2596061 112529.
 35.158.196.249  192.53.103.108   2 u   7h   64    3    9.026  2595880 112494.
 2606:4700:f1::1 10.20.12.67      3 u    6   64    1   11.698  11916.8 2118998
 2604:a880:800:c 128.59.0.245     2 u   7h   64    3   76.545  2596243 116100.
 178.62.68.79    94.198.159.10    2 u   7h   64    3    7.204  2596786 114270.
 2a00:2381:19c6: .PPS.            1 u   7h   64    3   28.756  2596424 114287.
 2a01:7e00::f03c 206.189.118.143  3 u   7h   64    3   10.812  2596605 114335.
 130.159.196.118 193.62.22.90     2 u   7h   64    3    7.193  2597148 116154.
 139.162.219.252 194.35.252.7     2 u   7h   64    1    4.340  2597147 12894.4
 178.62.16.103   195.66.241.2     2 u    1   64    1    3.756  20965.2 1641140
root@tranquility:~ #
NTP won't sync.
Any language using left-hand whitespace for syntax is ridiculous

Any DMs sent on Twitter will be answered next month.
Fake doctors - are all on my foes list.

Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

fik
Posts: 41
Joined: Thu Jan 17, 2013 1:34 pm

Re: Common firmware testing

Mon Mar 30, 2020 8:18 pm

The wifi issue with Raspberry Pi 3B+ and 64bit kernel is still there. Periodically the wifi works for approx. 15 s and then does not work for 45 s and then works again. I get about 75% of lost packages from ping.

Edit: actually, it is not a wifi problem, but the Raspberry Pi 3B+ boots fine and then restarts itself within 15 seconds. Is it a watchdog problem? But it happens only with 64bit kernel. 32bit kernel is fine.

Edit 2: Well, it surprisingly is a watchdog problem! Disabling the line RuntimeWatchdogSec=10 in /etc/systemd/system.conf avoids the problem with restarts. So the hardware watchdog bcm2835-wdt does not get the periodical resets from systemd in 64bits kernel, while in 32bit it does. That's strange.

Also, I observed another small cosmetic difference. Using old firmware on a Raspberry Pi 3B+ vcgencmd measure_clock h264 gives 300, with the new firmware it gives 0. For Raspberry Pi 4 it was always 0.

Edit 3: The next firmware on RPi4 and 64bit kernel does not have problems with the watchdog. Not sure if the next firmware for RPi4 actually differs from the current RPi4 firmware. Just checking.

fik
Posts: 41
Joined: Thu Jan 17, 2013 1:34 pm

Re: Common firmware testing

Tue Mar 31, 2020 7:01 am

OK, I probably know, what is happening :idea:

First, I can confirm the finding of DougieLawson. My RPi 3B+ has also a problem syncing time with 64bit kernel. I don't use ntpd, I have the default Raspbian timekeeping by systemd, but it is not synced.

Code: Select all

$ timedatectl timesync-status 
       Server: 185.8.237.45 (0.debian.pool.ntp.org)
Poll interval: 32s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 3
    Reference: 5102F8BD
    Precision: 1us (-21)
Root distance: 48.400ms (max: 5s)
       Offset: +58.452836s
        Delay: 3.890ms
       Jitter: 49.400568s
 Packet count: 4
    Frequency: +0.000ppm


While normally it should look like this (from RPi 4 any kernel or RPi 3B+ with 32bit kernel)

Code: Select all

$ timedatectl timesync-status 
       Server: 37.187.104.44 (2.debian.pool.ntp.org)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 2
    Reference: C1CC72E9
    Precision: 1us (-22)
Root distance: 43.471ms (max: 5s)
       Offset: +30us
        Delay: 35.206ms
       Jitter: 949us
 Packet count: 19
    Frequency: -14.660ppm
Manually disabling the ntp sync I can estimate the clock drift:

Code: Select all

sudo timedatectl set-ntp false
sudo ntpdate 3.europe.pool.ntp.org
sleep 1000
sudo ntpdate 3.europe.pool.ntp.org
For the RPi3 1000 seconds there are real-world 1816 seconds! The time on RPi3 is almost two times slower! That is why ntp and systemd can't synchronize the clock.

I think this also causes the watchdog to restart my RPi3. For RuntimeWatchdogSec=10 systemd is feeding the watchdog every 5 seconds (half the value), but due to the clock being two times slower, it is sometimes not enough and hardware watchdog restarts the board.


I also observed the timing problem by looking at the kernel loop delay calibration (lpj):

Code: Select all

$dmesg | grep lpj

RPi3 B+ 32bit kernel:

Code: Select all

[    0.000326] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000)

RPi3 B+ 64bit kernel:

Code: Select all

[    0.000121] Calibrating delay loop (skipped), value calculated using timer frequency.. 108.00 BogoMIPS (lpj=216000)

RPi4 B 32bit kernel:

Code: Select all

[    0.000282] Calibrating delay loop (skipped), value calculated using timer frequency.. 108.00 BogoMIPS (lpj=540000)

RPi4 B 64bit kernel:

Code: Select all

[    0.000257] Calibrating delay loop (skipped), value calculated using timer frequency.. 108.00 BogoMIPS (lpj=216000)

Looks like the RPi 3B+ is with 64bit kernel somehow picking up the wrong timing values for RPi4?

User avatar
DougieLawson
Posts: 40810
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Common firmware testing

Tue Mar 31, 2020 7:30 am

The first time round I spotted it with my ADS-B receiver as the multilateration stops working when you don't have a good timebase.
All but one of my 64-bit raspberries are running the 64-bit kernel & 32-userland. It is the 64-bit machines that fail.

Everything works OK with BRANCH=master rpi-update, lots of them fail to keep time with BRANCH=next rpi-update (so there's some regression between the two branches). Since it's likely in the closed source firmware it looks like it'll be impossible for me to find the root cause.
Any language using left-hand whitespace for syntax is ridiculous

Any DMs sent on Twitter will be answered next month.
Fake doctors - are all on my foes list.

Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

fik
Posts: 41
Joined: Thu Jan 17, 2013 1:34 pm

Re: Common firmware testing

Tue Mar 31, 2020 8:06 am

Dougie, can you check the time speed of the RPi3? Just stop ntp and then measure somehow, how long does e.g. sleep 100 take. By hand or by ntpdate, like me. But I think, it is also about two times slower, as in the case of RPi3B+.

User avatar
DougieLawson
Posts: 40810
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Common firmware testing

Tue Mar 31, 2020 9:00 am

fik wrote:
Tue Mar 31, 2020 8:06 am
Dougie, can you check the time speed of the RPi3? Just stop ntp and then measure somehow, how long does e.g. sleep 100 take. By hand or by ntpdate, like me. But I think, it is also about two times slower, as in the case of RPi3B+.
I've reverted all the wonky Raspberries to BRANCH=master so it will take a while to run your experiment.
Any language using left-hand whitespace for syntax is ridiculous

Any DMs sent on Twitter will be answered next month.
Fake doctors - are all on my foes list.

Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5708
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Common firmware testing

Tue Mar 31, 2020 9:59 am

fik wrote:
Tue Mar 31, 2020 7:01 am
OK, I probably know, what is happening :idea:

For the RPi3 1000 seconds there are real-world 1816 seconds! The time on RPi3 is almost two times slower! That is why ntp and systemd can't synchronize the clock.
Thanks for this diagnosis. I spent a while thinking abut this. The arm's time base comes from the architectural timers which runs straight of the crystal osc so there are no firmware setting that could have got this wrong... But we convey the system clock frequency to the arm through the arm stubs (arm code that runs before kernel) that the firmware provides a default version of when not explicitly set with "armstub=".

And Pi3 had 19.2MHz osc, and Pi4 has 54MHz osc which I suspect is the ratio the Pi3 is running slower. Let me think about how to solve this.

User avatar
DougieLawson
Posts: 40810
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Common firmware testing

Tue Mar 31, 2020 11:58 am

I see some differences with the BogoMIPs noise from the kernel

Code: Select all

B+[    0.001342] Calibrating delay loop... 697.95 BogoMIPS (lpj=3489792)
3B[    0.000975] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=76800)
3A+[    0.000974] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=76800)
2B[    0.001139] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000)
3B[    0.010804] SMP: Total of 4 processors activated (153.60 BogoMIPS).
Zero[    0.001340] Calibrating delay loop... 697.95 BogoMIPS (lpj=3489792)
1B[    0.001328] Calibrating delay loop... 697.95 BogoMIPS (lpj=3489792)
3B[    0.000971] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=76800)
ZeroW[    0.001344] Calibrating delay loop... 697.95 BogoMIPS (lpj=3489792)
1B[    0.001330] Calibrating delay loop... 697.95 BogoMIPS (lpj=3489792)
1B[    0.001337] Calibrating delay loop... 697.95 BogoMIPS (lpj=3489792)
1B[    0.001345] Calibrating delay loop... 697.95 BogoMIPS (lpj=3489792)
3B[    0.000973] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=76800)
A+[    0.001350] Calibrating delay loop... 697.95 BogoMIPS (lpj=3489792)
This is with BRANCH=next

Code: Select all

3A+[    0.000344] Calibrating delay loop (skipped), value calculated using timer frequency.. 108.00 BogoMIPS (lpj=216000)
Any language using left-hand whitespace for syntax is ridiculous

Any DMs sent on Twitter will be answered next month.
Fake doctors - are all on my foes list.

Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

User avatar
DougieLawson
Posts: 40810
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Common firmware testing

Tue Mar 31, 2020 12:44 pm

I tried the test on a 3A+ running BRANCH=next and it doesn't complete.

Code: Select all

root@ulysses:~ # timedatectl  set-ntp false
root@ulysses:~ # ntpdate 3.uk.pool.ntp.org
31 Mar 13:02:30 ntpdate[4134]: step time server 178.79.145.244 offset 6850.555529 sec
root@ulysses:~ # ntpdate 3.uk.pool.ntp.org; sleep 1000; ntpdate 3.uk.pool.ntp.org
31 Mar 13:03:19 ntpdate[4240]: step time server 178.79.145.244 offset 33.117298 sec
First go was to test the ntpdate program (as I'd just installed it).
It's still sitting there now since 13:03.

Code: Select all

root@ulysses:/proc/4269 # cat sched
sleep (4269, #threads: 1)
-------------------------------------------------------------------
se.exec_start                                :        449099.872897
se.vruntime                                  :           533.168337
se.sum_exec_runtime                          :             1.973666
se.nr_migrations                             :                    1
nr_switches                                  :                    7
nr_voluntary_switches                        :                    3
nr_involuntary_switches                      :                    4
se.load.weight                               :              1048576
se.runnable_weight                           :              1048576
se.avg.load_sum                              :                44906
se.avg.runnable_load_sum                     :                44906
se.avg.util_sum                              :             23406731
se.avg.load_avg                              :                  983
se.avg.runnable_load_avg                     :                  983
se.avg.util_avg                              :                  500
se.avg.last_update_time                      :         449099872256
se.avg.util_est.ewma                         :                  291
se.avg.util_est.enqueued                     :                  501
policy                                       :                    0
prio                                         :                  120
clock-delta                                  :                   74
root@ulysses:/proc/4269 #
The system clock has moved on 15 minutes in 40 wall clock minutes.

Code: Select all

root@ulysses:/proc/4269 # kill -alrm 4269
root@ulysses:/proc/4269 # date
Tue 31 Mar 13:18:34 BST 2020
root@ulysses:/proc/4269 #
Any language using left-hand whitespace for syntax is ridiculous

Any DMs sent on Twitter will be answered next month.
Fake doctors - are all on my foes list.

Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

User avatar
dickon
Posts: 1886
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Common firmware testing

Tue Mar 31, 2020 1:00 pm

Code: Select all

newdesktop:/tmp/ (1) 351 $ bc -l
bc 1.07.1
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
15/40
.37500000000000000000
19.2/54
.35555555555555555555
newdesktop:/tmp/ (1) 352 $ 
Bingo...
As it is apparently board policy to disallow any criticism of anything, as it appears to criticise something is to criticise all the users of that something, I will no longer be commenting in threads which are not directly relevant to my uses of the Pi.

fik
Posts: 41
Joined: Thu Jan 17, 2013 1:34 pm

Re: Common firmware testing

Tue Mar 31, 2020 2:12 pm

DougieLawson wrote: I see some differences with the BogoMIPs noise from the kernel
yes, I got the same
DougieLawson wrote: I tried the test on a 3A+ running BRANCH=next and it doesn't complete.

Code: Select all

root@ulysses:~ # timedatectl  set-ntp false
root@ulysses:~ # ntpdate 3.uk.pool.ntp.org
31 Mar 13:02:30 ntpdate[4134]: step time server 178.79.145.244 offset 6850.555529 sec
root@ulysses:~ # ntpdate 3.uk.pool.ntp.org; sleep 1000; ntpdate 3.uk.pool.ntp.org
31 Mar 13:03:19 ntpdate[4240]: step time server 178.79.145.244 offset 33.117298 sec
First go was to test the ntpdate program (as I'd just installed it).
It's still sitting there now since 13:03.
Note that the sleep 1000 takes almost 1900 seconds in reality, i.e. more than half an hour.
I thought you use directly ntpd for timekeeping, then you should stop ntpd.
The line timedatectl set-ntp false disables the default systemd time synchronization.

User avatar
DougieLawson
Posts: 40810
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Common firmware testing

Tue Mar 31, 2020 2:32 pm

I did stop ntp. Can't run ntpdate while ntpd is running.

The experiment started at 13:03 (based on the ntpdate results). I got bored and SIGALRM'd it at 13:40 (more than half an hour later by the wall clock) but the system clock said 13:18 (on a date command).

It's so very borken when a simple test like that doesn't complete.
Any language using left-hand whitespace for syntax is ridiculous

Any DMs sent on Twitter will be answered next month.
Fake doctors - are all on my foes list.

Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5708
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Common firmware testing

Wed Apr 01, 2020 4:00 pm

An update has been pushed to next branch to correct the arm timer rate with 64-bit kernel.

fik
Posts: 41
Joined: Thu Jan 17, 2013 1:34 pm

Re: Common firmware testing

Wed Apr 01, 2020 10:13 pm

The timer issue is corrected for my RPi 3B+ and 64bit kernel, good job!

lpj looks fine:

Code: Select all

[    0.000340] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=76800)
No more problem with the watchdog, no more problem with time sync.

User avatar
DougieLawson
Posts: 40810
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Common firmware testing

Thu Apr 02, 2020 7:55 pm

fik wrote:
Wed Apr 01, 2020 10:13 pm
The timer issue is corrected for my RPi 3B+ and 64bit kernel, good job!

lpj looks fine:

Code: Select all

[    0.000340] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=76800)
No more problem with the watchdog, no more problem with time sync.
All of mine running the common firmware have been stable all day today (got the last one running about 01:00 this morning). Thanks Dom for the code changes and thanks fik for doing better diagnostics than I did.
Any language using left-hand whitespace for syntax is ridiculous

Any DMs sent on Twitter will be answered next month.
Fake doctors - are all on my foes list.

Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

User avatar
Realizator
Posts: 68
Joined: Thu Jul 14, 2016 12:53 pm
Contact: Website Twitter

Re: Common firmware testing

Tue Apr 14, 2020 3:30 pm

Following this post from 6by9 on common firmware test with the CM3+ based system (StereoPi), I have one fact which can help.
After update to the common firmware, system is not booting with CM3+ Lite.
But it boots if I use CM3 Lite (not CM3+, non-plus). And I see a couple of warnings:
"cma: cma_alloc: alloc failed, req-size: 1753 pages, ret: -12"
"raspberrypi-clk raspberrypi-clk: Missing firmware mode"

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5708
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Common firmware testing

Wed Apr 15, 2020 11:10 am

Realizator wrote:
Tue Apr 14, 2020 3:30 pm
I have one fact which can help.
After update to the common firmware, system is not booting with CM3+ Lite.
But it boots if I use CM3 Lite (not CM3+, non-plus)"
Could you try latest update? I don't have CM3+ to hand, but based on your report I've pushed something that may be the fix.

User avatar
Realizator
Posts: 68
Joined: Thu Jul 14, 2016 12:53 pm
Contact: Website Twitter

Re: Common firmware testing

Wed Apr 15, 2020 12:05 pm

dom wrote:
Wed Apr 15, 2020 11:10 am
Could you try latest update? I don't have CM3+ to hand, but based on your report I've pushed something that may be the fix.
Just did it, and with the latest update I have:
1. System boots with both CM3 and CM3+ editions - i.e. issue is fixed.
2. Now I have only one warning while boot:

Code: Select all

cma: cma_alloc: alloc failed, req-size: 1753 pages, ret: -12
3. JFYI, my current firmware and kernel:

Code: Select all

pi@raspberrypi:~ $ vcgencmd version
Apr 15 2020 11:56:56 
Copyright (c) 2012 Broadcom
version 1103ec16df2571274600b377411499bf5aed6d0d (clean) (release) (start)
pi@raspberrypi:~ $ uname -r
5.4.29-v7+ 

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5708
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Common firmware testing

Wed Apr 15, 2020 1:21 pm

Can you post output of "dmesg | grep cma"

User avatar
Realizator
Posts: 68
Joined: Thu Jul 14, 2016 12:53 pm
Contact: Website Twitter

Re: Common firmware testing

Wed Apr 15, 2020 1:37 pm

dom wrote:
Wed Apr 15, 2020 1:21 pm
Can you post output of "dmesg | grep cma"

Code: Select all

pi@raspberrypi:~ $ dmesg | grep cma
[    0.000000] cma: Reserved 8 MiB at 0x37800000
[    0.000000] Memory: 887112K/917504K available (8192K kernel code, 673K rwdata, 2476K rodata, 1024K init, 824K bss, 22200K reserved, 8192K cma-reserved)
[    1.295169] cma: cma_alloc: alloc failed, req-size: 1753 pages, ret: -12
[    5.815120] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[    5.818371] bcm2835_vc_sm_cma_probe: Videocore shared memory driver

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5708
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Common firmware testing

Wed Apr 15, 2020 1:47 pm

I think that is fine. I believe we try allocating framebuffer from cma first and if it fails fall back to allocating from gpu memory.
You could add, say cma=16M to cmdline.txt and it would avoid the warning, but it should be safe without.

User avatar
Realizator
Posts: 68
Joined: Thu Jul 14, 2016 12:53 pm
Contact: Website Twitter

Re: Common firmware testing

Wed Apr 15, 2020 1:55 pm

dom wrote:
Wed Apr 15, 2020 1:47 pm
I think that is fine. I believe we try allocating framebuffer from cma first and if it fails fall back to allocating from gpu memory.
You could add, say cma=16M to cmdline.txt and it would avoid the warning, but it should be safe without.
Ok, got it. Thank you!

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 10544
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Common firmware testing

Wed Apr 15, 2020 5:21 pm

dom wrote:
Wed Apr 15, 2020 1:47 pm
I think that is fine. I believe we try allocating framebuffer from cma first and if it fails fall back to allocating from gpu memory.
You could add, say cma=16M to cmdline.txt and it would avoid the warning, but it should be safe without.
Hmm, that had been reverted on 4.19 branches.
Then again I've now found it's only a matter of adding __GFP_NOWARN into the flags passed to dma_alloc_coherent, so that's the better solution.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Return to “Advanced users”