d_older
Posts: 102
Joined: Mon Jun 25, 2012 5:04 pm
Location: East Yorkshire, UK

Re: Moving Linux kernel to 4.14

Tue May 01, 2018 10:35 pm

Ernst wrote:
Tue May 01, 2018 7:10 am
d_older wrote:
Mon Apr 30, 2018 10:39 pm
Note that the g_cdc module works perfectly with the zero(W) with stretch on 4.9
The g_cdc module works perfectly with the Pi zero using stretch with 4.14.34
I was using a Debian 64 bit 9.4 box - 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) where I was having issues I didn't see with Pi 4.9.

I've now tried Pi3 4.14.34-v7+ to Pi zero W 4.14.34+ and that works. The only issue I have is that stty does not appear to be able to set speed on the zero side

Code: Select all

stty: /dev/ttyGS0: unable to perform all requested operations
There is no error if attempted from the host side but miniterm.py still reports the original 9600.

A workround seems to be using miniterm.py's speed option on both sides and that is reported as being used.

Many thanks Ernst for your reply.

Unfortunately this doesn't help with ejolson's jumbo frame issue.

Now onto the "non-legacy" configfs method pi to pi to see if the "missing" kernel settings are required for that.

Dave

Note I've edited my original to 4.14.34+ (fat fingers)

edge0f17
Posts: 17
Joined: Sun Oct 25, 2015 6:55 am

Re: Moving Linux kernel to 4.14

Wed May 02, 2018 7:46 am

I have looked at the jumbo frames issue, and it was already broken in Linux 4.12. Likely due to the commit: https://github.com/raspberrypi/linux/co ... 183ed30443

This had unintended consequences that I in no way understand:
https://github.com/raspberrypi/linux/co ... e825711a94

Needs to be reported and fixed upstream.

edge0f17
Posts: 17
Joined: Sun Oct 25, 2015 6:55 am

Re: Moving Linux kernel to 4.14

Wed May 02, 2018 12:26 pm

https://github.com/raspberrypi/linux/co ... f41103d422

fixed max_mtu in the function gether_setup_name(), but that one is not used: they should have fixed gether_setup_name_default()

Looks like an easy fix.

ejolson
Posts: 2194
Joined: Tue Mar 18, 2014 11:47 am

Re: Moving Linux kernel to 4.14

Thu May 03, 2018 2:19 pm

edge0f17 wrote:
Wed May 02, 2018 12:26 pm
they should have fixed gether_setup_name_default()

Looks like an easy fix.
That's great news! Thanks for checking into this. I wonder how soon the fix for this regression will be included in the official kernel.

ejolson
Posts: 2194
Joined: Tue Mar 18, 2014 11:47 am

Re: Moving Linux kernel to 4.14

Wed May 09, 2018 5:05 pm

Another regression with the 4.14 series kernel is reported here. The issue seems to be that the new kernel requires an additional module in the initial ram filesystem, if booting that way. This could also be fixed by building the necessary module into the kernel.

Alex.
Posts: 6
Joined: Sun Feb 25, 2018 9:49 pm

Re: Moving Linux kernel to 4.14

Wed May 09, 2018 8:21 pm

ejolson wrote:
Wed May 09, 2018 5:05 pm
Another regression with the 4.14 series kernel is reported here. The issue seems to be that the new kernel requires an additional module in the initial ram filesystem, if booting that way. This could also be fixed by building the necessary module into the kernel.
It seems that's the same (or similar) FIQ bug issued here viewtopic.php?f=29&t=197689&start=50#p1272684
Don't know why it triggers only with a ramfs

DennisT
Posts: 3
Joined: Tue Jul 05, 2016 8:45 pm

Re: Moving Linux kernel to 4.14

Tue Jun 12, 2018 5:17 pm

Hi,
I ran this update and am now having a problem. Hopefully there's a fix available. I have a RPi3B set up as a kiosk device (Raspbian Jesse). It feeds a VGA monitor via a HDMI to VGA adapter. The application is a python script run full screen under xterm.
Startup is like:

Code: Select all

# disable DPMS (Energy Star) features.
xset -dpms
# disable screen saver
xset s off
# don't blank the video device
xset s noblank
# disable mouse pointer
unclutter &
# run window manager
matchbox-window-manager -use_cursor no -use_titlebar no  &
#start x11vnc for remote access
x11vnc -forever -usepw -display :0 &
# run xterm
lxterminal --geometry=150x50 --command /usr/local/bin/TC.sh
abbreviated TC.sh is

Code: Select all

unbuffer $BASEPATH/TimeClock.py
The application monitors activity and turns off the display by making an OS call:
tvservice -o
When activity occurs it then turns the display back on:
tvservice -p >/dev/null 2>&1
fbset -depth 8;
fbset -depth 16;

