[fedora-arm] The 4.15 kernel rebase on stable releases

Discussion:

Peter Robinson

2018-02-12 17:56:53 UTC

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
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an ema

Nicolas Chauvet

2018-02-14 13:23:27 UTC

Permalink

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/?h=topic/imx&id=c0879342efc41bc79a0836cc06ce2af22ec496c9
If you care to backport to 4.15 at some point ;)

Thx
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedoraproject.or

David Todd

2018-02-14 13:52:40 UTC

Permalink

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

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email

Peter Robinson

2018-02-14 16:14:31 UTC

Permalink

Post by David Todd
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/
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an ema

David Todd

2018-02-14 16:41:00 UTC

Permalink

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
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-leave@

Peter Robinson

2018-02-14 16:55:21 UTC

Permalink

Post by David Todd
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)

Post by David Todd
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
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedorapr

Tom Callaway

2018-02-14 17:47:56 UTC

Permalink

Post by Peter Robinson
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. :)

~tom
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-

Peter Robinson

2018-02-14 17:50:15 UTC

Permalink

Post by Tom Callaway

Post by Peter Robinson
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 ;-)
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe se

David Todd

2018-02-14 19:34:56 UTC

Permalink

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.

Post by Peter Robinson

Post by Tom Callaway

Post by Peter Robinson
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. :)

David Todd

2018-02-14 18:02:02 UTC

Permalink

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.
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.f

Stewart Samuels

2018-02-22 22:21:49 UTC

Permalink

Sorry about not transmitting to the list previously.Â I hadn't noticed
till you just pointed it out.Â My bad!!!

Okay.Â My follow-up.Â I tried to install
Fedora-Xfce-armhfp-Rawhide-20180220.n.0-sda.raw.xz.Â Here is a snippet
from dracut during the installation process which I believe to be relevant:

[ 4719.209090] dracut[1462] Executing: /usr/bin/dracut -f
/boot/initramfs-4.16.0-0.rc2.git0.1.fc28.armv7hl.img
4.16.0-0.rc2.git0.1.fc28.armv7hl

[ 4721.152402] dracut[1462] dracut module 'busybox' will not be
installed, because command 'busybox' could not be found!

[ 4724.107476] dracut[1462] dracut module 'biosdevname' will not
be installed, because command 'biosdevname' could not be found!

[ 4725.185474] dracut[1462] dracut module 'busybox' will not be
installed, because command 'busybox' could not be found!

[ 4727.693909] dracut[1462] *** Including module: bash ***

[ 4727.799897] dracut[1462] *** Including module: systemd ***

[ 4730.596548] dracut[1462] *** Including module: systemd-initrd ***

[ 4730.859397] dracut[1462] *** Including module: nss-softokn ***

[ 4731.005977] dracut[1462] *** Including module: i18n ***

[ 4733.099767] dracut[1462] *** Including module: network ***

[ 4734.115142] dracut[1462] *** Including module: ifcfg ***

[ 4734.205946] dracut[1462] *** Including module: drm ***

[ 4734.634405] dracut[1462] *** Including module: plymouth ***

[ 4736.175415] dracut[1462] *** Including module: kernel-modules ***

[ 4743.067874] dracut[1462] *** Including module:
kernel-network-modules ***

[ 4743.551749] dracut[1462] *** Including module: rootfs-block ***

[ 4743.692609] dracut[1462] *** Including module: terminfo ***

[ 4743.857149] dracut[1462] *** Including module: udev-rules ***

[ 4744.004466] dracut[1462] Skipping udev rule: 40-redhat.rules

[ 4744.025481] dracut[1462] Skipping udev rule: 50-firmware.rules

[ 4744.046519] dracut[1462] Skipping udev rule: 50-udev.rules

[ 4745.995457] dracut[1462] Skipping udev rule: 91-permissions.rules

[ 4746.018661] dracut[1462] Skipping udev rule:
80-drivers-modprobe.rules

[ 4746.256854] dracut[1462] *** Including module: dracut-systemd ***

[ 4747.002206] dracut[1462] *** Including module: usrmount ***

[ 4747.064120] dracut[1462] *** Including module: base ***

[ 4747.670184] dracut[1462] *** Including module: fs-lib ***

[ 4747.892757] dracut[1462] *** Including module: shutdown ***

[ 4748.488677] dracut[1462] *** Including modules done ***

[ 4748.514363] dracut[1462] *** Installing kernel module
dependencies ***

[ 4749.681429] dracut[1462] *** Installing kernel module
dependencies done ***

[ 4749.826826] dracut[1462] *** Resolving executable
dependencies ***

[ 4757.901864] dracut[1462] *** Resolving executable
dependencies done***

[ 4758.173199] dracut[1462] *** Hardlinking files ***

[ 4758.361998] dracut[1462] *** Hardlinking files done ***

[ 4758.396299] dracut[1462] *** Stripping files ***

[ 4758.693423] dracut[1462] *** Stripping files done ***

[ 4758.720413] dracut[1462] *** Generating early-microcode cpio
image ***

[ 4758.812895] dracut[1462] *** Constructing AuthenticAMD.bin ****

[ 4758.980397] dracut[1462] *** Store current command line
parameters ***

[ 4759.014533] dracut[1462] *** Creating image file
'/boot/initramfs-4.16.0-0.rc2.git0.1.fc28.armv7hl.img' ***

[ 4774.636604] dracut[1462] Image:
/var/tmp/dracut.Y9Up20/initramfs.img: 18M

So, although the boot messages are different now, the result is the
same.Â The system boots but not into graphical mode.Â Also, note the
orange highlighted lines from dracut.

I will try to get the dmesg | fpaste output once I get the system on the
network.Â Is there a particular URL you would like me to specify?

Also, one other question.Â Is there anything from partition 1 (which
seems to be strictly for Raspberry PIs) necessary to build and boot the
system for other systems like the Odroid?Â More specifically, should I
be able to build and boot the system using ONLY partitions 2,3,and 4?

Thanks again.

Â Â Â Â Â Stewart

Can you try the 4.16rc2 kernel [1] and see if that has the same
issues. The 4.16 kernel might help as there was a bunch of stuff that
changed in the exynos drm driver.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1046448

Looking at the builds in this URL I see "rawhide" listed as one of the
"Tasks". Doe this mean the current rawhide build are already including the
kernel-4.16.0-0.rc2 kernel?

Yes, and the just branched F-28 will as well. So you can do an upgrade
to F-28 and get it there too

Attached, is a MS Word formatted file of my boot log. Hope this helps.

Please don't do that, word processing docs are really not the way to
handle this in open source just fpaste it or something. If it's booted
just do "dmesg | fpaste" and provide the URL.

Regards,
Stewart

Post by Peter Robinson
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.
* 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
_______________________________________________

Peter Robinson

2018-02-22 22:32:52 UTC

Permalink

Sorry about not transmitting to the list previously. I hadn't noticed till
you just pointed it out. My bad!!!
Okay. My follow-up. I tried to install
Fedora-Xfce-armhfp-Rawhide-20180220.n.0-sda.raw.xz. Here is a snippet from
[ 4719.209090] dracut[1462] Executing: /usr/bin/dracut -f
/boot/initramfs-4.16.0-0.rc2.git0.1.fc28.armv7hl.img
4.16.0-0.rc2.git0.1.fc28.armv7hl
[ 4721.152402] dracut[1462] dracut module 'busybox' will not be installed,
because command 'busybox' could not be found!
[ 4724.107476] dracut[1462] dracut module 'biosdevname' will not be
installed, because command 'biosdevname' could not be found!
[ 4725.185474] dracut[1462] dracut module 'busybox' will not be installed,
because command 'busybox' could not be found!
[ 4727.693909] dracut[1462] *** Including module: bash ***
[ 4727.799897] dracut[1462] *** Including module: systemd ***
[ 4730.596548] dracut[1462] *** Including module: systemd-initrd ***
[ 4730.859397] dracut[1462] *** Including module: nss-softokn ***
[ 4731.005977] dracut[1462] *** Including module: i18n ***
[ 4733.099767] dracut[1462] *** Including module: network ***
[ 4734.115142] dracut[1462] *** Including module: ifcfg ***
[ 4734.205946] dracut[1462] *** Including module: drm ***
[ 4734.634405] dracut[1462] *** Including module: plymouth ***
[ 4736.175415] dracut[1462] *** Including module: kernel-modules ***
[ 4743.067874] dracut[1462] *** Including module: kernel-network-modules ***
[ 4743.551749] dracut[1462] *** Including module: rootfs-block ***
[ 4743.692609] dracut[1462] *** Including module: terminfo ***
[ 4743.857149] dracut[1462] *** Including module: udev-rules ***
[ 4744.004466] dracut[1462] Skipping udev rule: 40-redhat.rules
[ 4744.025481] dracut[1462] Skipping udev rule: 50-firmware.rules
[ 4744.046519] dracut[1462] Skipping udev rule: 50-udev.rules
[ 4745.995457] dracut[1462] Skipping udev rule: 91-permissions.rules
[ 4746.018661] dracut[1462] Skipping udev rule: 80-drivers-modprobe.rules
[ 4746.256854] dracut[1462] *** Including module: dracut-systemd ***
[ 4747.002206] dracut[1462] *** Including module: usrmount ***
[ 4747.064120] dracut[1462] *** Including module: base ***
[ 4747.670184] dracut[1462] *** Including module: fs-lib ***
[ 4747.892757] dracut[1462] *** Including module: shutdown ***
[ 4748.488677] dracut[1462] *** Including modules done ***
[ 4748.514363] dracut[1462] *** Installing kernel module dependencies ***
[ 4749.681429] dracut[1462] *** Installing kernel module dependencies done
***
[ 4749.826826] dracut[1462] *** Resolving executable dependencies ***
[ 4757.901864] dracut[1462] *** Resolving executable dependencies done***
[ 4758.173199] dracut[1462] *** Hardlinking files ***
[ 4758.361998] dracut[1462] *** Hardlinking files done ***
[ 4758.396299] dracut[1462] *** Stripping files ***
[ 4758.693423] dracut[1462] *** Stripping files done ***
[ 4758.720413] dracut[1462] *** Generating early-microcode cpio image ***
[ 4758.812895] dracut[1462] *** Constructing AuthenticAMD.bin ****
[ 4758.980397] dracut[1462] *** Store current command line parameters ***
[ 4759.014533] dracut[1462] *** Creating image file
'/boot/initramfs-4.16.0-0.rc2.git0.1.fc28.armv7hl.img' ***
[ 4774.636604] dracut[1462] Image: /var/tmp/dracut.Y9Up20/initramfs.img: 18M
So, although the boot messages are different now, the result is the same.
The system boots but not into graphical mode. Also, note the orange
highlighted lines from dracut.
I will try to get the dmesg | fpaste output once I get the system on the
network. Is there a particular URL you would like me to specify?
Also, one other question. Is there anything from partition 1 (which seems
to be strictly for Raspberry PIs) necessary to build and boot the system for
other systems like the Odroid? More specifically, should I be able to build
and boot the system using ONLY partitions 2,3,and 4?

For the moment yes, but it's a few MB, and it'll be a best effort
support because it'll be impossible to work out what's different or
what broke if it ceases to work. Moving forward we'll likely be moving
ARMv7 to uefi boot like aarch64 which would also mean you'd need to
reinstall as there would be no migration path. What issue doe the
extra partition cause?

Hi Peter,
I just got a chance to update my Odroid Xu4 with the latest updates for
F27.
All was working fine with the exceptions for the Exynos 5 USB-3 issues
prior
to this upgrade. After the upgrade and a reboot, my system no longer
boots
into graphics mode. It seems to be failing somewhere along the line with
udev, but I am not certain of this. The system will eventually boot into
non-graphics mode, which can be seen when connecting the serial port and
watching the boot messages.
As I mentioned in previous posts, the Rawhide Spins all seem to have this
issue too. In fact, they have had the problem for a long time now. On
the
positive side, both this release of F27 updates and the Rawhide spins do
seem to have the USB-3 issues fixed.
Can you try the 4.16rc2 kernel [1] and see if that has the same
issues. The 4.16 kernel might help as there was a bunch of stuff that
changed in the exynos drm driver.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1046448
Looking at the builds in this URL I see "rawhide" listed as one of the
"Tasks". Doe this mean the current rawhide build are already including the
kernel-4.16.0-0.rc2 kernel?
Yes, and the just branched F-28 will as well. So you can do an upgrade
to F-28 and get it there too
Attached, is a MS Word formatted file of my boot log. Hope this helps.
Please don't do that, word processing docs are really not the way to
handle this in open source just fpaste it or something. If it's booted
just do "dmesg | fpaste" and provide the URL.
Regards,
Stewart
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.
* 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
_______________________________________________
_______________________________________________

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-l

Stewart Samuels

2018-02-22 22:43:57 UTC

Permalink

It doesn't cause additional issues. Just that in graphics mode, it
always gets mounted on the desktop. However, if it is required for
building or booting my odroid, that could be a problem because with my
current build procedures, I do not copy this partition to either my SD
or MMC devices.

Tomorrow, if I have some time, I will try to extract the 4.16 kernel
image manually with all partitions on the SD drive and see if the boot
problem still persists.

Thanks.

Stewart

Post by Peter Robinson

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubsc

Stewart Samuels

2018-02-24 04:40:46 UTC

Permalink

I just got a chance to test the 4.16.0-0.rc2 kernel using the 20180220
Xfce Rawhide Spin.Â It fails to boot due to a kernel paging request.Â
Here are the snippets:

U-Boot 2018.03-rc2 (Feb 16 2018 - 14:14:52 +0000) for ODROID-XU3/XU4/HC1

CPU:Â Â Exynos5422 @ 800 MHz
Model: Odroid XU3 based on EXYNOS5422
Board: Odroid XU3 based on EXYNOS5422
Type:Â xu4
DRAM:Â 2 GiB
MMC:Â Â EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default
environment

Failed (-5)
In:Â Â Â serial
Out:Â Â serial
Err:Â Â serial
Net:Â Â No ethernet found.
Hit any key to stop autoboot:Â 0
mmc_init: -5, time 6
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:2...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
591 bytes read in 14 ms (41 KiB/s)
Ignoring unknown command: ui
Ignoring malformed menu command:Â autoboot
Ignoring malformed menu command:Â hidden
Ignoring unknown command: totaltimeout
Fedora-Xfce-armhfp-Rawhide-20180220.n.0 Boot Options.
1:Â Â Â Â Â Fedora-Xfce-armhfp-Rawhide-20180220.n.0
(4.16.0-0.rc2.git0.1.fc28.armv7hl)
Enter choice: 1:Â Â Â Â Â Â Â Fedora-Xfce-armhfp-Rawhide-20180220.n.0
(4.16.0-0.rc2.git0.1.fc28.armv7hl)
Retrieving file: /initramfs-4.16.0-0.rc2.git0.1.fc28.armv7hl.img
54271696 bytes read in 4082 ms (12.7 MiB/s)
Retrieving file: /vmlinuz-4.16.0-0.rc2.git0.1.fc28.armv7hl
6660608 bytes read in 519 ms (12.2 MiB/s)
append: ro root=UUID=7d9c6236-7437-49c9-9e30-cf5ba8d147d5 cma=192MB
Retrieving file:
/dtb-4.16.0-0.rc2.git0.1.fc28.armv7hl/exynos5422-odroidxu4.dtb
56970 bytes read in 508 ms (109.4 KiB/s)
Kernel image @ 0x42000000 [ 0x000000 - 0x65a200 ]
## Flattened Device Tree blob at 43000000
Â Â Booting using the fdt blob at 0x43000000
Â Â Loading Ramdisk to 4cc3e000, end 4ffffed0 ... OK
Â Â Loading Device Tree to 4cc2d000, end 4cc3de89 ... OK

