Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Bootable 64-bit RPi3 Gentoo image (OpenRC/Xfce/VC4) UPDATED
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... , 18, 19, 20  Next  
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Gentoo on ARM
View previous topic :: View next topic  
Author Message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 324

PostPosted: Tue Mar 12, 2019 6:10 pm    Post subject: Reply with quote

salfter wrote:
I'm trying to block the 4.19.* kernel from installing since it has some USB problems described elsewhere. I have this in /etc/portage/package.mask/bcmrpi3-kernel-bis-bin:

Code:
=sys-kernel/bcmrpi3-kernel-bis-bin-4.19.25.20190226


I tried this first:

Code:
>=sys-kernel/bcmrpi3-kernel-bis-bin-4.19


Both of these are ignored when I emerge @world; it keeps wanting to pull in the newer kernel instead of leaving the 4.14.* kernel alone. This is blocking an update of other packages (though I suppose I could get the list of ebuilds to be updated, filter out the kernel update, and do the rest).


It shouldn't be blocking now: I have reduced the minimum kernel version in the metapackage (here) to 4.14.

Try running:
Code:
demouser@pi64 ~ $ sudo emaint sync --repo rpi3

to pick this up, and then hopefully your kernel mask will apply, and you can update @world to downgrade to 4.14.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
salfter
n00b
n00b


Joined: 02 Jan 2003
Posts: 63

PostPosted: Tue Mar 12, 2019 7:37 pm    Post subject: Reply with quote

Sakaki wrote:
It shouldn't be blocking now: I have reduced the minimum kernel version in the metapackage (here) to 4.14.

Try running:
Code:
demouser@pi64 ~ $ sudo emaint sync --repo rpi3

to pick this up, and then hopefully your kernel mask will apply, and you can update @world to downgrade to 4.14.


I had already synced that version of the ebuild through. It's still trying to upgrade the kernel. After getting a list of packages to upgrade and filtering out sys-kernel/bcmrpi3-kernel-bis-bin, sys-boot/rpi3-64bit-firmware, and dev-embedded/rpi3-64bit-meta (all of which upgrades are masked), it looks like I can update the remaining packages.
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 324

PostPosted: Tue Mar 12, 2019 7:52 pm    Post subject: Reply with quote

Hmm, that's strange. What do you get if you run:
Code:
demouser@pi64 ~ $ equery d sys-kernel/bcmrpi3-kernel-bis-bin

_________________
Regards,

sakaki
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 324

PostPosted: Wed Mar 13, 2019 1:30 pm    Post subject: Reply with quote

For those who prefer a NOOBS-style installer, the v1.4.1 gentoo-on-rpi3-64bit images are now also available for install through PINN (called gentoo64 (=regular) and gentoo64pt (=pi-top) there).

Best, sakaki

