Testing 4.4 kernel

[dom]

The 4.4 kernel is interesting for a few reasons. It will have long term support (LTS).
It has a reasonable amount of upstream support for raspberry pi. With help from @notro and @pelwell we have been able to drop a lot of downstream patches and switch to using upstream code.
As part of this pruning, we have dropped non-device tree support.

We will swich to 4.4 kernel at some point in the future, but if testers want to experiment, then I've made a "next" firmware build. To update:

Code: Select all

sudo BRANCH=next rpi-update

Ideally everything will work much as before, but if you spot any regressions, then report them here.

[DougieLawson]

Does it have the PiZero OTG stuff or would I need to rebuild the kernel with some patches to re-enable that?

[DougieLawson]

I gave this a go on my Zero which uses the "official" BRCM 43143 WiFi dongle and the network was so unstable that I couldn't use an ssh session to do anything. It's been reverted to 4.1.15.

[dom]

Does it have the PiZero OTG stuff or would I need to rebuild the kernel with some patches to re-enable that?

Not yes, but when the OTG pull request is merged, this will be updated.

[dom]

I gave this a go on my Zero which uses the "official" BRCM 43143 WiFi dongle and the network was so unstable that I couldn't use an ssh session to do anything. It's been reverted to 4.1.15.

Any errors in dmesg?
Does adding "dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0" to cmdline.txt make a difference?

[DougieLawson]

Found this in a /var/log/kern.log*

Code: Select all

Dec 29 10:28:34 falcon kernel: [   13.374892] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
Dec 29 10:28:34 falcon kernel: [   14.033189] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
Dec 29 10:28:34 falcon kernel: [   14.033224] brcmfmac: brcmf_add_if: ignore IF event
Dec 29 10:28:34 falcon kernel: [   14.040536] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

It's running 4.4.0 again now with your extra cmdline parms.

[DougieLawson]

Those command line changes and sudo iwconfig wlan0 power off have worked. My zero has been stable all day.

One interesting observation (from another thread)

Code: Select all

[    0.000000] Machine model: Raspberry Pi ? Rev 1.2

something is missing in the GPU/Device Tree/Kernel for the zero.

That message is OK on my other Raspberries.

Code: Select all

[    0.000000] Machine model: Raspberry Pi Model B Plus Rev 1.2
[    0.000000] Machine model: Raspberry Pi 2 Model B Rev 1.1
[    0.000000] Machine model: Raspberry Pi Model B Rev 2
[    0.000000] Machine model: Raspberry Pi Model B Rev 2
[    0.000000] Machine model: Raspberry Pi Model B Rev 2
[    0.000000] Machine model: Raspberry Pi Model B Rev 2
[    0.000000] Machine model: Raspberry Pi Model B
[    0.000000] Machine model: Raspberry Pi Model A Plus Rev 1.1

not all are running the 4.4.0-rc7 kernel yet. I've got 5 out of 9 running with the experimental kernel.

[dom]

Those command line changes and sudo iwconfig wlan0 power off have worked. My zero has been stable all day.

You have made two changes to make it stable. Are you sure both are required?

[DougieLawson]

Those command line changes and sudo iwconfig wlan0 power off have worked. My zero has been stable all day.

You have made two changes to make it stable. Are you sure both are required?

I was doing the iwconfig stuff on 4.1.15 to stop the network dying through boredom. I'm fairly sure the cmdline.txt change is the thing that has stopped it breaking.

[dom]

I'm fairly sure the cmdline.txt change is the thing that has stopped it breaking.

Being certain would be useful to know.

[DougieLawson]

I'm fairly sure the cmdline.txt change is the thing that has stopped it breaking.

Being certain would be useful to know.

I'm not sure now. I did battle with my zero yesterday and ended up reverting to 4.1.15 to get it running as a stable system. I'll need to grab a new microSD card and try a proper series of tests because there were a couple of times when it simply wouldn't boot.

[DougieLawson]

I did another test with the extra kernel parms this morning.

Code: Select all

