Bug#982757: firmware-brcm80211: [REGRESSION] brcm/brcmfmac43340-sdio.bin missing in sid (20210208-1)
severity 982757 critical stop > Version: 20201218-3 > Severity: normal thank you for the report, oh boy this one is opens a can of trouble. It seems I was blissfully unaware that the Debian packaging did not take into account the symlinks of upstream linux-firmware WHENCE file. So this means we are missing a *lot* - all the symlinks!?!? > after latest update wifi stopped working and I saw that > brcm/brcmfmac43340-sdio.bin was missing, right it was replaced by newer cypress version and there should be a symlink of that guy from the older name: Link: brcm/brcmfmac43340-sdio.bin -> ../cypress/cyfmac43340-sdio.bin Could you please test latest 2021 upstream package with this symlink? kind regards, -- maks signature.asc Description: PGP signature
Processed: Re: Bug#982757: firmware-brcm80211: [REGRESSION] brcm/brcmfmac43340-sdio.bin missing in sid (20210208-1)
Processing commands for cont...@bugs.debian.org: > severity 982757 critical Bug #982757 [firmware-brcm80211] firmware-brcm80211: [REGRESSION] brcm/brcmfmac43340-sdio.bin missing in sid (20210208-1) Severity set to 'critical' from 'normal' > stop Stopping processing here. Please contact me if you need assistance. -- 982757: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982757 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#982579: Solution for loading firmware
Dear Bernhard, Thank you very much for your clear and helpful report! > I tested the following: > > 1. Copy file brcmfmac43430-sdio.AP6212.txt from upstream to lib/firmware/brcm so indeed it is a bug that we don't ship this one from upstream, will fix this in next Debian upload. > 2. Create symbolic link named brcmfmac43430-sdio.sinovoip.bpi-m3.txt to the > AP6212-file > 3. Create symbolic link named brcmfmac43430-sdio.sinovoip.bpi-m2-ultra.txt to > the AP6212-file this should be reported upstream, so that everyone takes advantage of it, hence adding linux-firmware mailinglist on Cc, happy to cook up a patch next 24hs. > After that, the wlan0 interface is available and scanning of the WLAN-ESSIDs > works. great! > Please either do it like described above or add the files directly instead of > the symbolic links. The symbolic links are better than duplicated files, but there seem to be on the Debian side an opened can of trouble on them, see #982757 (I'll post there soonish) Thank you for the kind words, the test and your report! -- maks signature.asc Description: PGP signature
Processed: Re: Bug#982840: linux-image-5.10.0-3-arm64: requesting scsi_debug.ko for arm64/armhf helping systemd autopkgtest
Processing control commands: > retitle -1 requesting scsi_debug.ko for arm64 helping > systemd autopkgtest Bug #982840 [src:linux] linux-image-5.10.0-3-arm64: requesting scsi_debug.ko for arm64/armhf helping systemd autopkgtest Changed Bug title to 'requesting scsi_debug.ko for arm64 helping systemd autopkgtest' from 'linux-image-5.10.0-3-arm64: requesting scsi_debug.ko for arm64/armhf helping systemd autopkgtest'. -- 982840: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982840 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#982840: linux-image-5.10.0-3-arm64: requesting scsi_debug.ko for arm64/armhf helping systemd autopkgtest
Control: retitle -1 requesting scsi_debug.ko for arm64 helping systemd autopkgtest Lack of scsi_debug.ko is also observed for ppc64el. Ryutaroh
Bug#982579: Solution for loading firmware
Hello Maks I tested the following: 1. Copy file brcmfmac43430-sdio.AP6212.txt from upstream to lib/firmware/brcm 2. Create symbolic link named brcmfmac43430-sdio.sinovoip.bpi-m3.txt to the AP6212-file 3. Create symbolic link named brcmfmac43430-sdio.sinovoip.bpi-m2-ultra.txt to the AP6212-file After that, the wlan0 interface is available and scanning of the WLAN-ESSIDs works. Please either do it like described above or add the files directly instead of the symbolic links. Best regards and thank you for the great support. Bernhard signature.asc Description: This is a digitally signed message part
Bug#981492: marked as done (linux-source-5.10: Module-only builds failing since 39a8b293)
Your message dated Mon, 15 Feb 2021 22:37:08 +0100 with message-id <3f9f27cc275a7d6f894a19e1db57bf4046c858e4.ca...@decadent.org.uk> and subject line Re: linux-source-5.10: Module-only builds failing since 39a8b293 has caused the Debian Bug report #981492, regarding linux-source-5.10: Module-only builds failing since 39a8b293 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 981492: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981492 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: linux-source-5.10 Version: 5.10.9-1 Severity: normal Tags: ftbfs X-Debbugs-Cc: nos...@kota.moe Trying to build in-tree kernel modules without the rest of the kernel (with the M=... make target) results in the build failing with "ld: cannot open linker script file -o: No such file or directory" Commands to reproduce (taken from a DKMS Makefile): tar xaf $(LINUX_SOURCE_TAR) --strip-components=1 -C linux-source cp /boot/config-$(KERNELRELEASE) linux-source/.config cp /usr/src/linux-headers-$(KERNELRELEASE)/Module.symvers linux- source/Module.symvers $(MAKE) -C linux-source oldconfig $(MAKE) -C linux-source prepare $(MAKE) -C linux-source M=drivers/hwmon This seems to be direct cause of a recent Debian patch: https://salsa.debian.org/kernel- team/linux/-/blob/master/debian/patches/debian/kbuild-look-for-module.lds- under-arch-directory-too.patch (commit 39a8b293ff1881bca11dae1831885dd30581d023) The patch tries to make the linker only use a specific linker script (module.lds) if it exists, but ends up preventing the linker script from being built from source (module.lds.S), and thus ends up never existing. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-source-5.10 depends on: ii binutils 2.35.1-7 ii xz-utils 5.2.5-1.0 Versions of packages linux-source-5.10 recommends: ii bc1.07.1-2+b2 ii bison 2:3.7.4+dfsg-1 ii flex 2.6.4-8 ii gcc 4:10.2.1-1 ii libc6-dev [libc-dev] 2.31-9 ii linux-config-5.10 5.10.9-1 ii make 4.3-4 Versions of packages linux-source-5.10 suggests: ii libncurses-dev [ncurses-dev] 6.2+20201114-2 ii pkg-config0.29.2-1 pn qtbase5-dev -- no debconf information --- End Message --- --- Begin Message --- Control: tag -1 - patch moreinfo On Mon, 2021-02-15 at 22:39 +1100, 小太 wrote: [...] > The real problem isn't in the code however, but in my Makefile. > I didn't run the "modules_prepare" target before trying to build a module, > despite it being documented: > https://www.kernel.org/doc/Documentation/kbuild/modules.txt > > Adding that target to my Makefile resolved the issue, without any changes > to the linux-source package. > So this bug is now invalid Therefore I am closing it. Thanks for checking. Ben. -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part --- End Message ---
Bug#982840: linux-image-5.10.0-3-arm64: requesting scsi_debug.ko for arm64/armhf helping systemd autopkgtest
The lack of scsci_debug.ko for arm64 also makes the autopkgtest-virt-qemu testsuite fail with udisks2. Ryutaroh
Bug#981492: linux-source-5.10: Module-only builds failing since 39a8b293
Hello 小太, just to let you know that your bug report was useful anyway: I ran into the same issue, and needed the same fix. In fact, my build script had the "make modules_prepare" commented out, with a "# TODO: is this needed?" comment above. Apparently, it wasn't needed until Linux 5.10. So thank you very much for posting this bug and the solution, and including the full error message in the description - that led me to this bug report, and saved me hours of hunting down the issue. Best Regards, -Robert On Mon, 15 Feb 2021 22:39:36 +1100 =?UTF-8?B?4oCN5bCP5aSq?= wrote: > Apologies - I jumped to conclusions in my original bug report > > After applying your patch and seeing it did not fix the issue, I did a bit > of investigation myself. > It turns out the problem wasn't in the linked commit, but actually part of > the upstream kernel: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.11=596b0474d3d9b1242eab713f84d8873f9887d980 > > The real problem isn't in the code however, but in my Makefile. > I didn't run the "modules_prepare" target before trying to build a module, > despite it being documented: > https://www.kernel.org/doc/Documentation/kbuild/modules.txt > > Adding that target to my Makefile resolved the issue, without any changes > to the linux-source package. > So this bug is now invalid
Re: Include J1939 module in kernel build
Thanks Vincent ! I wanted to do the same but couldn't figure out where to do so... On Mon, Feb 15, 2021, 09:47 Vincent Blut wrote: > Hi Rene, > > Le 2021-02-14 22:15, reneherr...@gmail.com a écrit : > > Dear Maintainer, > > > > I don't usually get to thank folks for everything that is made available > to the world, so a big and sincere thank you, despite not knowing who you > are. > > > > This is most definitely in the wishlist bucket as it is non-essential. > It is however very low lying fruit. > > > > J1939 and other derived protocols such as NMEA 2000 are widely used in > the automotive and marine industries to name a few. > > > > I myself live on a sailboat and use various pieces of software that get > supercharged when they can collect data from other devices on the boat. > > > > For example, I have an AIS and GPS devices on my NMEA 2000 bus that > broadcasts the boat's position and that of other vessels (avoiding large > metallic objects out at sea is a good thing). The can-j1939 Linux Kernel > module does all the heavy lifting involved with the protocol which sits on > top of CAN and allows you to easily send and receive messages with hardware > devices already supported in Debian Linux (ex: CAN Bus Analyzer from > Microchip). This module enables pulling that data and feeding it to a > chart plotter such as OpenCPN. In simple terms, seeing a chart is nice, > seing a chart displaying your position and that of other boats is *very* > nice, having an alarm go off when a process detects a collision is eminant > is *pure awesomeness* as it can literally save your life. > > > > The currect workaround is simply to pull the sources and recompiling the > kernel, which is not a huge deal, but it is a little anoying as this > (idealy) needs to be repeated every update. > > > > Thanks for taking the time to read and consider this, > > > > Rene > > I sent a merge request for this: > https://salsa.debian.org/kernel-team/linux/-/merge_requests/329 > > > Cheers, > Vincent >
Workshops on Bid Writing and 17 Other Topics
FORTHCOMING TRAINING COURSES ONLINE VIA ZOOM - 10.00 to 12.30 - COST £95.00 For more details and booking links please google nfp workshops Bid Writing: The Basics Mon 22 Feb 2021 - Mon 08 Mar 2021 - Mon 22 Mar 2021 - Mon 12 Apr 2021 - Mon 26 Apr 2021 Bid Writing: Advanced Tue 23 Feb 2021 - Tue 09 Mar 2021 - Tue 23 Mar 2021 - Tue 13 Apr 2021 - Tue 27 Apr 2021 Recruiting and Managing Volunteers Wed 10 Mar 2021 - Thu 13 May 2021 Major Donor Fundraising Wed 14 Apr 2021 - Thu 10 Jun 2021 Corporate Fundraising - Mon 01 Mar 2021 Capital Campaigns - Tue 02 Mar 2021 Legacy Fundraising - Wed 03 Mar 2021 Running Fundraising Events - Thu 04 Mar 2021 Recruiting & Working With Trustees - Fri 05 Mar 2021 Being A Better Trustee - Fri 12 Mar 2021 Community Fundraising - Mon 15 Mar 2021 Writing For Work & The Web - Tue 16 Mar 2021 Time Management, Delegation & Meetings - Wed 17 Mar 2021 Delivering Presentations - Thu 18 Mar 2021 Leadership - Fri 19 Mar 2021 GDPR & Data Protection - Thu 25 Mar 2021 Public Relations & Publicity - Fri 26 Mar 2021 Coaching & Mentoring - Mon 29 Mar 2021 Training For Trainers - Tue 30 Mar 2021 To unsubscribe please reply back replacing the subject line with debian-kernel@lists.debian.org NFP WORKSHOPS 18 Blake Street, York YO1 8QG 01133 280988
Re: Include J1939 module in kernel build
Hi Rene, Le 2021-02-14 22:15, reneherr...@gmail.com a écrit : > Dear Maintainer, > > I don't usually get to thank folks for everything that is made available to > the world, so a big and sincere thank you, despite not knowing who you are. > > This is most definitely in the wishlist bucket as it is non-essential. It is > however very low lying fruit. > > J1939 and other derived protocols such as NMEA 2000 are widely used in the > automotive and marine industries to name a few. > > I myself live on a sailboat and use various pieces of software that get > supercharged when they can collect data from other devices on the boat. > > For example, I have an AIS and GPS devices on my NMEA 2000 bus that > broadcasts the boat's position and that of other vessels (avoiding large > metallic objects out at sea is a good thing). The can-j1939 Linux Kernel > module does all the heavy lifting involved with the protocol which sits on > top of CAN and allows you to easily send and receive messages with hardware > devices already supported in Debian Linux (ex: CAN Bus Analyzer from > Microchip). This module enables pulling that data and feeding it to a chart > plotter such as OpenCPN. In simple terms, seeing a chart is nice, seing a > chart displaying your position and that of other boats is *very* nice, having > an alarm go off when a process detects a collision is eminant is *pure > awesomeness* as it can literally save your life. > > The currect workaround is simply to pull the sources and recompiling the > kernel, which is not a huge deal, but it is a little anoying as this (idealy) > needs to be repeated every update. > > Thanks for taking the time to read and consider this, > > Rene I sent a merge request for this: https://salsa.debian.org/kernel-team/linux/-/merge_requests/329 Cheers, Vincent signature.asc Description: PGP signature
Bug#981492: linux-source-5.10: Module-only builds failing since 39a8b293
Apologies - I jumped to conclusions in my original bug report After applying your patch and seeing it did not fix the issue, I did a bit of investigation myself. It turns out the problem wasn't in the linked commit, but actually part of the upstream kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.11=596b0474d3d9b1242eab713f84d8873f9887d980 The real problem isn't in the code however, but in my Makefile. I didn't run the "modules_prepare" target before trying to build a module, despite it being documented: https://www.kernel.org/doc/Documentation/kbuild/modules.txt Adding that target to my Makefile resolved the issue, without any changes to the linux-source package. So this bug is now invalid On Mon, 15 Feb 2021 at 12:49, Ben Hutchings wrote: > Control: tag -1 patch moreinfo > > Does this fix it? > > Ben. > > -- > Ben Hutchings > 73.46% of all statistics are made up. >
Bug#982840: linux-image-5.10.0-3-arm64: requesting scsi_debug.ko for arm64/armhf helping systemd autopkgtest
Package: src:linux Version: 5.10.13-1 Severity: wishlist Dear Maintainer, Latest autopkgtest Salsa supports arm64 QEMU testbeds. When we apply autopkgtest-virt-qemu --dpkg-architecture=arm64 or armhf on systemd, the "storage" test fails because of modprobe: FATAL: Module scsi_debug not found in directory /lib/modules/5.10.0-3-arm64 I talked with Michael Biebl on https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/113#note_227958 he wondered if it is possible to enable scsi_debug on arm64 Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.10.0-3-arm64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.13-1 (2021-02-06) ** Command line: dma.dmachans=0x37f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3eb0 vc_mem.mem_size=0x3ff0 console=tty0 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 rootwait rootfstype=ext4 module_blacklist=vc4 ** Tainted: C (1024) * staging driver was loaded ** Kernel log: [ 20.631603] systemd[1]: Mounting Huge Pages File System... [ 20.683486] systemd[1]: Mounting POSIX Message Queue File System... [ 20.736492] systemd[1]: Mounting Kernel Debug File System... [ 20.787618] systemd[1]: Mounting Kernel Trace File System... [ 20.836925] systemd[1]: Starting Restore / save the current clock... [ 20.889264] systemd[1]: Starting Set the console keyboard layout... [ 20.940552] systemd[1]: Starting Create list of static device nodes for the current kernel... [ 20.992153] systemd[1]: Starting Load Kernel Module configfs... [ 21.044220] systemd[1]: Starting Load Kernel Module drm... [ 21.095387] systemd[1]: Starting Load Kernel Module fuse... [ 21.138735] fuse: init (API version 7.32) [ 21.163989] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. [ 21.164255] systemd[1]: Condition check resulted in File System Check on Root Device being skipped. [ 21.227986] systemd[1]: Starting Journal Service... [ 21.464155] systemd[1]: Starting Load Kernel Modules... [ 21.513840] systemd[1]: Starting Remount Root and Kernel File Systems... [ 21.563344] EXT4-fs (sda2): re-mounted. Opts: journal_async_commit,nobarrier,data=writeback,commit=3600 [ 21.564141] systemd[1]: Starting Coldplug All udev Devices... [ 21.651478] systemd[1]: Mounted Huge Pages File System. [ 21.694010] systemd[1]: Started Journal Service. [ 22.064408] systemd-journald[243]: Received client request to flush runtime journal. [ 37.861091] vcc-sd: disabling [ 39.399477] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer [ 39.439887] vchiq: module is from the staging directory, the quality is unknown, you have been warned. [ 39.488816] iproc-rng200 fe104000.rng: hwrng registered [ 39.516318] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 39.610584] Module vc4 is blacklisted [ 39.638493] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 39.657619] cfg80211: Loaded X.509 cert 'b...@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf' [ 39.678583] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328' [ 39.700179] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 39.706556] io scheduler kyber registered [ 39.719922] platform regulatory.0: firmware: direct-loading firmware regulatory.db [ 39.787993] platform regulatory.0: firmware: direct-loading firmware regulatory.db.p7s [ 39.813752] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) [ 39.844975] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 39.863636] usbcore: registered new interface driver brcmfmac [ 39.877152] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned. [ 39.905384] bcm2835_audio bcm2835_audio: card created with 8 channels [ 39.907090] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.bin [ 39.925440] mc: Linux media interface: v0.10 [ 39.956391] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt [ 40.102108] videodev: Linux video capture interface: v2.00 [ 40.107976] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 40.108103] brcmfmac mmc0:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.clm_blob (-2) [ 40.108107] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware [ 40.108113] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 40.109706] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar 1 2015 07:29:38
