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.
Re: Moving Linux kernel to 4.19
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5708
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Moving Linux kernel to 4.19
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.kozman wrote: ↑Wed Feb 20, 2019 12:34 pmHe'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.
Some files are seven years old because they haven't changed since day one. Doesn't mean anything is wrong.
Re: Moving Linux kernel to 4.19
dom wrote: ↑Wed Feb 20, 2019 1:00 pmThe 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.kozman wrote: ↑Wed Feb 20, 2019 12:34 pmHe'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.
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.

Re: Moving Linux kernel to 4.19
With external disk attached when upgraded to 4.19 e4defrag commands kills the system:
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.
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
Re: Moving Linux kernel to 4.19
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.
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.
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5708
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Moving Linux kernel to 4.19
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?
Re: Moving Linux kernel to 4.19
DougieLawson wrote: ↑Mon Feb 18, 2019 6:57 pmMy 3B+ isn't happy. The WiFi network is very flaky.
That one is going back to 4.14.79-v7+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 ...
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
Last edited by Muximize on Fri Feb 22, 2019 5:18 pm, edited 3 times in total.
Re: Moving Linux kernel to 4.19
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.
-
- Posts: 13
- Joined: Sat Feb 23, 2019 8:09 pm
Re: Moving Linux kernel to 4.19
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 nowdom wrote: ↑Fri Nov 30, 2018 11:47 amI 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
Code: Select all
dtoverlay=gpio-ir,gpio_pin=23
dtoverlay=gpio-ir-tx,gpio_pin=22
Re: Moving Linux kernel to 4.19
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.
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.
Re: Moving Linux kernel to 4.19
Can you try putting regulatory.db and regulatory.db.p7s in /lib/firmware? See my post a bit earlier for details.
Re: Moving Linux kernel to 4.19
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.
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.
Re: Moving Linux kernel to 4.19
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
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
Re: Moving Linux kernel to 4.19
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.
# 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.
Re: Moving Linux kernel to 4.19
want to block v4l2, which module(s)?
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 10518
- Joined: Wed Dec 04, 2013 11:27 am
- Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.
Re: Moving Linux kernel to 4.19
Any particular reason why? Both sit there taking near zero resources if not used.
bcm2835-v4l2 for the camera
bcm2835-codec for the codecs.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.
I'm not interested in doing contracts for bespoke functionality - please don't ask.
Re: Moving Linux kernel to 4.19
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
Reverting with:
sudo rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b brings it back.
Happy to help! Thanks as ever for super work!!!
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
sudo rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b brings it back.
Happy to help! Thanks as ever for super work!!!
Re: Moving Linux kernel to 4.19
use vc4-kms-v3d, seems slow down system, after block become better.
but don't know if im right? or just 4.19 issue?
Re: Moving Linux kernel to 4.19
If it helps the hostapd diagnostics, it appears the issue is broader than 4.19. This link shows the same occurred a few weeks back in 4.14.90-v7+ as well. https://raspberrypi.stackexchange.com/q ... aile/92643
Code: Select all
nl80211: Register frame command failed (type=208): ret=-22 (Invalid argument)
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5708
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Moving Linux kernel to 4.19
There is an issue about hostapd issues here (on 4.14 kernel) https://github.com/raspberrypi/linux/issues/2619tonyhain wrote: ↑Mon Feb 25, 2019 5:35 pmIf it helps the hostapd diagnostics, it appears the issue is broader than 4.19. This link shows the sameoccurred a few weeks back in 4.14.90-v7+ as well. https://raspberrypi.stackexchange.com/q ... aile/92643Code: Select all
nl80211: Register frame command failed (type=208): ret=-22 (Invalid argument)
Re: Moving Linux kernel to 4.19
@tonyhain. Thanks! I should have added that when I reverted with
and it worked again, it was running 4.14.98-v7+, so more recent that the failing version in that report.sudo rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b
Re: Moving Linux kernel to 4.19
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
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
Re: Moving Linux kernel to 4.19
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+
brcmfmac43430-sdio.bin cloned from git.kernel.org/pub/scm/linux/kernel/git ... rmware.git
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:
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
setting that to US and doing the modprobe bounce results in
no impact on AP mode though
giving up on 4.19.23-v7+
rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b
all appears to be working ...
with 43430-sdio.bin ver 7.45.98.38 & 43430-sdio.txt as 2019-01-15 + ltecx flags
Thanks for your comments, and hopefully this helps narrow the search for the problem.
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
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
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
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=
Code: Select all
# iw reg get
country US: DFS-FCC
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
...
rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b
Code: Select all
[ 0.000000] Linux version 4.14.98-v7+
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