PS: Many thanks to procount for helping me set up my own PINN repository (https://isshoni.org/pinn/os), and kindly linking it into the official set!
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
salfter
n00b
n00b


Joined: 02 Jan 2003
Posts: 63

PostPosted: Wed Mar 13, 2019 10:40 pm    Post subject: Reply with quote

Sakaki wrote:
Hmm, that's strange. What do you get if you run:
Code:
demouser@pi64 ~ $ equery d sys-kernel/bcmrpi3-kernel-bis-bin


Code:
 * These packages depend on sys-kernel/bcmrpi3-kernel-bis-bin:
dev-embedded/rpi3-64bit-meta-1.3.2 (boot-fw ? >=sys-kernel/bcmrpi3-kernel-bis-bin-4.14.44.20180601[with-matching-boot-fw(-),pitop(-)?])
                                   (!boot-fw ? >=sys-kernel/bcmrpi3-kernel-bis-bin-4.14.44.20180601[-with-matching-boot-fw(-)])
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 324

PostPosted: Thu Mar 14, 2019 9:30 am    Post subject: Reply with quote

If that's the only dep you have, it should update OK. Try pulling the repo again:
Code:
demouser@pi64 ~ $ sudo emaint sync --repo rpi3

then does
Code:
demouser@pi64 ~ $ emerge -avu rpi3-64bit-meta

work? If not, what does it output as the blocker?
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
salfter
n00b
n00b


Joined: 02 Jan 2003
Posts: 63

PostPosted: Thu Mar 14, 2019 8:38 pm    Post subject: Reply with quote

Sakaki wrote:
If that's the only dep you have, it should update OK. Try pulling the repo again:
Code:
demouser@pi64 ~ $ sudo emaint sync --repo rpi3

then does
Code:
demouser@pi64 ~ $ emerge -avu rpi3-64bit-meta

work? If not, what does it output as the blocker?


Code:

Local copy of remote index is up-to-date and will be used.
This action requires superuser access...
Would you like to add --pretend to options? [Yes/No] y

These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 KiB


I believe that's the desired behavior...trying
Code:
sudo emerge -auNDv --keep-going=y @world
now:

Code:

Local copy of remote index is up-to-date and will be used.

These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 KiB

!!! The following update has been skipped due to unsatisfied dependencies:

sys-kernel/bcmrpi3-kernel-bis-bin:0

  selected: (sys-kernel/bcmrpi3-kernel-bis-bin-4.14.90.20181222:0/0::rpi3, installed)
  skipped: (sys-kernel/bcmrpi3-kernel-bis-bin-4.19.25.20190226:0/0::rpi3, ebuild scheduled for merge) (see unsatisfied dependency below)

!!! All ebuilds that could satisfy "~sys-boot/rpi3-64bit-firmware-1.20190215[pitop(-)?,-dtbo(+)]" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-boot/rpi3-64bit-firmware-1.20190215::rpi3 (masked by: package.mask)

(dependency required by "sys-kernel/bcmrpi3-kernel-bis-bin-4.19.25.20190226::rpi3" [ebuild])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.



Nothing to merge; quitting.


I didn't get that the first time around, though...I think having --autounmask-write in EMERGE_DEFAULT_OPTS was the source of the problem. Adding --autounmask-keep-masks to EMERGE_DEFAULT_OPTS should keep masked packages masked while still allowing keyword and USE flag changes, which is why I usually have --autounmask-write on my Gentoo boxen.
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 324

PostPosted: Thu Mar 14, 2019 9:21 pm    Post subject: Reply with quote

Looks like something you have in /etc/package.mask/... locally is blocking sys-boot/rpi3-64bit-firmware-1.20190215: there's no rpi3-overlay mask affecting that package other than this one:
Code:
# mask erroneously tagged version
=sys-boot/rpi3-64bit-firmware-1.20180417

which obviously doesn't apply in this case.

Do you have any applicable entries in /etc/package.mask/... ?
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
salfter
n00b
n00b


Joined: 02 Jan 2003
Posts: 63

PostPosted: Thu Mar 14, 2019 10:08 pm    Post subject: Reply with quote

/etc/portage/package.mask/ has the following:

Code:
::::::::::::::
/etc/portage/package.mask/avrdude
::::::::::::::
=dev-embedded/avrdude-9999

::::::::::::::
/etc/portage/package.mask/bcmrpi3-kernel-bis-bin
::::::::::::::
>=sys-kernel/bcmrpi3-kernel-bis-bin-4.19.25.20190226

::::::::::::::
/etc/portage/package.mask/mjpg-streamer
::::::::::::::
=media-video/mjpg-streamer-9999

::::::::::::::
/etc/portage/package.mask/rpi3-64bit-firmware
::::::::::::::
>=sys-boot/rpi3-64bit-firmware-1.20190215

::::::::::::::
/etc/portage/package.mask/rpi3-64bit-meta
::::::::::::::
>=dev-embedded/rpi3-64bit-meta-1.4

::::::::::::::
/etc/portage/package.mask/slic3r
::::::::::::::
=media-gfx/slic3r-9999


bcmrpi3-kernel-bis-bin, rpi3-64bit-firmware, and rpi3-64bit-meta would be the files of interest here.
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 324

PostPosted: Thu Mar 14, 2019 10:17 pm    Post subject: Reply with quote

So if you remove the files (or move them to another holding directory somewhere):
/etc/portage/package.mask/bcmrpi3-kernel-bis-bin
/etc/portage/package.mask/rpi3-64bit-firmware
/etc/portage/package.mask/rpi3-64bit-meta

can you then update @world?
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
salfter
n00b
n00b


Joined: 02 Jan 2003
Posts: 63

PostPosted: Thu Mar 14, 2019 10:25 pm    Post subject: Reply with quote

Sakaki wrote:
So if you remove the files (or move them to another holding directory somewhere):
/etc/portage/package.mask/bcmrpi3-kernel-bis-bin
/etc/portage/package.mask/rpi3-64bit-firmware
/etc/portage/package.mask/rpi3-64bit-meta

can you then update @world?


The intent with those files is to keep the kernel from being updated to 4.19 until its USB issues are sorted. Removing them would cause the kernel to update to 4.19, which I don't want to have happen.

Everything else is up-to-date AFAIK, so emerge @world shouldn't pull in anything new until other packages are updated.
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 324

PostPosted: Thu Mar 14, 2019 10:33 pm    Post subject: Reply with quote

OK I understand I think.

The problem is that you need to remove the file:
/etc/portage/package.mask/rpi3-64bit-meta

and (if you wish) also:
/etc/portage/package.mask/rpi3-64bit-firmware

Just leave the file:
/etc/portage/package.mask/bcmrpi3-kernel-bis-bin

That should be sufficient.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
roylongbottom
n00b
n00b


Joined: 13 Feb 2017
Posts: 53
Location: Essex, UK

PostPosted: Fri Mar 29, 2019 12:56 pm    Post subject: 64 Bit High Performance Linpack Benchmark Reply with quote

64 Bit High Performance Linpack Benchmark

Has anyone produced a precompiled version of the HPL benchmark to run on a Raspberry Pi 3, or detailed procedures to load the appropriate packages to compile and install one?

Some time ago, the original precompiled HPL benchmark was shown to produce the wrong numeric results or system crashes on the Pi 3B. I have recently been running two versions of the 32 bit HPL benchmarks on Raspberry Pi 3B and 3B+, via Raspbian Jessie and Stretch. The versions were an old precompiled one and another that I generated that uses ATLAS, with alternative Basic Linear Algebra Subprograms. The latter took 14 hours to build from scratch, including hundreds of MFLOPS speed tuning calculations. Although a later compiler was used, performance was slower than the original.

The benchmarks were run using a range of data sizes and options to utilise 1, 2 or 4 cores. Most tests encountered errors, using the old Pi 3B, but only during the 4 core tests, and not necessarily at high temperatures. No failures were encountered during the Pi 3B+ tests but there was an initial performance hit, using Raspbian Stretch, where the default temperature for reducing CPU clock speed, from 1400 to 1200 MHz, had been reduced from 70°C to 60°C. Note that both systems were in FLIRC cases, with efficient cooling via the built in heatsinks.

I than ran my floating point stress tests, four copies at the same time, homing in one that produced similar failures as HPL, with each using 160 KB data size, to overfill the shared L2 cache.

See 32 bit summary results in:

https://www.raspberrypi.org/forums/viewtopic.php?f=31&t=44080&p=1448724#p1448724

and full details at ResearchGate in:

https://www.researchgate.net/publication/331983549_Raspberry_Pi_3B_and_3B_High_Performance_Linpack_and_Error_Tests

64 Bit Stress Tests


I also ran my 64 bit stress tests via Gentoo. Following is a summary of a series of tests on the older Pi 3B, where failures occurred on the third run, with performance and temperatures increasing (due to improved L2 cache hits?). The running time varied using the different logical core, when, on the final passes, two or three cores were in use, and produced higher total MFLOPS. The fourth run crashed. On rebooting there were no errors, but temperatures might not have reached the breaking point.

Code:

                              Single Core Average 3688 MFLOPS 

           Test 1                  Test 2                  Test 3
                         Total                   Total                           Total
 Seconds   MHz      °C  MFLOPS     MHz      °C  MFLOPS     MHz   Volts      °C  MFLOPS Errors

     0    1200    44.0            1200    47.2            1200  1.2625    46.2
   240    1200    63.4    3506    1200    67.1    5151    1200  1.2625    68.2    6716     0
   480    1200    66.6    3489    1200    70.4    5145    1200  1.2625    72.0    6698     0
   720    1200    69.8    3962    1200    72.0    5149    1200  1.2625    74.1    6709     6
   960    1200    66.1   >7391    1200    72.5   >7367    1200  1.2625    74.1   >7630     5

             Test 4                                  Test 5 Power Off/On
                                   Total                                   Total
  Seconds    MHz   Volts      °C  MFLOPS  Errors     MHz   Volts      °C  MFLOPS  Errors

       0    1200  1.2625    56.9                    1200  1.2688    47.2
     240    1200  1.2625    74.1    6248     2      1200  1.2688    68.2    4680     0
     480    1200  1.2625    76.3    6246     8      1200  1.2688    71.4    4679     0
     720    1200  1.2625   CRASH             3      1200  1.2688    73.6    4342     0
     960    1200                                    1200  1.2688    69.3   >7200     0


The next table provides details of Pi 3B+ test results, when there were no errors or crashes. MFLOPS measurements confirm faster speeds using fewer cores and variation on subsequent runs (one reducing). Temperatures were also lower ad CPU MHz constant. An increase in voltage was indicted at 60°C and after rebooting, also on the 3B after power off/on, but is it of any significance?

Code:
                                          1 Core   2 Cores   3 Cores
                        Average MFLOPS      4316      8273      7462

         Test 1                       Test 2                       Test 3
                             Total                        Total                        Total
 Seconds  MHz   Volts   °C  MFLOPS     MHz   Volts   °C  MFLOPS     MHz   Volts   °C  MFLOPS

    0    1400  1.3375  39.2           1400  1.3375  47.8           1400  1.3375  50.5
  240    1400  1.3375  52.1   5980    1400  1.3375  58.0   4298    1400  1.3438  61.2   5570
  480    1400  1.3375  54.8   5980    1400  1.3438  60.1   4290    1400  1.3438  62.8   5595
  720    1400  1.3375  58.5   5994    1400  1.3438  61.8   4788    1400  1.3438  63.9   5522
  960    1400  1.3438  60.1  >7400    1400  1.3438  60.1  >8770    1400  1.3438  65.0   5545

         Test 4                       Test 5  Reboot               Test 6  Power Off/On

    0    1400  1.3375  54.8           1400  1.3500  47.2           1400  1.3500  46.2
  240    1400  1.3438  63.4   4477    1400  1.3500  58.5   5817    1400  1.3500  59.6   6327
  480    1400  1.3438  64.5   4441    1400  1.3563  61.2   5805    1400  1.3563  61.8   6341
  720    1400  1.3438  64.5   4505    1400  1.3563  64.5   6500    1400  1.3563  64.5   7183
  960    1400  1.3438  63.4  >5720    1400  1.3563  65.0  >9500    1400  1.3563  62.3 >10000


_________________
Regards

Roy
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 324

PostPosted: Sat Mar 30, 2019 7:39 pm    Post subject: Reply with quote

roylongbottom,

very interesting results, as always. In the raspberrypi.org posting you linked, you state (wrt a 32-bit system):
roylongbottom wrote:
In view of the Pi 3B failures, I decided to see if I could reproduce similar problems running my floating point stress test program, using four copies to saturate all CPU cores. Experiments showed that I could produce data comparison failures and system crashes, when each program was allocated 160 KB memory, to overfill shared L2 cache. No failures occurred during Pi 3B+ tests but, to start with, performance was degraded due to the slower CPU MHz at 60°C.

So do I read you right, you can reproducibly create non-deterministic output (for a supposedly deterministic program) under certain (relatively high-load) conditions on the RPi3B (in 32-bit mode), where the temperature is high but below the default critical threshold?

Isn't that quite a serious issue? Have the RPF engineers come back to you with any comments?
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
brikko
n00b
n00b


Joined: 30 Mar 2019
Posts: 2

PostPosted: Sat Mar 30, 2019 11:25 pm    Post subject: Very poor hw video decoding Reply with quote

Hello everyone.

I just tried the latest image and unfortunately I'm everything but impressed with the hw video decoding.

The same file plays perfectly in LibreElEC and is completely unwatchable here, both with VLC and ffplay -vcodec h264_v4lm2m.
Lots and lots of dropped frames... 1 core is almost 100% while the others stay at about 10%.

Is this the kind of performance that we should expect from the opensource v4l2 mesa framework?
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 324

PostPosted: Sun Mar 31, 2019 12:19 am    Post subject: Reply with quote

brikko,

quite possibly there will be issues with it, as it has just been introduced with kernel 4.19; presumably it will get better over time. On my tests the hardware codec paths performed significantly better on high-bitrate files than the software paths did. But they may not yet exploit all the zero-copy buffering etc. that the MMAL paths can.

The version of VLC on the image does not yet use the v4l2 m2m HW codec paths, nor does kodi etc.

ffplay should do so however, when you force the vcodec as stated.

Can you share the URL of the target file you are trying to play?
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
brikko
n00b
n00b


Joined: 30 Mar 2019
Posts: 2

PostPosted: Sun Mar 31, 2019 10:17 am    Post subject: Reply with quote

I noticed. There's definitely a difference between kodi/vlc (sw) and ffplay (hw), but even with v4l2m2m it's just not as smooth as it is with the proprietary driver, even with the basic 10Mb jellyfish test file. I can clearly see stuttering there.

The other file I tried to play is a common 1080p.AMZN.WEB-DL.DD+5.1.H.264-AJP69 mkv release.
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 324

PostPosted: Sun Mar 31, 2019 11:07 am    Post subject: Reply with quote

brikko,

The other issue is pushing the rendered frames out for display. Currently, even with the v4l2 m2m codecs, this is done using a regular gl pipeline. As such, if you have a very high-res display, it can easily become the bottleneck (again, MMAL based systems can write directly, which is much faster).

Turning window-manager compositing off, and selecting the kms, rather than fkms, driver, helps with this, a bit.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
roylongbottom
n00b
n00b


Joined: 13 Feb 2017
Posts: 53
Location: Essex, UK

PostPosted: Sun Mar 31, 2019 4:53 pm    Post subject: Reply with quote

Sakaki wrote:
roylongbottom,

So do I read you right, you can reproducibly create non-deterministic output (for a supposedly deterministic program) under certain (relatively high-load) conditions on the RPi3B (in 32-bit mode), where the temperature is high but below the default critical threshold?

Isn't that quite a serious issue? Have the RPF engineers come back to you with any comments?


Recreating the HPL type of failure (not necessarily the same) involved experimentation with known attributes of the program and results - floating point calculation speed varied and failures could be at lower speeds (with less heat), 100% utilisation of 4 cores, data size much greater than cache capacity that would need regular refreshing, original single CPU Linpack depended on L2 cache speed, failures not seen running my stress tests where all data could be in cache (but could be if run for a long time). So I tried stress tests with data larger than L2 cache size, where performance could be expected to vary.

Yes the issue is serious. See reply regarding more issues.

https://www.raspberrypi.org/forums/viewtopic.php?f=31&t=44080&start=100#p1449330
_________________
Regards

Roy
Back to top
View user's profile Send private message
Irre
Guru
Guru


Joined: 09 Nov 2013
Posts: 347
Location: Stockholm

PostPosted: Sun Apr 14, 2019 6:34 pm    Post subject: Reply with quote

Sakaki!
Please add "samba" as default use parameter for kodi. It works, but there are too many recompilations. (My media server runs samba). :D
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 324

PostPosted: Tue Apr 16, 2019 8:09 pm    Post subject: Reply with quote

Irre,

samba USE flag added to the defaults, and rebuilt kodi-18.0 pushed to the binhost.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
Irre
Guru
Guru


Joined: 09 Nov 2013
Posts: 347
Location: Stockholm

PostPosted: Tue Apr 16, 2019 9:45 pm    Post subject: Reply with quote

Thank you very much! :D
Back to top
View user's profile Send private message
Precision
n00b
n00b


Joined: 05 Sep 2018
Posts: 3

PostPosted: Tue Apr 23, 2019 10:24 pm    Post subject: Reply with quote

Sakaki wrote:
  • Kernel migrated to rpi-4.19.y (sys-kernel/bcmrpi3-kernel-bis-bin-4.19.25.20190226).

Does anyone know what commit this represents in the raspberrypi/linux git repo? There is no corresponding 20190226 release, and I did not find this information in the source tarball or release notes.

Edit: After cloning the repo and all that fun, time-consuming stuff, I see the commit is probably eb1e5b1a64ee6526a7cdb22357dcafc6ba643fbe. This is still just an educated guess, though, and I have no way of being certain. I remain interested in a foolproof way to determine the raspberrypi/linux commits that are used for Sakaki's releases. There appear to be many commits since the sublevel version bump to 36, for example. Does Sakaki build from 4.19.36's most recent commit (as of right now, 210f0d39438017f3b4e9a92cf4e2ccac8be3e795) or its first commit (c98875d930e915d01e8c40c7d3c16f00b3c8abe1)?
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 324

PostPosted: Thu Apr 25, 2019 5:32 pm    Post subject: Reply with quote

Hi Precision,

if you look at the notes accompanying the corresponding bcmrpi3-kernel-bis release (the instance of the weekly kernel autobuild which the bcmrpi3-kernel-bis-bin-4.19.25.20190226.ebuild you cited uses as its upstream), it says:
Code:
Release of version 4.19.25.20190226 (kernel 4.19.25-v8-78eb13b25d5e-bis+)
(You can also see this kernel release name by issuing uname -r on a booted system).

As then explained in that project's readme:
Code:
As with its sister project bcmrpi3-kernel, the baseline build configuration is the upstream bcmrpi3_defconfig, wherein the first 12 hex digits of the tip commit SHA1 hash are appended to CONFIGLOCALVERSION (with a separating hyphen).
...
As an (historical) example, on 1 June 2018, the default branch was rpi-4.14.y (NB, it is rpi-4.19.y now), and the latest commit was 4fca48b7612da3ff5737e27da15b0964bdf4928f (the short form of which is 4fca48b7612d). The created release was 4.14.44.20180601, within which the kernel tarball was bcmrpi3-kernel-bis-4.14.44.20180601.tar.xz, and the corresponding kernel release name was 4.14.44-v8-4fca48b7612d-bis+.


By the same logic, the tip commit (of the 4.19.y branch) when the 4.19.25.20190226 kernel was built, was 78eb13b25d5e.

Which can be looked up at https://github.com/raspberrypi/linux/commit/78eb13b25d5e.

So, iterating for the 4.19.36 autobuild, we see it has a release name of 4.19.36-v8-210f0d394380-bis+. Therefore, the short form tip commit of 4.19.y at build time was 210f0d394380, which can be looked up at https://github.com/raspberrypi/linux/commit/210f0d394380. The long form is 210f0d39438017f3b4e9a92cf4e2ccac8be3e795 (i.e., your first answer ^-^).

Note you should always look up the commit hash from the kernel name like this if you require certainty, as even on a single day commits may well exist before and after the point at which the particular kernel was compiled.

Hope that makes sense!
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
Precision
n00b
n00b


Joined: 05 Sep 2018
Posts: 3

PostPosted: Fri Apr 26, 2019 7:02 am    Post subject: Reply with quote

Thank you for the thorough explanation. We are so lucky to have you. I am sorry, however, as I still don't understand why this produces zero results:

Code:
$ PAGER= git log -1
commit f70d3cee7ea9e6411559cc75e3882d4703752dfe (HEAD -> rpi-4.19.y, origin/rpi-4.19.y, origin/HEAD)
Merge: 210f0d394380 6c3fc187664b
Author: Phil Elwell <pelwell@users.noreply.github.com>
Date:   Wed Apr 24 14:59:59 2019 +0100

    Merge pull request #2941 from P33M/rpi-4.19.y

    Decrease cgroup mayhem
$ git log --format='%h' | wc # same number as currently on github
 788224  788224 10246912
$ git log --format='%h' --all | wc # illogical paranoia
 910116  910116 11831508
$ git log --format='%h' --all | grep -Fxm1 210f0d394380 # 4.19.36-v8-210f0d394380-bis+
210f0d394380
$ git log --format='%h' --all | grep -Fxm1 4fca48b7612d # your example
4fca48b7612d
$ uname -r
4.19.25-v8-78eb13b25d5e-bis+
$ git log --format='%h' --all | grep -Fxm1 78eb13b25d5e # my machine
$


Do you have any ideas?
Back to top
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Gentoo on ARM All times are GMT
Goto page Previous  1, 2, 3 ... , 18, 19, 20  Next
Page 19 of 20

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum