Moving Linux kernel to 4.19 [Already moved for many months now (in january 2020)]

[kozman]

don't know does it call firmware or not? but saw it in github

Not really sure what you are saying. That shows the kernel and modules are at 4.19.23.
If you want to test it follow instructions in first post of this thread or you can wait until it reaches apt/raspbian later.

He's correct since at least yesterday. Not everything is up to 4.19.23. There are many things at (https://github.com/Hexxeh/rpi-firmware) still showing level at 4.14.94 or .98.

[dom]

He's correct since at least yesterday. Not everything is up to 4.19.23. There are many things at (https://github.com/Hexxeh/rpi-firmware) still showing level at 4.14.94 or .98.

The kernel update doesn't directly affect firmware or opt/vc libs. So those files will show the last update commit of when they were last updated.
Some files are seven years old because they haven't changed since day one. Doesn't mean anything is wrong.

[kozman]

He's correct since at least yesterday. Not everything is up to 4.19.23. There are many things at (https://github.com/Hexxeh/rpi-firmware) still showing level at 4.14.94 or .98.

The kernel update doesn't directly affect firmware or opt/vc libs. So those files will show the last update commit of when they were last updated.
Some files are seven years old because they haven't changed since day one. Doesn't mean anything is wrong.

Didn't know that. Thanks for clearing it up.

[dom]

one has to remember to uncomment the fake driver with #dtoverlay=vc4-fkms-v3d in /boot/config.txt to avoid the hang

Latest rpi-update kernel should fix the hang when vc4-fkms is enabled. Fix from here.

[dariuszb]

With external disk attached when upgraded to 4.19 e4defrag commands kills the system:

Code: Select all

[ 1192.086591] e4defrag invoked oom-killer: gfp_mask=0x6000d0(GFP_KERNEL|__GFP_RECLAIMABLE), nodemask=(null), order=0, oom_score_adj=0
[ 1192.086604] e4defrag cpuset=/ mems_allowed=0
[ 1192.086630] CPU: 2 PID: 2149 Comm: e4defrag Tainted: G         C O      4.19.23-v7+ #1203
[ 1192.086634] Hardware name: BCM2835
[ 1192.086668] [<80111ea8>] (unwind_backtrace) from [<8010d440>] (show_stack+0x20/0x24)
[ 1192.086685] [<8010d440>] (show_stack) from [<8080c880>] (dump_stack+0xd4/0x118)
[ 1192.086703] [<8080c880>] (dump_stack) from [<8023a7f0>] (dump_header+0x80/0x250)
[ 1192.086718] [<8023a7f0>] (dump_header) from [<80239b68>] (oom_kill_process+0x358/0x3a8)
[ 1192.086731] [<80239b68>] (oom_kill_process) from [<8023a498>] (out_of_memory+0x134/0x36c)
[ 1192.086746] [<8023a498>] (out_of_memory) from [<802408c0>] (__alloc_pages_nodemask+0x1024/0x1178)
[ 1192.086762] [<802408c0>] (__alloc_pages_nodemask) from [<802901d0>] (new_slab+0x520/0x6b4)
[ 1192.086775] [<802901d0>] (new_slab) from [<80292190>] (___slab_alloc.constprop.11+0x454/0x594)
[ 1192.086788] [<80292190>] (___slab_alloc.constprop.11) from [<80292314>] (__slab_alloc.constprop.10+0x44/0x90)
[ 1192.086801] [<80292314>] (__slab_alloc.constprop.10) from [<80292ae0>] (kmem_cache_alloc+0x20c/0x23c)
[ 1192.086815] [<80292ae0>] (kmem_cache_alloc) from [<802c3450>] (__d_alloc+0x34/0x1f0)
[ 1192.086830] [<802c3450>] (__d_alloc) from [<802c362c>] (d_alloc+0x20/0x88)
[ 1192.086843] [<802c362c>] (d_alloc) from [<802c3ab0>] (d_alloc_parallel+0x68/0x500)
[ 1192.086858] [<802c3ab0>] (d_alloc_parallel) from [<802b3fdc>] (__lookup_slow+0x6c/0x174)
[ 1192.086873] [<802b3fdc>] (__lookup_slow) from [<802b4124>] (lookup_slow+0x40/0x54)
[ 1192.086885] [<802b4124>] (lookup_slow) from [<802b6f08>] (walk_component+0x1f8/0x2f8)
[ 1192.086896] [<802b6f08>] (walk_component) from [<802b75b4>] (path_lookupat+0x78/0x214)
[ 1192.086908] [<802b75b4>] (path_lookupat) from [<802b90d4>] (filename_lookup+0xac/0x11c)
[ 1192.086919] [<802b90d4>] (filename_lookup) from [<802b9254>] (user_path_at_empty+0x50/0x58)
[ 1192.086931] [<802b9254>] (user_path_at_empty) from [<802ad820>] (vfs_statx+0x7c/0xe8)
[ 1192.086944] [<802ad820>] (vfs_statx) from [<802ae444>] (sys_fstatat64+0x40/0x70)
[ 1192.086958] [<802ae444>] (sys_fstatat64) from [<80101000>] (ret_fast_syscall+0x0/0x28)
[ 1192.086963] Exception stack(0xa604bfa8 to 0xa604bff0)
[ 1192.086974] bfa0:                   7e9b3388 7e9b1024 00000007 01cd7f8b 7e9b0f78 00000100
[ 1192.086984] bfc0: 7e9b3388 7e9b1024 7e9b0f78 00000147 7e9b3388 7e9b3388 7e9b33c0 7e9b344c
[ 1192.086991] bfe0: 0000001c 7e9b0f58 76e78288 76e74cc0
[ 1192.086997] Mem-Info:
[ 1192.087017] active_anon:13885 inactive_anon:2626 isolated_anon:0
[ 1192.087017]  active_file:369 inactive_file:448 isolated_file:0
[ 1192.087017]  unevictable:438 dirty:0 writeback:0 unstable:0
[ 1192.087017]  slab_reclaimable:211896 slab_unreclaimable:9973
[ 1192.087017]  mapped:1277 shmem:2670 pagetables:608 bounce:0

It has been working perfectly for years including kernel 4.14.98. External disk has fair amount of files - 2GB in total, 2.5 million files.

[dariuszb]

After upgrading to 4.19 system sometimes hangs during soft reboot (it looks like it goes down but then hangs during start). I think I identified what is causing it in my setup. I tested it with multiple Raspberry Pi 2 and 3 with various setup (LAN, wifi, USB devices). Results are always the same.

In my configuration I try to keep stuff in memory in order to limit SD card wear (i run remote systems I don't really want to have to travel to change SD card).

So I have in my /etc/fstab

tmpfs /var/log tmpfs size=100M 0 0
tmpfs /tmp tmpfs size=100M 0 0
tmpfs /var/tmp tmpfs size=100M 0 0

I used this for years without any issues. Now with 4.19 systems sometimes fail to soft reboot so I commented /var/log in fstab to capture logs on SD card. And surprisingly now it reboots 100% times without any issues. When I move /var/log to tmpfs again it hangs very often on soft reboot. Hard reboot brings system to life.

[dom]

With external disk attached when upgraded to 4.19 e4defrag commands kills the system:

Seems to be an out of memory condition. Were you running other apps (e.g. browser)?
Does it work when gpu_mem=16 is set in config.txt which gives the arm a bit more memory?

[Muximize]

My 3B+ isn't happy. The WiFi network is very flaky.

Code: Select all

...
[    7.835263] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    7.914576] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    7.917373] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[    7.917395] cfg80211: failed to load regulatory.db
...

That one is going back to 4.14.79-v7+

EDIT: I'm getting the same kind of failure on my 3A+ Raspberries.

The reason WiFi is flaky could be the missing regulatory db. Linux 4.15 changed the way this works:
https://kernelnewbies.org/Linux_4.15#line-251

If you put regulatory.db and regulatory.db.p7s in /lib/firmware, those errors in dmesg should disappear. You can find these files here:
https://git.kernel.org/pub/scm/linux/ke ... .git/tree/

I believe this should be added to Raspbian by default. Here's how Alpine Linux solved it:
https://git.alpinelinux.org/aports/comm ... 5ffb88e69e (more info: https://bugs.alpinelinux.org/issues/9549)

But the wireless-regdb package in Raspbian seems to only have the older files, an doesn't put anything in /lib/firmware

[dariuszb]

With external disk attached when upgraded to 4.19 e4defrag commands kills the system:

Seems to be an out of memory condition. Were you running other apps (e.g. browser)?
Does it work when gpu_mem=16 is set in config.txt which gives the arm a bit more memory?

I run it headless with all UI software removed. And yes gpu_mem=16 is set. I spent some time optimizing my configuration and it performs perfectly. It acts as samba files and openvpn server. Only now with 4.19 I have issues. At the moment I rolled back to 4.14.

[MallocArray]