Jan  7 02:09:31 falcon kernel: [  539.393695] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jan  7 02:09:43 falcon kernel: [  550.921770] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Jan  7 02:10:10 falcon kernel: [  578.215301] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jan  7 02:10:10 falcon kernel: [  578.232823] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
Jan  7 02:10:10 falcon kernel: [  578.232880] cfg80211: World regulatory domain updated:
Jan  7 02:10:10 falcon kernel: [  578.232893] cfg80211:  DFS Master region: unset

The WiFi comes up active, then 27 seconds later silently dies. Back to 4.1.15+ again.

[dom]

I did another test with the extra kernel parms this morning

Can you be explicit with what does and does not work?

Does disabling the fiq and "sudo iwconfig wlan0 power off" work reliably on 4.4? Does just disbling the fiq? Does just "sudo iwconfig wlan0 power off"?

[DougieLawson]

Hostname: Falcon
Kernel: 4.4.0-rc7+ #831 complete with Phil's small firmware change from yesterday
Hardware: RPi 0, Broadcom WiFi dongle brcm43134, Toshiba TV, IBM Keyboard, Wireless mouse
Network: IPv4 (10.1.1.0/24 subnet) with a IPv6 tunnel (using 2001:xxxx:xxxx:xxxx/64 prefix from HE.com)
OS: Jessie updated yesterday with apt-get update && apt-get -y dist-upgrade
Broadcom firmware: https://wireless.wiki.kernel.org/en/use ... /brcm80211

Network comes up and connects then dies.
Restarting it with
ifup --force wlan0
ip route add default via 10.1.1.138
runs for a short while then dies.

Adding

Code: Select all

iwconfig wlan0 power off

to /etc/rc.local makes no difference

Adding

Code: Select all

dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0

to cmdline.txt makes no difference. Full command line is

Code: Select all

dwc_otg.lpm_enable=0 dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Reverting to 4.1.15+ #830 by copying /boot from a backup (old command line), everything else the same and the network runs rock solid, stable. I've even run rpi-update on the 4.1.15+ stuff to get Phil's small firmware changes again.

Config.txt (for serial 0xebd5f1e8) is

Code: Select all

#
# Unified config.txt @ 03/01/2016 22:39
#

[0x5a67d427]
# ** Eagle      : 5a67d427 **
disable_camera_led=1
#kernel=kernel7.4.1.15-v7+.img.830
kernel=kernel7.4.4.0-rc7-v7+.img.831
dtoverlay=i2c-rtc,ds1307
max_usb_current=1

[0x5b592f7f]
# ** Aplus      : 5b592f7f **
gpu_mem=16

[0x9b930691]
# ** Raspberry  : 9b930691 **
dtoverlay=rpi-cirrus-wm5102-overlay
kernel=kernel.3.18.9W+.img

[0xc2355259]
# ** Odyssey    : c2355259 **
dtoverlay=lirc-rpi,gpio_in_pin=23,gpio_in_pull=high
gpu_mem=128
start_x=1

[0xe685c936]
# ** Apollo     : e685c936 **
dtoverlay=i2c-rtc,ds1307
gpu_mem=16
initramfs initrd.sda followkernel
max_usb_current=1

[0xebd5f1e8]
# ** Falcon     : ebd5f1e8 **
#dtoverlay=enc28j60,int_pin=25,speed=20000000
gpu_mem=64
dtparam=act_led_activelow=on
#kernel=kernel.4.1.15+.img.830

#[0x4800069e]
# ** Pi         : 4800069e **

#[0x62144670]
# ** Saturn     : 62144670 **

#[0x3dfffed]
# ** Raspberrypi: 3d5fffed **

[all]
dtoverlay=sdhost
dtparam=i2c=on,spi=on

yes, I am one of those loonies using the serial number stanzas in my config.txt.

[dom]

Upstream 4.4 kernel went stable today and rpi-update firmware has been updated.

[AndyD]

Hi Dom, I have been testing the 4.4 kernel on a number of Raspberry Pi Models. When I tried the games released by webfoot on a Raspberry Pi Model 2 the Raspberry Pi hung solid. I reverted to the Master branch of the firmware and the problem was resolved. I will attempt to confirm this over the weekend.

[dom]