Starting kernel ...

[Â Â Â 0.000000] Booting Linux on physical CPU 0x100
[Â Â Â 0.000000] Linux version 4.16.0-0.rc2.git0.1.fc28.armv7hl
(***@buildvm-armv7-07.arm.fedoraproject.org) (gcc version
8.0.1 20180218 8
[Â Â Â 0.000000] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7),
cr=10c5387d

.
.
.

[Â Â Â 6.366866] 12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq =
61, base_baud = 0) is a S3C6400/10
[Â Â Â 6.377630] msm_serial: driver initialized
[Â Â Â 6.380655] STMicroelectronics ASC driver initialized
[Â Â Â 6.390013] libphy: Fixed MDIO Bus: probed
[Â Â Â 6.393299] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI)
Driver
[Â Â Â 6.399194] ehci-pci: EHCI PCI platform driver
[Â Â Â 6.403631] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[Â Â Â 6.409762] ohci-pci: OHCI PCI platform driver
[Â Â Â 6.414203] uhci_hcd: USB Universal Host Controller Interface driver
[Â Â Â 6.420729] usbcore: registered new interface driver
usbserial_generic
[Â Â Â 6.427020] usbserial: USB Serial support registered for generic
[Â Â Â 6.433186] mousedev: PS/2 mouse device common for all mice
[Â Â Â 6.445564] device-mapper: uevent: version 1.0.3
[Â Â Â 6.449213] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20)
initialised: dm-***@redhat.com
[Â Â Â 6.461297] ledtrig-cpu: registered to indicate activity on CPUs
[Â Â Â 6.466198] hidraw: raw HID events driver (C) Jiri Kosina
[Â Â Â 6.471445] usbcore: registered new interface driver usbhid
[Â Â Â 6.476783] usbhid: USB HID core driver
[Â Â Â 6.483709] drop_monitor: Initializing network drop monitor service
[Â Â Â 6.489025] Initializing XFRM netlink socket
[Â Â Â 6.493716] NET: Registered protocol family 10
[Â Â Â 8.028149] Unable to handle kernel paging request at virtual
address fffffffc

Stewart

Looking at the builds in this URL I see "rawhide" listed as one of the
"Tasks". Doe this mean the current rawhide build are already including the
kernel-4.16.0-0.rc2 kernel?

Yes, and the just branched F-28 will as well. So you can do an upgrade
to F-28 and get it there too

Attached, is a MS Word formatted file of my boot log. Hope this helps.

Please don't do that, word processing docs are really not the way to
handle this in open source just fpaste it or something. If it's booted
just do "dmesg | fpaste" and provide the URL.

Regards,
Stewart

Peter Robinson

2018-02-24 12:07:59 UTC

Permalink

I just got a chance to test the 4.16.0-0.rc2 kernel using the 20180220 Xfce
Rawhide Spin. It fails to boot due to a kernel paging request. Here are
[ 8.028149] Unable to handle kernel paging request at virtual address fffffffc

Wow kernel, thanks, it's very useful :-/

Was there any further output after this? The kernel would normally
spit out a full traceback right after this line.

There's some fixes for the exynos landed for rc3 so might be worth
trying that one when it lands next week.

P

Stewart
Hi Peter,
I just got a chance to update my Odroid Xu4 with the latest updates for
F27.
All was working fine with the exceptions for the Exynos 5 USB-3 issues
prior
to this upgrade. After the upgrade and a reboot, my system no longer
boots
into graphics mode. It seems to be failing somewhere along the line with
udev, but I am not certain of this. The system will eventually boot into
non-graphics mode, which can be seen when connecting the serial port and
watching the boot messages.
As I mentioned in previous posts, the Rawhide Spins all seem to have this
issue too. In fact, they have had the problem for a long time now. On
the
positive side, both this release of F27 updates and the Rawhide spins do
seem to have the USB-3 issues fixed.
Can you try the 4.16rc2 kernel [1] and see if that has the same
issues. The 4.16 kernel might help as there was a bunch of stuff that
changed in the exynos drm driver.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1046448
Looking at the builds in this URL I see "rawhide" listed as one of the
"Tasks". Doe this mean the current rawhide build are already including the
kernel-4.16.0-0.rc2 kernel?
Yes, and the just branched F-28 will as well. So you can do an upgrade
to F-28 and get it there too
Attached, is a MS Word formatted file of my boot log. Hope this helps.
Please don't do that, word processing docs are really not the way to
handle this in open source just fpaste it or something. If it's booted
just do "dmesg | fpaste" and provide the URL.
Regards,
Stewart
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.
* 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
_______________________________________________
_______________________________________________

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedoraproj

Stewart Samuels

2018-02-24 17:09:05 UTC

Permalink

No. No other messages follow. The system freezes at this point.

Stewart

Post by Peter Robinson

Wow kernel, thanks, it's very useful :-/
Was there any further output after this? The kernel would normally
spit out a full traceback right after this line.
There's some fixes for the exynos landed for rc3 so might be worth
trying that one when it lands next week.
P

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@l

Stewart Samuels

2018-03-05 04:10:31 UTC

Permalink

Hello All,

I am happy to report that the latest Rawhide spin
"Fedora-Mate-armhfp-Rawhide-20180301.n.0-sda.raw.xz
<https://mirrors.rit.edu/fedora/fedora/linux/development/rawhide/Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20180301.n.0-sda.raw.xz>"
seems to be working correctly now for the Odroid XU4.Â The system boots
into graphical mode and the USB 3 issues seem to be working as well.Â
This version of spins is using the 4.16.0-0.rc3 kernel.

Â Â Â Â Stewart

No.Â No other messages follow.Â The system freezes at this point.
Stewart

On Sat, Feb 24, 2018 at 4:40 AM, Stewart Samuels

I just got a chance to test the 4.16.0-0.rc2 kernel using the 20180220 Xfce
Rawhide Spin.Â It fails to boot due to a kernel paging request.Â
Here are
[Â Â Â 8.028149] Unable to handle kernel paging request at virtual
address fffffffc

Wow kernel, thanks, it's very useful :-/
Was there any further output after this? The kernel would normally
spit out a full traceback right after this line.
There's some fixes for the exynos landed for rc3 so might be worth
trying that one when it lands next week.
P

Stewart
Hi Peter,
I just got a chance to update my Odroid Xu4 with the latest updates for
F27.
All was working fine with the exceptions for the Exynos 5 USB-3 issues
prior
to this upgrade.Â After the upgrade and a reboot, my system no longer
boots
into graphics mode.Â It seems to be failing somewhere along the line
with
udev, but I am not certain of this.Â The system will eventually boot
into
non-graphics mode, which can be seen when connecting the serial port and
watching the boot messages.
As I mentioned in previous posts, the Rawhide Spins all seem to have this
issue too.Â In fact, they have had the problem for a long time now.Â On
the
positive side, both this release of F27 updates and the Rawhide spins do
seem to have the USB-3 issues fixed.
Can you try the 4.16rc2 kernel [1] and see if that has the same
issues. The 4.16 kernel might help as there was a bunch of stuff that
changed in the exynos drm driver.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1046448
Looking at the builds in this URL I see "rawhide" listed as one of the
"Tasks".Â Doe this mean the current rawhide build are already
including the
kernel-4.16.0-0.rc2 kernel?
Yes, and the just branched F-28 will as well. So you can do an upgrade
to F-28 and get it there too
Attached, is a MS Word formatted file of my boot log.Â Hope this helps.
Please don't do that, word processing docs are really not the way to
handle this in open source just fpaste it or something. If it's booted
just do "dmesg | fpaste" and provide the URL.
Regards,
Stewart
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.
* 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
_______________________________________________
_______________________________________________