I believe lirc_rpi is no longer recommended and gpio-ir should be used instead. Some info here:
https://www.raspberrypi.org/forums/view ... p?t=205415

Thank you for this. I was really confused when my /dev/lirc0 disappeared after upgrading. Switching to gpio-ir and gpio-ir-tx got me somewhat back, but now I have /dev/lirc0 and /dev/lirc1 which results in me needing to make additional configuration changes to my lirc setup to support both receiving and sending. But at least I know where to go from here now

Code: Select all

dtoverlay=gpio-ir,gpio_pin=23
dtoverlay=gpio-ir-tx,gpio_pin=22

[tonyhain]

So I got here without intent, but the complete failure of the wifi on 4.19 doesn't appear to be discussed. That may be due to everyone on the list knowing not to try. Either way, it is unusable.

Started from the Stratux distribution 4.9 (stock raspbian with hostapd and dump1090 preinstalled) with a stable system until I turned on wpa. At that point there were intermittent failures where hostapd would completely lose track of wlan0. Discussion on https://github.com/raspberrypi/linux/issues/2453 suggested this might be resolved by rebinding the device. Nothing happened when I tried it on 4.9, so I thought 'apt update' would get me to current stable. Clearly from other threads about 'apt update' the managers of the process would rather tell people how stupid they are for doing the obvious than to have the obvious action do something safe. Rather than having update with no hash take you to the most current, it would appear to be safer for the masses if that took you to a designated stable build. One could argue that the developers are on one hand lazy for not wanting to put the hash in for development builds, but on the other hand overworked for having to constantly tell people they are stupid for not knowing how the update process works.

In any case, instead of 4.14 I find the pi is running 4.19. searching for 4.19 wifi errors led me to this discussion. It would appear there are several issues, and since I don't know what is supposed to happen, all I can do is provide what I did and what happened in case that helps someone figure out how to resolve it. I scripted the sequence described in the github discussion above, annotated the steps, and extracted relevant lines from dmesg. While developing the script I occasionally found that the softlink at /sys/bus/platform/drivers/mmc-bcm2835/3f300000.mmc would disappear. It happened often enough that I put in a test to recreate it when it disappeared, but not often enough that I could nail down which step immediately preceded the disappearance.

20190224075700 Initial dmesg for mmc-bcm & mmc1

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.19.23-v7+ (dom@dom-XPS-13-9370) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1203 SMP Tue Feb 19 23:26:17 GMT 2019
[ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Raspberry Pi 3 Model B Rev 1.2
...
[ 0.852607] mmc-bcm2835 3f300000.mmc: could not get clk, deferring probe
[ 0.931365] mmc-bcm2835 3f300000.mmc: mmc_debug:0 mmc_debug2:0
[ 0.934522] mmc-bcm2835 3f300000.mmc: DMA channel allocated
...
[ 1.002919] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 1.007508] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 1.012005] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 1.040034] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 1.214074] mmc1: new high speed SDIO card at address 0001
...
[ 3.945418] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[ 3.951256] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 3.951518] usbcore: registered new interface driver brcmfmac
[ 4.105711] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 4.105836] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 4.106567] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Aug 7 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[ 4.916863] brcmfmac: power management disabled
[ 4.975081] brcmfmac: power management disabled

20190224075700 Attempting to reset using modprobe -r brcmfmac
20190224075707 modprobe reset failed with

[ 4104.307178] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 4104.310263] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 4104.310415] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 4104.310426] cfg80211: failed to load regulatory.db
[ 4104.346179] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[ 4104.359302] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 4104.359620] usbcore: registered new interface driver brcmfmac
[ 4104.470701] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 4104.470783] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 4104.471501] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Aug 7 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[ 4104.594024] brcmfmac: power management disabled
[ 4104.681012] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 4104.681032] brcmfmac: power management disabled

20190224075707 trying harder by unbinding 3f300000.mmc
echo -n 3f300000.mmc > /sys/devices/platform/soc/3f300000.mmc/driver/unbind
20190224075710 Unbind result:

[ 4110.150699] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[ 4110.150851] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[ 4110.163363] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[ 4110.163377] brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-5)
[ 4110.393406] mmc1: card 0001 removed
[ 4110.396243] ------------[ cut here ]------------
[ 4110.396284] WARNING: CPU: 3 PID: 1089 at kernel/irq/manage.c:1597 __free_irq+0xc4/0x314
[ 4110.396296] Trying to free already-free IRQ 86
[ 4110.396305] Modules linked in: brcmfmac brcmutil cfg80211 rfkill binfmt_misc ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter ip_tables x_tables cdc_acm sha256_generic bcm2835_codec(C) bcm2835_v4l2(C) v4l2_mem2mem bcm2835_mmal_vchiq(C) v4l2_common snd_bcm2835(C) videobuf2_dma_contig videobuf2_vmalloc snd_pcm videobuf2_memops videobuf2_v4l2 snd_timer videobuf2_common snd raspberrypi_hwmon joydev videodev hwmon media i2c_bcm2835 vc_sm_cma(C) evdev fixed rpi_ft5406 uio_pdrv_genirq rpi_backlight uio i2c_dev i2c_bcm2708 ipv6 [last unloaded: brcmutil]
[ 4110.396556] CPU: 3 PID: 1089 Comm: reset_wlan0 Tainted: G C 4.19.23-v7+ #1203
[ 4110.396560] Hardware name: BCM2835
[ 4110.396595] [<80111ea8>] (unwind_backtrace) from [<8010d440>] (show_stack+0x20/0x24)
[ 4110.396616] [<8010d440>] (show_stack) from [<8080c880>] (dump_stack+0xd4/0x118)
[ 4110.396636] [<8080c880>] (dump_stack) from [<8012092c>] (__warn+0x104/0x11c)
[ 4110.396652] [<8012092c>] (__warn) from [<8012099c>] (warn_slowpath_fmt+0x58/0x74)
[ 4110.396667] [<8012099c>] (warn_slowpath_fmt) from [<80180470>] (__free_irq+0xc4/0x314)
[ 4110.396682] [<80180470>] (__free_irq) from [<80180758>] (free_irq+0x48/0x90)
[ 4110.396697] [<80180758>] (free_irq) from [<80184928>] (devm_irq_release+0x1c/0x20)
[ 4110.396717] [<80184928>] (devm_irq_release) from [<805a35a4>] (release_nodes+0x190/0x20c)
[ 4110.396736] [<805a35a4>] (release_nodes) from [<805a40f8>] (devres_release_all+0x40/0x5c)
[ 4110.396755] [<805a40f8>] (devres_release_all) from [<805a0408>] (device_release_driver_internal+0x1a0/0x228)
[ 4110.396771] [<805a0408>] (device_release_driver_internal) from [<805a04b0>] (device_release_driver+0x20/0x24)
[ 4110.396785] [<805a04b0>] (device_release_driver) from [<8059e2d8>] (unbind_store+0x90/0x130)
[ 4110.396799] [<8059e2d8>] (unbind_store) from [<8059d744>] (drv_attr_store+0x30/0x3c)
[ 4110.396817] [<8059d744>] (drv_attr_store) from [<8032fd24>] (sysfs_kf_write+0x54/0x58)
[ 4110.396837] [<8032fd24>] (sysfs_kf_write) from [<8032f358>] (kernfs_fop_write+0xdc/0x1c4)
[ 4110.396874] [<8032f358>] (kernfs_fop_write) from [<802a872c>] (__vfs_write+0x48/0x170)
[ 4110.396898] [<802a872c>] (__vfs_write) from [<802a8a1c>] (vfs_write+0xb4/0x1bc)
[ 4110.396916] [<802a8a1c>] (vfs_write) from [<802a8cb4>] (ksys_write+0x64/0xcc)
[ 4110.396933] [<802a8cb4>] (ksys_write) from [<802a8d34>] (sys_write+0x18/0x1c)
[ 4110.396951] [<802a8d34>] (sys_write) from [<80101000>] (ret_fast_syscall+0x0/0x28)
[ 4110.396958] Exception stack(0xb65fffa8 to 0xb65ffff0)
[ 4110.396970] ffa0: 0127e4e0 0000000c 00000001 0127e4e0 0000000c 0044d874
[ 4110.396982] ffc0: 0127e4e0 0000000c 00000001 00000004 0000000c 00000000 01280e5c 7e956284
[ 4110.396991] ffe0: 00000000 7e956064 0044c9dc 76ebc89c
[ 4110.397000] ---[ end trace 6aff3025503a4bce ]---

echo -n 3f300000.mmc > /sys/bus/platform/drivers/mmc-bcm2835/bind
20190224075715 Rebind result:
20190224075715 Failed status:

[ 4112.508595] mmc-bcm2835 3f300000.mmc: mmc_debug:0 mmc_debug2:0
[ 4112.508609] mmc-bcm2835 3f300000.mmc: DMA channel allocated
[ 4112.563614] mmc1: queuing unknown CIS tuple 0x41 (4 bytes)
[ 4112.565866] mmc1: queuing unknown CIS tuple 0x04 (0 bytes)
[ 4112.566512] mmc1: bad CIS tuple 0x20 (0 bytes)
[ 4112.566528] mmc1: error -22 whilst initialising SDIO card
[ 4112.613413] mmc1: queuing unknown CIS tuple 0x41 (4 bytes)
[ 4112.616267] mmc1: queuing unknown CIS tuple 0x04 (0 bytes)
[ 4112.617088] mmc1: bad CIS tuple 0x20 (0 bytes)
[ 4112.617105] mmc1: error -22 whilst initialising SDIO card
[ 4112.672708] mmc1: queuing unknown CIS tuple 0x41 (4 bytes)
[ 4112.676910] mmc1: queuing unknown CIS tuple 0x04 (0 bytes)
[ 4112.678094] mmc1: bad CIS tuple 0x20 (0 bytes)
[ 4112.678112] mmc1: error -22 whilst initialising SDIO card
[ 4112.747197] mmc1: queuing unknown CIS tuple 0x41 (4 bytes)
[ 4112.755416] mmc1: queuing unknown CIS tuple 0x04 (0 bytes)
[ 4112.757713] mmc1: bad CIS tuple 0x20 (0 bytes)
[ 4112.757735] mmc1: error -22 whilst initialising SDIO card


Either the development team is using Rpi's without built-in wifi, or they know not to try, because this should have been exposed long before now if the 4.19 release effort has been active since October. Again, it was not my intent to move to the bleeding edge, but since I am here, hopefully this feedback will help in tracking down the problem. If there are other steps to try or feedback to provide, I will gladly help until I need to put that machine back on a usable build.

[Muximize]

Can you try putting regulatory.db and regulatory.db.p7s in /lib/firmware? See my post a bit earlier for details.

[tonyhain]

I saw that post but couldn't tell if the lack of those files was by intent by the way it was worded at the end. I had looked around on the system to see if they were put somewhere else like wireless-regdb. Unfortunately it appears that /usr/share/doc/wireless-regdb only contains a changelog and copyright notice.

It didn't help:
[41618.997118] usbcore: deregistering interface driver brcmfmac
[41620.260195] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[41620.263382] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[41620.263703] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
[41620.295453] usbcore: registered new interface driver brcmfmac

All I did was a wget on those 2 files, so that may not have been the correct way to acquire them.

[tonyhain]

I had tried to git clone the tree path in your initial note, but that failed so I used wget. After the failure I went back to the link and up to find a valid clone path
git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git
after putting those files in place, the brcmfmac regdb error went away ...


20190224215249 Attempting to reset using modprobe -r brcmfmac
[ 750.073357] usbcore: deregistering interface driver brcmfmac
[ 751.478502] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 751.481305] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 751.516061] usbcore: registered new interface driver brcmfmac

20190224215255 modprobe reset failed with Force_fail
20190224215255 trying harder by unbinding 3f300000.mmc
20190224215257 Unbind result:

[ 756.680973] ------------[ cut here ]------------
[ 756.681007] WARNING: CPU: 3 PID: 1381 at kernel/irq/manage.c:1597 __free_irq+0xc4/0x314
[ 756.681014] Trying to free already-free IRQ 86
[ 756.681020] Modules linked in: brcmfmac brcmutil cfg80211 rfkill ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter ip_tables x_tables cdc_acm joydev sha256_generic raspberrypi_hwmon hwmon snd_bcm2835(C) bcm2835_codec(C) bcm2835_v4l2(C) snd_pcm v4l2_mem2mem v4l2_common bcm2835_mmal_vchiq(C) videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 snd_timer videobuf2_common snd i2c_bcm2835 videodev media vc_sm_cma(C) evdev rpi_ft5406 uio_pdrv_genirq rpi_backlight uio fixed i2c_dev i2c_bcm2708 ipv6 [last unloaded: brcmutil]
[ 756.681251] CPU: 3 PID: 1381 Comm: reset_wlan0 Tainted: G WC 4.19.23-v7+ #1203
[ 756.681256] Hardware name: BCM2835
[ 756.681284] [<80111ea8>] (unwind_backtrace) from [<8010d440>] (show_stack+0x20/0x24)
[ 756.681304] [<8010d440>] (show_stack) from [<8080c880>] (dump_stack+0xd4/0x118)
[ 756.681323] [<8080c880>] (dump_stack) from [<8012092c>] (__warn+0x104/0x11c)
[ 756.681339] [<8012092c>] (__warn) from [<8012099c>] (warn_slowpath_fmt+0x58/0x74)
[ 756.681354] [<8012099c>] (warn_slowpath_fmt) from [<80180470>] (__free_irq+0xc4/0x314)
[ 756.681369] [<80180470>] (__free_irq) from [<80180758>] (free_irq+0x48/0x90)
[ 756.681383] [<80180758>] (free_irq) from [<80184928>] (devm_irq_release+0x1c/0x20)
[ 756.681402] [<80184928>] (devm_irq_release) from [<805a35a4>] (release_nodes+0x190/0x20c)
[ 756.681420] [<805a35a4>] (release_nodes) from [<805a40f8>] (devres_release_all+0x40/0x5c)
[ 756.681438] [<805a40f8>] (devres_release_all) from [<805a0408>] (device_release_driver_internal+0x1a0/0x228)
[ 756.681453] [<805a0408>] (device_release_driver_internal) from [<805a04b0>] (device_release_driver+0x20/0x24)
[ 756.681467] [<805a04b0>] (device_release_driver) from [<8059e2d8>] (unbind_store+0x90/0x130)
[ 756.681481] [<8059e2d8>] (unbind_store) from [<8059d744>] (drv_attr_store+0x30/0x3c)
[ 756.681497] [<8059d744>] (drv_attr_store) from [<8032fd24>] (sysfs_kf_write+0x54/0x58)
[ 756.681522] [<8032fd24>] (sysfs_kf_write) from [<8032f358>] (kernfs_fop_write+0xdc/0x1c4)
[ 756.681545] [<8032f358>] (kernfs_fop_write) from [<802a872c>] (__vfs_write+0x48/0x170)
[ 756.681565] [<802a872c>] (__vfs_write) from [<802a8a1c>] (vfs_write+0xb4/0x1bc)
[ 756.681581] [<802a8a1c>] (vfs_write) from [<802a8cb4>] (ksys_write+0x64/0xcc)
[ 756.681598] [<802a8cb4>] (ksys_write) from [<802a8d34>] (sys_write+0x18/0x1c)
[ 756.681615] [<802a8d34>] (sys_write) from [<80101000>] (ret_fast_syscall+0x0/0x28)
[ 756.681622] Exception stack(0xb0c67fa8 to 0xb0c67ff0)
[ 756.681636] 7fa0: 01eca690 0000000c 00000001 01eca690 0000000c 00491874
[ 756.681651] 7fc0: 01eca690 0000000c 00000001 00000004 0000000c 00000000 01ecd7c4 7eb01254
[ 756.681675] 7fe0: 00000000 7eb01034 004909dc 76e7489c
[ 756.681688] ---[ end trace f324ee52a5a42456 ]---

20190224215303 Rebind result:
20190224215303 Failed status:

[ 758.815938] mmc-bcm2835 3f300000.mmc: mmc_debug:0 mmc_debug2:0
[ 758.815951] mmc-bcm2835 3f300000.mmc: DMA channel allocated
[ 758.873631] mmc1: queuing unknown CIS tuple 0x41 (64 bytes)
[ 758.895147] mmc1: queuing unknown CIS tuple 0xdb (66 bytes)
[ 758.898939] mmc1: queuing unknown CIS tuple 0x65 (10 bytes)
[ 758.923230] mmc1: queuing unknown CIS tuple 0x04 (69 bytes)
[ 758.932790] mmc1: queuing unknown CIS tuple 0x49 (28 bytes)
[ 758.937888] mmc1: queuing unknown CIS tuple 0x69 (14 bytes)
[ 758.943430] mmc1: queuing unknown CIS tuple 0x13 (15 bytes)
[ 758.944088] mmc1: queuing unknown CIS tuple 0x83 (0 bytes)
[ 758.972276] mmc1: queuing unknown CIS tuple 0x28 (86 bytes)
[ 759.010908] mmc1: queuing unknown CIS tuple 0x8c (120 bytes)


but the interface still unrecognized suggesting that a driver is not loading.
# iw phy
# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.
# ifconfig wlan0
wlan0: error fetching interface information: Device not found

[tonyhain]

Ok, so a power cycle after putting the regdb files in place appears to have had more impact than multiple shutdown -r efforts did.
# iw wlan0 info
Interface wlan0
ifindex 3
wdev 0x1
addr b8:27:eb:80:a2:f7
type managed
wiphy 0
channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
# iw wlan0 scan | grep SSID
SSID: xfinitywifi
SSID: HAIN

Unfortunately hostapd still fails:

hostapd /tmp/hostapd.conf
Configuration file: /tmp/hostapd.conf
nl80211: Could not configure driver mode
nl80211 driver initialization failed.
hostapd_free_hapd_data: Interface wlan0 wasn't started

# cat /tmp/hostapd.conf
ssid=stratux
channel=4

auth_algs=1
wpa=3
wpa_passphrase=Squawk123
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

interface=wlan0
hw_mode=g
wmm_enabled=1
ieee80211n=1
ignore_broadcast_ssid=0


Again, this was working fine until I added the WPA component, and even then it was working with intermittent loss of the wlan0 interface. With 4.19 it appears that beyond the missing files there is a driver difference that doesn't allow AP mode.

[cjan]

want to block v4l2, which module(s)?

[6by9]

want to block v4l2, which module(s)?

Any particular reason why? Both sit there taking near zero resources if not used.
bcm2835-v4l2 for the camera
bcm2835-codec for the codecs.

[lowflyer]

I couldn't get hostapd running after rpi-update to 4.19.25-v7+.

What I did:
Start with fresh 2018-11-13-raspbian-stretch-lite on a 3B Revision a02082.
sudo apt update
sudo apt upgrade
Set up bridged WiFi AP using https://www.raspberrypi.org/documentati ... et-sharing
reboot and check the AP works.

Then do:
sudo rpi-update
reboot but no AP. Starting hostapd from console gives

Code: Select all

random: Trying to read entropy from /dev/random
Configuration file: /etc/hostapd/hostapd.conf
rfkill: initial event: idx=0 type=1 op=0 soft=0 hard=0
rfkill: initial event: idx=1 type=2 op=0 soft=0 hard=0
nl80211: Using driver-based roaming
nl80211: Supported cipher 00-0f-ac:1
nl80211: Supported cipher 00-0f-ac:5
nl80211: Supported cipher 00-0f-ac:2
nl80211: Supported cipher 00-0f-ac:4
nl80211: Using driver-based off-channel TX
nl80211: Supported vendor command: vendor_id=0x1018 subcmd=1
nl80211: Use separate P2P group interface (driver advertised support)
nl80211: Enable multi-channel concurrent (driver advertised support)
nl80211: use P2P_DEVICE support
nl80211: Disable use_monitor with device_ap_sme since no monitor mode support detected
nl80211: interface wlan0 in phy phy0
nl80211: Set mode ifindex 3 iftype 3 (AP)
nl80211: Setup AP(wlan0) - device_ap_sme=1 use_monitor=0
nl80211: Subscribe to mgmt frames with AP handle 0x1acf038 (device SME)
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0x1acf038 match=
nl80211: Register frame command failed (type=208): ret=-22 (Invalid argument)
nl80211: Register frame match - hexdump(len=0): [NULL]
nl80211: Could not configure driver mode
nl80211: deinit ifname=wlan0 disabled_11b_rates=0
nl80211: Remove monitor interface: refcount=0
nl80211: Remove beacon (ifindex=3)
netlink: Operstate: ifindex=3 linkmode=0 (kernel-control), operstate=6 (IF_OPER_UP)
nl80211: Set mode ifindex 3 iftype 2 (STATION)
nl80211: Teardown AP(wlan0) - device_ap_sme=1 use_monitor=0
nl80211 driver initialization failed.
hostapd_interface_deinit_free(0x1acdcd8)
hostapd_interface_deinit_free: num_bss=1 conf->num_bss=1
hostapd_interface_deinit(0x1acdcd8)
wlan0: interface state UNINITIALIZED->DISABLED
hostapd_bss_deinit: deinit bss wlan0
wlan0: AP-DISABLED 
hostapd_cleanup(hapd=0x1ace9a0 (wlan0))
hostapd_free_hapd_data: Interface wlan0 wasn't started
hostapd_interface_deinit_free: driver=(nil) drv_priv=(nil) -> hapd_deinit
hostapd_interface_free(0x1acdcd8)
hostapd_interface_free: free hapd 0x1ace9a0
hostapd_cleanup_iface(0x1acdcd8)
hostapd_cleanup_iface_partial(0x1acdcd8)
hostapd_cleanup_iface: free iface=0x1acdcd8

Reverting with:
sudo rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b brings it back.

Happy to help! Thanks as ever for super work!!!

[cjan]

want to block v4l2, which module(s)?