This has all been working fine for months. I need to add some capability and upgrade some things. That lead me to rpi-update.
rpi-update results:

Code: Select all

[email protected]:/home/pi# rpi-update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 13403  100 13403    0     0   111k      0 --:--:-- --:--:-- --:--:--  111k
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** We're running for the first time
 *** Backing up files (this will take a few minutes)
 *** Backing up firmware
 *** Backing up modules 4.4.13-v7+
#############################################################
This update bumps to rpi-4.14.y linux tree
Be aware there could be compatibility issues with some drivers
Discussion here:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=197689
##############################################################
 *** Downloading specific firmware revision (this will take a few minutes)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   168    0   168    0     0    744      0 --:--:-- --:--:-- --:--:--   746
100 55.8M  100 55.8M    0     0  4227k      0  0:00:13  0:00:13 --:--:-- 3808k
 *** Updating firmware
 *** Updating kernel modules
 *** depmod 4.14.48-v7+
 *** depmod 4.14.48+
 *** Updating VideoCore libraries
 *** Using HardFP libraries
 *** Updating SDK
 *** Running ldconfig
 *** Storing current firmware revision
 *** Deleting downloaded files
 *** Syncing changes to disk
 *** If no errors appeared, your firmware was successfully updated to 31eb6c5d0f7374ba8404104e60618d40f54f1e8c
 *** A reboot is needed to activate the new firmware
[email protected]:/home/pi# reboot
Finally, the issue I'm having. Once I've run rpi-update the script to turn the display back on doesn't work properly. The display comes back on, but the screen is scrambled. Colors are messed up and it appears as if the data being displayed is at a different resolution:
Image
Running this
[email protected]:/home/pi# fbset

mode "800x600"
geometry 800 600 800 600 16
timings 0 0 0 0 0 0 0
rgba 5/11,6/5,5/0,0/16
endmode

shows the correct settings.

Any help would be appreciated.

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

Re: Moving Linux kernel to 4.14

Tue Jun 12, 2018 7:24 pm

DennisT wrote:
Tue Jun 12, 2018 5:17 pm
Finally, the issue I'm having. Once I've run rpi-update the script to turn the display back on doesn't work properly. The display comes back on, but the screen is scrambled. Colors are messed up and it appears as if the data being displayed is at a different resolution:
This sounds more like a firmware than kernel issue. Can you create an issue here?
https://github.com/raspberrypi/firmware/issues

DennisT
Posts: 3
Joined: Tue Jul 05, 2016 8:45 pm

Re: Moving Linux kernel to 4.14

Wed Jun 13, 2018 4:16 pm

Thanks, I opened a issue there. It turns out the upgrade goes from a 16bpp framebuffer to a 32bpp for the console.
fbset -depth 32
should fix the problem.
However I found
vcgencmd display_power
command during my research and went with that instead.

adamreisnz
Posts: 7
Joined: Sat Sep 16, 2017 9:29 am

Re: Moving Linux kernel to 4.14

Thu Jun 14, 2018 12:09 am

I am experiencing issues with 4.14 crashing the Raspberry Pi when reading inputs from the GPIO.
The issue is documented here: https://github.com/raspberrypi/linux/issues/2550

How can I run `apt-get upgrade` on an older version of Raspbian but avoid the kernel being upgraded from 4.9 to 4.14?

drmullins
Posts: 29
Joined: Fri Jun 23, 2017 9:22 pm

Re: Moving Linux kernel to 4.14

Wed Jul 04, 2018 6:34 pm

I am having difficultly playing mp3 files over a network using VLC since upgading to kernel 4.14. A short mp3 file - 20 MB - takes a minute to start playing over my network where iperf indicates a network speed of about 80 Mbit/s.

Playback over the network using VLC starts immediately (in 1 or 2 seconds) with kernel 4.9.80.

Playback over the network also starts immediately with kernel 4.14 when using audacious or banshee

Help !

drmullins
Posts: 29
Joined: Fri Jun 23, 2017 9:22 pm

Re: Moving Linux kernel to 4.14

Wed Jul 04, 2018 8:27 pm

I just found a fix to playing files over a network with VLC

I had to specify vers=1.0 for the smb version in the samba mount (using autofs). Without this the smb version defaults to vers=2.1 (presumably) and this stops VLC from working properly !

This is quite inconvenient because one can't use the new more secure smb protocols (2.1 or 3.0) in all circumstances but this seems be an issue of compatibility between samba and VLC, rather than an issue for the foundation.

krbvroc1
Posts: 3
Joined: Tue Jul 10, 2018 12:17 am

Re: Moving Linux kernel to 4.14

Tue Jul 10, 2018 12:31 am

paul433 wrote:
Thu Mar 15, 2018 1:04 pm
Kernel 4.14.21 seemed to be really stable, 4.14.24 we started seeing these kernel panics again. Seems that we have not round the race condition that is causing the problem.
Any update / resolution / github issue on this? I found this thread because my 3B+ is fairly regularly hanging when I unplug and plug it back in (cycle power).

I am using stock kernel 4.14.34-v7+ from 2018-04-18-raspbian-stretch-lite.zip.

I have an HDMI display / USB touchscreen combo connected. When I cycle power, the red led lights, I might get a blip or two of green and then nothing. The display/touchscreen is not powered up in this failure scenario. Power cycling has been very unreliable.

I added 'dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0' mentioned in this thread and have yet to experience the problem over a few dozen power cycles.

I tried hooking a serial device to pins 6/8/10 of the J8 connector to see if I could provide more info, but I just get garbled text. (When it boot okays it is garbled until the login prompt appears - so maybe some baud issue or I am misunderstanding how to get boot output via serial).

User avatar
DougieLawson
Posts: 34168
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website

Re: Moving Linux kernel to 4.14

Tue Jul 10, 2018 6:00 am

krbvroc1 wrote:
Tue Jul 10, 2018 12:31 am
I am using stock kernel 4.14.34-v7+ from 2018-04-18-raspbian-stretch-lite.zip.
Run sudo apt update; sudo apt -y dist-upgrade and that will get to a 4.14.52 kernel that you can use to re-run your tests.
Note:The use of baseball bats for educational purposes is completely disallowed on this forum.

Any DMs sent on Twitter will be answered next month.

krbvroc1
Posts: 3
Joined: Tue Jul 10, 2018 12:17 am

Re: Moving Linux kernel to 4.14

Tue Jul 10, 2018 6:43 pm

DougieLawson wrote:
Tue Jul 10, 2018 6:00 am
krbvroc1 wrote:
Tue Jul 10, 2018 12:31 am
I am using stock kernel 4.14.34-v7+ from 2018-04-18-raspbian-stretch-lite.zip.
Run sudo apt update; sudo apt -y dist-upgrade and that will get to a 4.14.52 kernel that you can use to re-run your tests.
I am still seeing the hang with 4.14.52-v7+...but it is hard to track. It only seems to be able to reproduce when /boot/cmdline contains 'quiet'. If I remove 'quiet' I haven't seen the hang. 'quiet' doesn't show me any info as to how far or where it is hanging. The USB hasn't been given power yet since my touchscreen is not yet powered on. Putting 'dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0' back on the cmdline works everytime.

Any other debug/troubleshooting steps?

ps. my garbled serial console was due to 'splash' on cmdline - is this non-ascii data being sent to serial console?

User avatar
DougieLawson
Posts: 34168
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website

Re: Moving Linux kernel to 4.14

Tue Jul 10, 2018 8:46 pm

Once you're running a current development kernel if the problem still exists then open an issue at https://github.com/raspberrypi/linux or https://github.com/raspberrypi/firmware (if you can be sure it belongs there).
Note:The use of baseball bats for educational purposes is completely disallowed on this forum.

Any DMs sent on Twitter will be answered next month.

krbvroc1
Posts: 3
Joined: Tue Jul 10, 2018 12:17 am

Re: Moving Linux kernel to 4.14

Tue Jul 10, 2018 8:49 pm

DougieLawson wrote:
Tue Jul 10, 2018 8:46 pm
Once you're running a current development kernel if the problem still exists then open an issue at https://github.com/raspberrypi/linux or https://github.com/raspberrypi/firmware (if you can be sure it belongs there).
If 'dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0' fixes it, is that kernel or firmware?

User avatar
DougieLawson
Posts: 34168
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website

Re: Moving Linux kernel to 4.14

Tue Jul 10, 2018 9:23 pm

That's a kernel driver parameter.
Note:The use of baseball bats for educational purposes is completely disallowed on this forum.

Any DMs sent on Twitter will be answered next month.

User avatar
kozman
Posts: 15
Joined: Tue Sep 11, 2018 3:40 pm

Re: Moving Linux kernel to 4.14

Tue Sep 11, 2018 3:53 pm

Full disclosure: I'm not a Linux person.

I've been following this thread since last fall and wanted to post my experience with some of the recent 4.14 kernels. When doing an rpi-update, I've noticed that during a sudo reboot (after the kernel has been successfully updated), it will crash hard. It's usually a full-on kernel panic with all manner of gobbledygook that's scrolled a few screens worth of info. This time, after an update from 4.14.68 to 4.14..69, it actually hung on the shutdown process and there's a bit of info there which I hope might be useful to you guys for helping figure out the cause of the problem.
Attachments
error.jpg
error.jpg (199.09 KiB) Viewed 1589 times