Stewart Samuels

2018-03-21 22:16:26 UTC

Permalink

Hello All,

FYI.Â After my previous successes (see thread below) I earlier this week
performed an upgrade on my Odroid XU4 to the latest version of Rawhide
Mate Spin.Â For some reason, once again, although the system boots, it
no longer boots into graphical mode, complaining of a UDEV issue.Â This
is the same problem it seems I was running into with the latest updates
of F27 and why I switched over to the Rawhide releases with the newer
kernel.Â With the updated software, my Odroid boots into graphical mode
if I use the previously installed 4.16.0-0.rc3 kernel, but not with the
newer kernel.

I will upgrade it again to the latest rawhide release and post the log
of that, should I still have issues.

Â Â Â Â Stewart

Post by Stewart Samuels
Hello All,
I am happy to report that the latest Rawhide spin
"Fedora-Mate-armhfp-Rawhide-20180301.n.0-sda.raw.xz
<https://mirrors.rit.edu/fedora/fedora/linux/development/rawhide/Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20180301.n.0-sda.raw.xz>"
seems to be working correctly now for the Odroid XU4.Â The system
boots into graphical mode and the USB 3 issues seem to be working as
well.Â This version of spins is using the 4.16.0-0.rc3 kernel.
Â Â Â Â Stewart

No. No other messages follow.Â The system freezes at this point.
Stewart

On Sat, Feb 24, 2018 at 4:40 AM, Stewart Samuels

Wow kernel, thanks, it's very useful :-/
Was there any further output after this? The kernel would normally
spit out a full traceback right after this line.
There's some fixes for the exynos landed for rc3 so might be worth
trying that one when it lands next week.
P

Stewart
On Thu, Feb 22, 2018 at 7:52 PM, Stewart Samuels
On Thu, Feb 22, 2018 at 7:24 PM, Stewart Samuels
Hi Peter,
I just got a chance to update my Odroid Xu4 with the latest updates for
F27.
All was working fine with the exceptions for the Exynos 5 USB-3 issues
prior
to this upgrade.Â After the upgrade and a reboot, my system no longer
boots
into graphics mode.Â It seems to be failing somewhere along the
line with
udev, but I am not certain of this.Â The system will eventually
boot into
non-graphics mode, which can be seen when connecting the serial port and
watching the boot messages.
As I mentioned in previous posts, the Rawhide Spins all seem to have this
issue too.Â In fact, they have had the problem for a long time now.Â On
the
positive side, both this release of F27 updates and the Rawhide spins do
seem to have the USB-3 issues fixed.
Can you try the 4.16rc2 kernel [1] and see if that has the same
issues. The 4.16 kernel might help as there was a bunch of stuff that
changed in the exynos drm driver.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1046448
Looking at the builds in this URL I see "rawhide" listed as one of the
"Tasks".Â Doe this mean the current rawhide build are already
including the
kernel-4.16.0-0.rc2 kernel?
Yes, and the just branched F-28 will as well. So you can do an upgrade
to F-28 and get it there too
Attached, is a MS Word formatted file of my boot log.Â Hope this helps.
Please don't do that, word processing docs are really not the way to
handle this in open source just fpaste it or something. If it's booted
just do "dmesg | fpaste" and provide the URL.
Regards,
Stewart
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.
* 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
_______________________________________________
_______________________________________________