Any particular reason why? Both sit there taking near zero resources if not used.
bcm2835-v4l2 for the camera
bcm2835-codec for the codecs.

use vc4-kms-v3d, seems slow down system, after block become better.
but don't know if im right? or just 4.19 issue?

[dom]

But the wireless-regdb package in Raspbian seems to only have the older files, an doesn't put anything in /lib/firmware

Thanks for report - we are investigating.

[tonyhain]

If it helps the hostapd diagnostics, it appears the issue is broader than 4.19. This link shows the same

Code: Select all

nl80211: Register frame command failed (type=208): ret=-22 (Invalid argument)

occurred a few weeks back in 4.14.90-v7+ as well. https://raspberrypi.stackexchange.com/q ... aile/92643

[dom]

If it helps the hostapd diagnostics, it appears the issue is broader than 4.19. This link shows the same

Code: Select all

nl80211: Register frame command failed (type=208): ret=-22 (Invalid argument)

occurred a few weeks back in 4.14.90-v7+ as well. https://raspberrypi.stackexchange.com/q ... aile/92643

There is an issue about hostapd issues here (on 4.14 kernel) https://github.com/raspberrypi/linux/issues/2619

[lowflyer]

@tonyhain. Thanks! I should have added that when I reverted with

sudo rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b

and it worked again, it was running 4.14.98-v7+, so more recent that the failing version in that report.

[swahren]

Because of the many complains about broken AP mode, i want to link to my post from November:
https://www.raspberrypi.org/forums/view ... 5#p1396409

Since this won't be fixed in mainline, we have two options:
1) update hostapd to a more recent version (e.g. from Buster)
2) revert the mentioned commit

[tonyhain]

So yesterday I tried to see if I could find any combination of things that would make a difference in the behavior of this, but didn't have any luck. I did find that the 43430 files in 4.19.23-v7+ appear to be stale.

brcmfmac43430-sdio.bin distributed with 4.19.23-v7+

Code: Select all

brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Aug  7 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378

brcmfmac43430-sdio.bin cloned from git.kernel.org/pub/scm/linux/kernel/git ... rmware.git

Code: Select all

brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f

2019-01-15 update to brcmfmac43430-sdio.raspberrypi,3-model-b.txt

for testing soft link sdio.bin & sdio.txt in various combinations

Able to scan local SSIDs, but hostapd AP mode still fails.
Found diff from 4.9 distributed ... sdio.txt was lack of:

Code: Select all

# LTECX flags
ltecxmux=0
ltecxpadnum=0x0102
ltecxfnsel=0x44
ltecxgcigpio=0x01

Added those with no difference in behavior. Never could find definition for their function, but in the places mentioning them they have different values from the 43455 in the 3-b+.

I did find random comments about the 3-b+ not being able to work as an AP without a defined country_code due to compliance issues with the 5Ghz band. Suspecting that a change related to the 3-b+ may have had an unintended impact on the 3-b I added country_code=US to hostapd.conf with no effect to it or persistent state see by iw

Code: Select all

# iw reg get
country 00: DFS-UNSET

# tail -1 /etc/default/crda
REGDOMAIN=

setting that to US and doing the modprobe bounce results in

Code: Select all

# iw reg get
country US: DFS-FCC

no impact on AP mode though

Code: Select all

# hostapd -dd /tmp/hostapd.conf
...
nl80211: Setup AP(wlan0) - device_ap_sme=1 use_monitor=0
nl80211: Subscribe to mgmt frames with AP handle 0xb0c0e8 (device SME)
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) nl_handle=0xb0c0e8 match=
nl80211: Register frame command failed (type=208): ret=-22 (Invalid argument)
nl80211: Register frame match - hexdump(len=0): [NULL]
nl80211: Could not configure driver mode
...

giving up on 4.19.23-v7+
rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b

Code: Select all

[    0.000000] Linux version 4.14.98-v7+ 

all appears to be working ...
with 43430-sdio.bin ver 7.45.98.38 & 43430-sdio.txt as 2019-01-15 + ltecx flags

Code: Select all

# iw wlan0 info
Interface wlan0
	ifindex 3
	wdev 0x1
	addr b8:27:eb:80:a2:f7
	ssid stratux
	type AP
	wiphy 0
	channel 4 (2427 MHz), width: 20 MHz, center1: 2427 MHz

# arp -a
? (192.168.10.10) at (tablet-mac) [ether] on wlan0

Thanks for your comments, and hopefully this helps narrow the search for the problem.