verkerkbr
Posts: 14
Joined: Mon Sep 10, 2018 9:17 pm

Re: Moving Linux kernel to 4.14

Wed Sep 12, 2018 9:40 am

Kernels 4.14.68 and 67 gave memory leaks and locks-up with our marine navigation systems. Now with the latest version 4.14.69 these seem to be solved.

Only a small problem occurs. Piclone does no longer work well. I have to revert to kernel 4.14.62 for using the Piclone. With this kernel it works without problems. We use the Piclone very often to make backup SD cards.

We are using Raspian Stretch (with OpenPlotter additions) VC4 driver on and in the Plotter software OpenCPN OpenGL on.

Bram

verkerkbr
Posts: 14
Joined: Mon Sep 10, 2018 9:17 pm

Re: Moving Linux kernel to 4.14

Wed Sep 12, 2018 9:11 pm

After doing the latest updates, with the exception of the kernel update., system is running very well.

Kernel is now 4.14.62. No lockups. System is now running for about 4 hours.

Raspian Stretch, VC4 driver on and OpenGL in the plotter software also on.

Fast screen movement and no screen problems.We are using OpenPlotter 1.1.0 Alpha. System is an RPI 3B+

Connected to an activ USB hub with GPS mouse and AIS (automatic indentification system for shipping) receiver.

Piclone is also working without problems.

Regards,

Bram

User avatar
kozman
Posts: 15
Joined: Tue Sep 11, 2018 3:40 pm

Re: Moving Linux kernel to 4.14

Thu Sep 13, 2018 3:40 pm

verkerkbr wrote:
Wed Sep 12, 2018 9:11 pm
After doing the latest updates, with the exception of the kernel update., system is running very well.

Kernel is now 4.14.62. No lockups. System is now running for about 4 hours.

Raspian Stretch, VC4 driver on and OpenGL in the plotter software also on.

Fast screen movement and no screen problems.We are using OpenPlotter 1.1.0 Alpha. System is an RPI 3B+

Connected to an activ USB hub with GPS mouse and AIS (automatic indentification system for shipping) receiver.

Piclone is also working without problems.

Regards,

Bram
I was just looking through some of the upcoming changes to kernel 4.14.70 and there are a few ARM fixes in there so maybe it'll work better than the 4.14.63-69 series for PiClone. Did you reach out to the PiClone author about the issues?

DirkS
Posts: 9522
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

Re: Moving Linux kernel to 4.14

Thu Sep 13, 2018 4:32 pm

kozman wrote:
Thu Sep 13, 2018 3:40 pm
Did you reach out to the PiClone author about the issues?
To make that easier: https://github.com/raspberrypi-ui/piclone/issues

verkerkbr
Posts: 14
Joined: Mon Sep 10, 2018 9:17 pm

Re: Moving Linux kernel to 4.14

Thu Sep 13, 2018 7:57 pm

If it works well with kernel 4.14.62, the conclusion must be it is a kernel problem and not an Piclone issue. With the other kernel versions I also had problems with locking up of the system after some time idle. Screen errors.

If kernel 4.14.70 is available I will certainly give it a try. Piclone is important for always having back-up of the systems and nautical ENC charts on board.

Most of the time it works in one session. It it fails we have to do it a second time.

Bram

User avatar
kozman
Posts: 15
Joined: Tue Sep 11, 2018 3:40 pm

Re: Moving Linux kernel to 4.14

Thu Sep 13, 2018 8:49 pm

verkerkbr wrote:
Thu Sep 13, 2018 7:57 pm
If it works well with kernel 4.14.62, the conclusion must be it is a kernel problem and not an Piclone issue. With the other kernel versions I also had problems with locking up of the system after some time idle. Screen errors.

If kernel 4.14.70 is available I will certainly give it a try. Piclone is important for always having back-up of the systems and nautical ENC charts on board.

Most of the time it works in one session. It it fails we have to do it a second time.

Bram
If it walks and quacks like a duck, it's a duck. My unscientific hunch is maybe some of the continued Meltdown/Spectre and recent security changes backported to 4.14 kernels *could* be at fault. Who knows. From the GIT page, doesn't look like much has happened with PiClone since 2016.

Kernel 4.14.70 should probably go final in a few days and be available via rpi-update shortly after that. You could always report back when it does and see if it works with PiClone. I'd still bug the author to see if he/she could update it against newer kernels just to be sure it's not his app or bitrot.

Return to “Advanced users”