Hi Dom, I have been testing the 4.4 kernel on a number of Raspberry Pi Models. When I tried the games released by webfoot on a Raspberry Pi Model 2 the Raspberry Pi hung solid. I reverted to the Master branch of the firmware and the problem was resolved. I will attempt to confirm this over the weekend.

Just tried 3D Frog Frenzy on 4.4 kernel with no issues.
Make sure you have gpu_mem=256 and see if you can reproduce.
If you are overclocking then disable that for this test.

[joan]

4.4.0+ #834

There may be a problem with I2C.

If I have dtparam=i2c_arm=on and dtparam=i2c_vc=on in /boot/config.txt only bus 0 appears (no /dev/i2c-1, no response to i2cdetect).

If I comment out dtparam=i2c_vc=on bus 1 appears.

[DougieLawson]

4.4.0+ #834

There may be a problem with I2C.

If I have dtparam=i2c_arm=on and dtparam=i2c_vc=on in /boot/config.txt only bus 0 appears (no /dev/i2c-1, no response to i2cdetect).

If I comment out dtparam=i2c_vc=on bus 1 appears.

I've just tested a model B running 4.4.0+ #834 with

Code: Select all

dtparam=i2c=on,spi=on
dtparam=i2c_vc=on

and get the same failure.

[joan]

4.4.0+ #834

There may be a problem with I2C.

If I have dtparam=i2c_arm=on and dtparam=i2c_vc=on in /boot/config.txt only bus 0 appears (no /dev/i2c-1, no response to i2cdetect).

If I comment out dtparam=i2c_vc=on bus 1 appears.

I've just tested a model B running 4.4.0+ #834 with

Code: Select all

dtparam=i2c=on,spi=on
dtparam=i2c_vc=on

and get the same failure.

I have tried on a B+ and a Pi Zero with the same response.

Whichever order I use for dtparam=i2c_arm=on and dtparam=i2c_vc=on only bus 0 is created.

[AndyD]

Just tried 3D Frog Frenzy on 4.4 kernel with no issues.
Make sure you have gpu_mem=256 and see if you can reproduce.
If you are overclocking then disable that for this test.

Thanks for looking Dom. Yes, I had gpu_mem=256 and no I don't overclock. The only thing non-standard about my Pi2 is that it has a TFT display attached and runs a system monitor daemon that displays on the TFT. I have confirmed the behaviour by going back to the next branch. To correct the original post, the Raspberry Pi is not completely hung, I can SSH into it, but the console terminal hangs completely. I will do some more tests to see if I can isolate the problem.

[AndyD]

Thanks for looking Dom. Yes, I had gpu_mem=256 and no I don't overclock. The only thing non-standard about my Pi2 is that it has a TFT display attached and runs a system monitor daemon that displays on the TFT. I have confirmed the behaviour by going back to the next branch. To correct the original post, the Raspberry Pi is not completely hung, I can SSH into it, but the console terminal hangs completely. I will do some more tests to see if I can isolate the problem.

Digging in to the problem a little further, it appears that when I use the 4.4 Kernel there is no alsa device.

Code: Select all

AL lib: (EE) alsa_open_playback: Could not open playback device 'default': No such file or directory

I have confirmed the same behaviour on both a Pi2 and Model B rev 2. They are connected to a 1920x1080 LCD TV using an HDMI cable. Let me know if you want any more details.

[DougieLawson]

Have you got

Code: Select all

snd-bcm2835

in /etc/modules?

[DirkS]

Have you got

Code: Select all

snd-bcm2835

in /etc/modules?

Isn't

Code: Select all

dtparam=audio

in config.txt the 'modern' way of getting the module loaded?

[AndyD]

Have you got

Code: Select all

snd-bcm2835

in /etc/modules?

Isn't

Code: Select all

dtparam=audio

in config.txt the 'modern' way of getting the module loaded?

Yes, that is it, but why is the behaviour different between 4.1.16/master and 4.4.0/next?

In overlay/README it says

Code: Select all

audio  Set to "on" to enable the onboard ALSA audio interface (default "off")

But, this doesn't appear to be the case until 4.4.0/next. Also, there is no option in raspi-config to enable onboard ALSA audio.