Hi All,
Just a heads up that the 4.15 kernel is headed to stable releases.
I did a bunch of testing over the weekend and fixed up a bunch of issues, added some minor enhancements across a number of platforms. There is a kernel-4.15.2-301.fc27 build [1] which had all those fixes for people to test, I expect a 4.15.3 kernel going to updates-testing later today or tomorrow.
A few notes for the fixes I added: * fixed cpufreq/thermal on i.MX6 (thanks kwizart for upstream fix) * Crypto/rng engine on some AllWinner devices now loads/works (A10/A143/A20 at least, I suspect more will come with later kernels) * Exynos 5 USB-3 issue should now be fixed once and for all (I hope) * A bunch of improvements for monitor detection on the Raspberry Pi * Ethernet driver more stable on AllWInner A64/H5 platforms (like Pine64) * Numerous other upstream fixes improvements that headed upstream * 4.15.3 (not in the build above) will include aarch64 fixes for Spectre/Meltdown.
So please test and feel free to reply to this thread with any new issues you see with the 4.15 series, or any positive results.
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=24966088
2018-02-12 18:56 GMT+01:00 Peter Robinson pbrobinson@gmail.com:
Hi All,
Just a heads up that the 4.15 kernel is headed to stable releases.
I did a bunch of testing over the weekend and fixed up a bunch of issues, added some minor enhancements across a number of platforms. There is a kernel-4.15.2-301.fc27 build [1] which had all those fixes for people to test, I expect a 4.15.3 kernel going to updates-testing later today or tomorrow.
A few notes for the fixes I added:
- fixed cpufreq/thermal on i.MX6 (thanks kwizart for upstream fix)
Thx for the mention!
There is also a patch that has landed in 4.16-rc1 to fix the load of the sdma firmware (included in our linux-firmware package). https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git/commit/?... If you care to backport to 4.15 at some point ;)
Thx
Peter, not sure what parts of this might be useful, so I'll try to keep it brief. Let me know if you want more details about anything.
Coming to you from Firefox running on F27 4.15.2-301.aarch64 running on a Raspberry Pi 3B. Xfce4 as GUI.
Last two installs (over the last week or so) were from the F27 link to aarch64 downloads, and I used the Workstation download in both cases: Fedora-Workstation-27-1.6.aarch64
The base 4.13 install was pretty unusable through the GUI. System crashed after initial setup as it was trying to bring up the login screen. Power cycled and it came up with the GUI screen. GUI performance was so slow that I presumed it was hung; might have just been performance, though. Login via ssh from Mac worked. Did a dnf update to get to 4.14.18-300 and when I rebooted got black screen (no login GUI); load was 0.01, so it was idle but graphical not working. I assumed that the 4.4.18 update broke X. Installed the 4.15 rpms ref'd here and got the black screen on boot. But in all those cases, could get to the system via ssh from my Mac. Performance for routine tasks similar to SUSE Leap 42.3. On 4.15, using nmcli, was able to get WiFi working routinely. So the biggest issue was the GUI -- which is a problem if you're trying to run the workstation environment. :-)
After meeting yesterday, did a fresh install of F-Workstation-27-1.6-aarch64 to get the initial 4.13 kernel. Again, slow GUI; did setup; system restarted GUI and brought up login screen successfully, but system hung when I logged in. Rebooted through power cycle and worked from Mac via ssh. Transferred over the 4.15 rpms and the brcm...txt file needed for WiFi (copied from site Paul ref'd). INSTALLED 4.15 DIRECTLY, AVOIDING 4.14 UPDATE. Came up with GUI on reboot. THEN did dnf update. Reboot, & GUI still works -- but is still very slow. Used GUI interface to set up WiFi: works. Did a "systemctl set-default multi-user.service" and rebooted to get rid of GUI login screen. Did a dnf groupinstall "xfce workstation". On console, did startxfce4 and got a usable GUI. Slower than OpenSUSE Leap 42.3 but usable and stable. Exited and tried Worg ... hung screen.
My tentative conclusion is that the Worg stuff is unusable at this point and that I'm better sticking with xfce. I'll try a clean install of minimal and then install xfce to see if that results in an even more stable and reliable workstation envt.
4.15 boots from either USB or microSD on the RPi-3B. The RPi-3B will boot from the microSD card or from a USB drive if it has been prepared (one-time process) to so. F27-4.15 will boot from either. (I use a microSD and microSD-USB adapter so the same card is used with different interfaces). Timings are comparable, but USB *seems* to boot a bit faster (54 sec vs 60 for microSD). But the good news is that you COULD do the initial dd copy onto a USB-interfaced SSD, resize the / partition with gparted on a host, and then boot the RPi directly from the SSD drive if you wanted, with no extra finagling needed.
I'll follow up with more info if my minimal install / 4.15 update / xfce install is successful.
David
On Wed, Feb 14, 2018 at 1:52 PM, David Todd hdtodd@gmail.com wrote:
Peter, not sure what parts of this might be useful, so I'll try to keep it brief. Let me know if you want more details about anything.
Coming to you from Firefox running on F27 4.15.2-301.aarch64 running on a Raspberry Pi 3B. Xfce4 as GUI.
Last two installs (over the last week or so) were from the F27 link to aarch64 downloads, and I used the Workstation download in both cases: Fedora-Workstation-27-1.6.aarch64
The base 4.13 install was pretty unusable through the GUI. System crashed after initial setup as it was trying to bring up the login screen. Power cycled and it came up with the GUI screen. GUI performance was so slow that I presumed it was hung; might have just been performance, though. Login via ssh from Mac worked. Did a dnf update to get to 4.14.18-300 and when I rebooted got black screen (no login GUI); load was 0.01, so it was idle but graphical not working. I assumed that the 4.4.18 update broke X. Installed the 4.15 rpms ref'd here and got the black screen on boot. But in all those cases, could get to the system via ssh from my Mac. Performance for routine tasks similar to SUSE Leap 42.3. On 4.15, using nmcli, was able to get WiFi working routinely. So the biggest issue was the GUI -- which is a problem if you're trying to run the workstation environment. :-)
After meeting yesterday, did a fresh install of F-Workstation-27-1.6-aarch64 to get the initial 4.13 kernel. Again, slow GUI; did setup; system restarted GUI and brought up login screen successfully, but system hung when I logged in. Rebooted through power cycle and worked from Mac via ssh. Transferred over the 4.15 rpms and the brcm...txt file needed for WiFi (copied from site Paul ref'd). INSTALLED 4.15 DIRECTLY, AVOIDING 4.14 UPDATE. Came up with GUI on reboot. THEN did dnf update. Reboot, & GUI still works -- but is still very slow. Used GUI interface to set up WiFi: works. Did a "systemctl set-default multi-user.service" and rebooted to get rid of GUI login screen. Did a dnf groupinstall "xfce workstation". On console, did startxfce4 and got a usable GUI. Slower than OpenSUSE Leap 42.3 but usable and stable. Exited and tried Worg ... hung screen.
My tentative conclusion is that the Worg stuff is unusable at this point and that I'm better sticking with xfce. I'll try a clean install of minimal and then install xfce to see if that results in an even more stable and reliable workstation envt.
What is Worg?
To be frank on the RPi3 you're actually better off using the 32 bit XFCE image, aarch64 will use more memory with no real additional gain. You can get the XFCE image directly for this purpose: https://arm.fedoraproject.org/
GM, Peter,
Typo ... Xorg.
Yes, I've tried several aarch64 versions on the RPi-3 and timed performance against the 32-bit versions, and the 32-bit versions substantially out-perform the 64-bit. I keep hoping the 64-bit versions will get faster, but I'm not so sure any more.
Mostly I wanted to do some ARM8 assembler to learn the architecture and test some algorithms that I hoped would leverage ARM8's architecture to improve performance. The excursions into 64-bit SUSE and Fedora are educational diversions, as I try to find a 64-bit version that is stable and performs reasonably well as an OS platform for my testing. So far, I've spent more time on my diversions than on my algorithms. :-)
David
On Wed, Feb 14, 2018 at 4:41 PM, David Todd hdtodd@gmail.com wrote:
GM, Peter,
Typo ... Xorg.
Yes, I've tried several aarch64 versions on the RPi-3 and timed performance against the 32-bit versions, and the 32-bit versions substantially out-perform the 64-bit. I keep hoping the 64-bit versions will get faster, but I'm not so sure any more.
Well it's got 1Gb of RAM and is a constrained platform, it's not really around the "64 bit versions" but rather the hardware, it's constrained and not really aimed at 64 bit, you basically just lose RAM etc due to the 64 bit for no material gain (you'd need over ~4gb RAM for that)
Mostly I wanted to do some ARM8 assembler to learn the architecture and test some algorithms that I hoped would leverage ARM8's architecture to improve performance. The excursions into 64-bit SUSE and Fedora are educational diversions, as I try to find a 64-bit version that is stable and performs reasonably well as an OS platform for my testing. So far, I've spent more time on my diversions than on my algorithms. :-)
So I'd run a minimal install without a GUI and then ssh into it. Fedora on aarch64 performs pretty well in a number of use cases but it's a $35 piece of HW... basically you get what you pay for.
Either way this is _WAY_ off topic of this thead
On Wed, Feb 14, 2018 at 5:47 PM, Tom Callaway tcallawa@redhat.com wrote:
On 02/14/2018 11:55 AM, Peter Robinson wrote:
Either way this is _WAY_ off topic of this thead
On this point, I'd disagree. The RPI hardware is rather ubiquitous, so having this discussion here (and, thus, in a searchable place), is on-topic IMHO. :)
On topic for this list sure, they capabilities of graphics/aarch64 etc on low end hardware is not really on topic for the 4,15 rebase, it's ongoing etc... It could easily be a dedicated thread which would make it even easier to discover than buried in a 4.15 rebase thread ;-)
I had trouble finding information about Fedora aarch64 to learn from others' experiences with it. If it makes sense to move much of the above discussion to a new thread about "Fedora aarch64 on Raspberry Pi", I'd be all for it and would add more as I get more experience. There are an awful lot of RPi's in the world, and for those of us interested in Fedora on the Pi, a focal point would be useful.
On 2/14/18 12:50 PM, Peter Robinson wrote:
On Wed, Feb 14, 2018 at 5:47 PM, Tom Callaway tcallawa@redhat.com wrote:
On 02/14/2018 11:55 AM, Peter Robinson wrote:
Either way this is _WAY_ off topic of this thead
On this point, I'd disagree. The RPI hardware is rather ubiquitous, so having this discussion here (and, thus, in a searchable place), is on-topic IMHO. :)
On topic for this list sure, they capabilities of graphics/aarch64 etc on low end hardware is not really on topic for the 4,15 rebase, it's ongoing etc... It could easily be a dedicated thread which would make it even easier to discover than buried in a 4.15 rebase thread ;-)
Peter, Thx. That's what I concluded and I'm off doing that right now. I'll install xfce for occasions when I really want a GUI, but primarily use the CLI.
And you're right about the limitations of a $35 computer -- but I'm impressed by its capabilities, too, running a Linux distribution with all those tools. Pretty incredible.
Didn't mean to sidetrack the thread, but I do appreciate your observations and help.
-
David Todd -
Nicolas Chauvet -
Peter Robinson -
Tom Callaway