Debian-kernel, I wish you business successfully #FuU3TiiK #
Dear Customer, Lockda is theleadingsmartlockmanufacturerfrom Chinamainland,factorylocated in Shenzhen. We providestate-of-artsmartlock and havemultiplekindsoflocksforyou to choose.The most important is we havecompetitivepricetohelpyoupromotebusiness in the market.Support OEM and ODM Write me back pls, let’s talk more in details!
Bug#969916: linux-image-5.8.0-1-arm64: USB3 port not working on Pine64's Rock64
Package: src:linux Version: 5.8.7-1 Severity: normal When connecting a USB device to the USB3 port on the Rock64, nothing appears in dmesg and lsblk doesn't show the device either. But when I boot into armbian, it does appear in both dmesg and lsblk. Then I found commit "[ rockchip64 ] add USB3 PHY RK3328" at https://github.com/armbian/build/commit/d230c3d15db200e81ddb3149f4a46198be2d9d20 and compared kernel configurations diederik@armbian-rock64:~$ grep -E 'CONFIG_HAVE_COPY_THREAD_TLS|CONFIG_CDROM|CONFIG_CHARGER_ISP1704|CONFIG_USB_PHY|CONFIG_PHY_ROCKCHIP_INNO_USB3' /boot/config-5.8.6-rockchip64 CONFIG_HAVE_COPY_THREAD_TLS=y CONFIG_CDROM=m # CONFIG_CDROM_PKTCDVD is not set CONFIG_CHARGER_ISP1704=m CONFIG_USB_PHY=y CONFIG_PHY_ROCKCHIP_INNO_USB3=y diederik@deb-rock64:~$ grep -E 'CONFIG_HAVE_COPY_THREAD_TLS|CONFIG_CDROM|CONFIG_CHARGER_ISP1704|CONFIG_USB_PHY|CONFIG_PHY_ROCKCHIP_INNO_USB3' /boot/config-* CONFIG_HAVE_COPY_THREAD_TLS=y CONFIG_CDROM=m # CONFIG_CDROM_PKTCDVD is not set # CONFIG_CHARGER_ISP1704 is not set CONFIG_USB_PHY=y Thus the 2 differences are CONFIG_CHARGER_ISP1704 and CONFIG_PHY_ROCKCHIP_INNO_USB3. I then checked the kernel configs of linux-image-5.8.0-1-armmp_5.8.7-1_armhf and linux-image-5.8.0-1-armmp-lpae_5.8.7-1_armhf (both from DL-ed .deb files) and noticed that both have CONFIG_CHARGER_ISP1704=m So my untrained eye would think that it could be enabled in arm64's config as well. The above referenced commit (message) also contains: "Adds the USB3 PHY driver currently under consideration upstream." I don't have the knowledge to determine whether that is safe/supported and what the status upstream is. I did find the following links, which maybe useful: https://patchwork.kernel.org/project/linux-rockchip/list/?submitter=179815 https://lkml.org/lkml/2020/8/16/168 Cheers, Diederik -- Package-specific info: ** Version: Linux version 5.8.0-1-arm64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.0-6) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.7-1 (2020-09-05) ** Command line: quiet ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information Device Tree model: Pine64 Rock64 ** Loaded modules: snd_soc_hdmi_codec dw_hdmi_i2s_audio aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul sha2_ce sha256_arm64 sha1_ce ofpart leds_gpio snd_soc_rockchip_spdif snd_soc_rockchip_i2s snd_soc_rockchip_pcm snd_soc_core spi_nor snd_pcm_dmaengine mtd snd_pcm lima snd_timer snd gpu_sched nvmem_rockchip_efuse rockchip_thermal dw_wdt soundcore cpufreq_dt ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic realtek rk808_regulator rtc_rk808 dwmac_rk clk_rk808 stmmac_platform stmmac rockchipdrm ohci_platform ohci_hcd analogix_dp dwc2 dw_hdmi cec mdio_xpcs rk808 dw_mipi_dsi phylink drm_kms_helper of_mdio fixed_phy udc_core ehci_platform ehci_hcd drm libphy usbcore phy_rockchip_inno_usb2 ptp fixed dw_mmc_rockchip pps_core dw_mmc_pltfm phy_rockchip_inno_hdmi usb_common rockchip_io_domain dw_mmc spi_rockchip pl330 i2c_rk3x ** Network interface configuration: *** /etc/network/interfaces: source /etc/network/interfaces.d/* auto lo iface lo inet loopback allow-hotplug eth0 iface eth0 inet dhcp ** Network status: *** IP interfaces and addresses: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 52:ce:d0:54:13:01 brd ff:ff:ff:ff:ff:ff inet 192.168.1.211/24 brd 192.168.1.255 scope global dynamic eth0 valid_lft 84990sec preferred_lft 84990sec inet6 fe80::50ce:d0ff:fe54:1301/64 scope link valid_lft forever preferred_lft forever *** Device statistics: Inter-| Receive| Transmit face |bytespackets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 0 0000 0 0 00 0000 0 0 0 eth0: 9046841371000 0 0 0 281183 990101 0 0 0 ** PCI devices: ** USB devices: Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: arm64 (aarch64) Kernel: Linux 5.8.0-1-arm64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via
Bug#969897: wireless-regdb: Document differences between debian and upstream regulatory.db
Package: wireless-regdb Version: 2020.04.29-2 Severity: wishlist Dear Maintainer, I recently encountered the error cfg80211: loaded regulatory.db is malformed or signature is missing/invalid when booting kernel 5.8.7 without Debian patches. Based on /usr/share/doc/wireless-regdb/README.Debian I understand that this is expected and I need to switch the regulatory.db alternative. This all works well, thanks. However, I don't understand the implications of this change. How does the Debian version differ from the upstream version, if at all? They appear to be binary identical on my system, and that this is enforced by the build scripts. Is the difference only the signing keys? Presumably there is good reason for this divergence. Would it be possible to document the differences and motivation in README.Debian and/or regulatory.db(5) to help users like myself understand? Thanks, Kevin -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.7 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled wireless-regdb depends on no packages. wireless-regdb recommends no packages. Versions of packages wireless-regdb suggests: ii crda 4.14+git20191112.9856751-1 -- no debconf information
Processed: Re: Bug#969889: linux-image-5.8.0-1-amd64: fails to load kernel modules, X does not work
Processing control commands: > reassign -1 src:nvidia-graphics-drivers-legacy-390xx Bug #969889 [src:linux] linux-image-5.8.0-1-amd64: fails to load kernel modules, X does not work Bug reassigned from package 'src:linux' to 'src:nvidia-graphics-drivers-legacy-390xx'. No longer marked as found in versions linux/5.8.7-1. Ignoring request to alter fixed versions of bug #969889 to the same values previously set -- 969889: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969889 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#969889: linux-image-5.8.0-1-amd64: fails to load kernel modules, X does not work
Control: reassign -1 src:nvidia-graphics-drivers-legacy-390xx On Tue, Sep 08, 2020 at 02:14:54PM +0200, Vincent Lefevre wrote: > Sep 08 13:31:20 zira systemd-modules-load[408]: Error running install command > 'modprobe nvidia-modeset ; modprobe -i nvidia-legacy-390xx-drm ' for module > nvidia_drm: retcode 1 No module called nvidia-legacy-390xx-drm is shipped with the kernel. So no bug here. I re-assigned the bug to the hopefully correct package. Bastian -- Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant." -- Kirk, "The Ultimate Computer", stardate 4731.3
Bug#969889: linux-image-5.8.0-1-amd64: fails to load kernel modules, X does not work
On 2020-09-08 13:59:07 +0200, Bastian Blank wrote:
> Control: tag -1 moreinfo
> Control: severity -1 important
>
> On Tue, Sep 08, 2020 at 01:36:45PM +0200, Vincent Lefevre wrote:
> > This version fails to load kernel modules (no issues with previous
> > Linux kernels provided by Debian). As a consequence, X does not work.
>
> > ** Loaded modules:
> > rfcomm
> > ipt_REJECT
>
> Your system have a lot of loaded modules. Please provide the real error
> message.
OK, I thought that the dmesg outout should contain it.
According to journalctl:
Sep 08 13:31:20 zira systemd-modules-load[408]: Error running install command
'modprobe nvidia-modeset ; modprobe -i nvidia-legacy-390xx-drm ' for module
nvidia_drm: retcode 1
Sep 08 13:31:20 zira systemd-modules-load[408]: Failed to insert module
'nvidia_drm': Invalid argument
Indeed, /var/log/apt/term.log contains:
Setting up linux-headers-5.8.0-1-amd64 (5.8.7-1) ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 5.8.0-1-amd64:
[...]
{ unset ARCH; env NV_VERBOSE=1 make -j8 modules KERNEL_UNAME=5.8.0-1-amd64; }
>> /var/lib/dkms/nvidia-legacy-390xx/390.138/build/make.log 2>&1
(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.8.0-1-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-legacy-390xx/390.138/build/make.log for more
information.
.
Setting up linux-headers-amd64 (5.8.7-1) ...
Setting up linux-image-amd64 (5.8.7-1) ...
Log ended: 2020-09-08 13:23:01
(note that this error was not forwarded to aptitude).
and /var/lib/dkms/nvidia-legacy-390xx/390.138/build/make.log contains:
[...]
FATAL: modpost: GPL-incompatible module nvidia-uvm.ko uses GPL-only symbol
'radix_tree_preloads'
make[3]: ***
[/usr/src/linux-headers-5.8.0-1-common/scripts/Makefile.modpost:111:
/var/lib/dkms/nvidia-legacy-390xx/390.138/build/Module.symvers] Error 1
make[2]: *** [/usr/src/linux-headers-5.8.0-1-common/Makefile:1681: modules]
Error 2
make[2]: Leaving directory '/usr/src/linux-headers-5.8.0-1-amd64'
make[1]: *** [Makefile:185: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.8.0-1-common'
make: *** [Makefile:81: modules] Error 2
--
Vincent Lefèvre - Web:
Processed: Re: Bug#969889: linux-image-5.8.0-1-amd64: fails to load kernel modules, X does not work
Processing control commands: > tag -1 moreinfo Bug #969889 [src:linux] linux-image-5.8.0-1-amd64: fails to load kernel modules, X does not work Added tag(s) moreinfo. > severity -1 important Bug #969889 [src:linux] linux-image-5.8.0-1-amd64: fails to load kernel modules, X does not work Severity set to 'important' from 'grave' -- 969889: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969889 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#969889: linux-image-5.8.0-1-amd64: fails to load kernel modules, X does not work
Control: tag -1 moreinfo Control: severity -1 important On Tue, Sep 08, 2020 at 01:36:45PM +0200, Vincent Lefevre wrote: > This version fails to load kernel modules (no issues with previous > Linux kernels provided by Debian). As a consequence, X does not work. > ** Loaded modules: > rfcomm > ipt_REJECT Your system have a lot of loaded modules. Please provide the real error message. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6
Bug#969889: linux-image-5.8.0-1-amd64: fails to load kernel modules, X does not work
Package: src:linux Version: 5.8.7-1 Severity: grave Justification: renders package unusable This version fails to load kernel modules (no issues with previous Linux kernels provided by Debian). As a consequence, X does not work. I've attached the dmesg output. -- Package-specific info: ** Version: Linux version 5.8.0-1-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.0-6) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.7-1 (2020-09-05) ** Command line: BOOT_IMAGE=/vmlinuz-5.8.0-1-amd64 root=/dev/mapper/zira--vg-root ro quiet ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Hewlett-Packard product_name: HP ZBook 15 G2 product_version: A3008CD10003 chassis_vendor: Hewlett-Packard chassis_version: bios_vendor: Hewlett-Packard bios_version: M70 Ver. 01.08 board_vendor: Hewlett-Packard board_name: 2253 board_version: KBC Version 03.10 ** Loaded modules: rfcomm ipt_REJECT nf_reject_ipv4 xt_multiport nft_compat nft_counter nf_tables nfnetlink cmac algif_hash algif_skcipher af_alg cpufreq_conservative cpufreq_userspace cpufreq_powersave bnep btusb btrtl btbcm iwlmvm btintel bluetooth intel_rapl_msr mac80211 libarc4 mei_wdt intel_rapl_common snd_hda_codec_realtek jitterentropy_rng binfmt_misc iwlwifi snd_hda_codec_generic drbg ledtrig_audio x86_pkg_temp_thermal snd_hda_codec_hdmi ansi_cprng intel_powerclamp cfg80211 coretemp ecdh_generic hp_wmi ecc snd_hda_intel sparse_keymap rapl snd_intel_dspcfg uvcvideo intel_cstate snd_hda_codec intel_uncore videobuf2_vmalloc videobuf2_memops snd_hda_core videobuf2_v4l2 videobuf2_common iTCO_wdt joydev snd_hwdep intel_pmc_bxt videodev snd_pcm pcspkr iTCO_vendor_support serio_raw mxm_wmi wmi_bmof mei_me snd_timer tpm_infineon watchdog sg mc rfkill apple_mfi_fastcharge at24 snd mei soundcore evdev tpm_tis tpm_tis_core tpm hp_accel lis3lv02d hp_wireless rng_core ac button parport_pc ppdev drm lp parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic dm_crypt dm_mod sd_mod sr_mod cdrom t10_pi crc_t10dif crct10dif_generic hid_apple hid_generic usbhid hid crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel rtsx_pci_sdmmc mmc_core ahci libahci libata aesni_intel xhci_pci libaes crypto_simd xhci_hcd cryptd glue_helper psmouse ehci_pci ehci_hcd e1000e i2c_i801 scsi_mod i2c_smbus usbcore rtsx_pci lpc_ich ptp pps_core usb_common battery video wmi ** Network status: *** IP interfaces and addresses: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 30:8d:99:25:ad:3f brd ff:ff:ff:ff:ff:ff inet 192.168.1.3/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0 valid_lft 86221sec preferred_lft 86221sec inet6 fe80::b735:e72d:ac2d:f50/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: wlp61s0: mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether cc:3d:82:a9:e3:ea brd ff:ff:ff:ff:ff:ff *** Device statistics: Inter-| Receive| Transmit face |bytespackets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 31682 360000 0 0 031682 360000 0 0 0 eth0: 9841141134000 0 0 4 217083 945000 0 0 0 wlp61s0: 0 0000 0 0 00 0000 0 0 0 *** Protocol statistics: Ip: Forwarding: 2 1036 total packets received 1 with invalid addresses 0 forwarded 0 incoming packets discarded 1008 incoming packets delivered 1077 requests sent out 20 outgoing packets dropped 548 dropped because of missing route 2 reassemblies required 1 packets reassembled ok Icmp: 46 ICMP messages received 0 input ICMP message failed ICMP input histogram: destination unreachable: 46 64 ICMP messages sent 0 ICMP messages failed ICMP output histogram: destination unreachable: 64 IcmpMsg: InType3: 46 OutType3: 64 Tcp: 28 active connection openings 5 passive connection openings 9 failed connection attempts 2 connection resets received 0 connections established 648 segments received 721 segments sent out 9 segments retransmitted 0 bad segments received 31 resets sent Udp: 412 packets received 40 packets to unknown port received 0 packet receive errors 463 packets sent 0 receive buffer errors
Bug#959768: [PATCH] initramfs-tools/hook-functions: Fix libgcc_s.so.1 dependency
>> Can you check whether the benh/libgcc_s branch works for you? > Yes, I can confirm that this fixes the issue for me. Ben, could you push out a new initramfs-tools package with this fix soon? Everytime I update the kernel package it fails to create the initrd... Helge
Processed: closing 968109
Processing commands for cont...@bugs.debian.org: > close 968109 5.8.7-1 Bug #968109 [src:linux] linux-image-5.7.0-2-arm64: USB unusable on Raspberry Pi 4B 8GB Ignoring request to alter fixed versions of bug #968109 to the same values previously set Bug #968109 [src:linux] linux-image-5.7.0-2-arm64: USB unusable on Raspberry Pi 4B 8GB Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 968109: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968109 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#941712: marked as done (hfs partitions corrupted when removing lots of files over network)
Your message dated Tue, 8 Sep 2020 08:20:40 +0200
with message-id <20200908062040.ga15...@lorien.valinor.li>
and subject line Re: Bug#941712: hfs partitions corrupted when removing lots of
files over network
has caused the Debian Bug report #941712,
regarding hfs partitions corrupted when removing lots of files over network
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.)
--
941712: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941712
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: hfsutils
Version: 3.2.6-14
Severity: grave
Output from uname -a
Linux raspberrypi 4.19.66-v7l+ #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7l
GNU/Linux
Output from apt show libc6 2>&1 | grep ^Version
Version: 2.28-10+rpi1
Hardware;
RaspberryPi model 2b and RaspberryPi model 4b
What led up to the situation?
I set up a new RaspberryPi to be a Samba network file server for an HFS
partition (see setup section at end of this email for details). I then deleted
about 300 files from the HFS partition from a client machine. This caused an
"Internal error: Oops: 206 [#1] SMP ARM". See kern.log below for Oops details.
After the error, the filesytem was corrputed and could not be repaired using
fsck. See fsck output below.
To reproduce the problem, I run the following from a client machine;
for i in {1..300}; do touch /Volumes/TimeMachineBackup/$i; done ; rm
/Volumes/TimeMachineBackup/*
Every time I re-run this test on a freshly formatted drive, the same error
occurs and the filesystem is always corrupted and cannot be repaired (i.e.
total data loss).
What exactly did you do (or not do) that was effective (or ineffective)?
I tried all of the following;
- Replaced Samba network sharing with Netatalk
- Re-installed Raspbian from scratch
- Different mkfs.hfs formatting options to add journal files and alter the
b-node sizes
- Various samba configurations to change sync / async options, threading
options, permissions, etc
- 3 different disk drives (USB flash drive, USB powered HDD, Separately powered
HDD)
- 2 different RaspberryPi models (2b and 4b)
- Different network connections speeds (WiFi at 200Mbs, Ethernet at 100Mbs,
Ethernet at 1000Mbs)
- Deleted 300 files locally on the RaspberryPi file server (i.e. not over
network)
- Replaced HFS+ format with EXT4
What was the outcome of this action?
None the the things I tried above had any impact on the problem except;
- The problem did not occur at all when deleting locally on the RaspberryPi
file server.
- The problem did not occur at all when HFS+ was replaced with EXT4
What outcome did you expect instead?
Given the problem did not occur locally on the file server, but did over
Sambaa, I expected the problem to go away when I replaced Samba with Netatalk.
It did not.
I wonder if the problem relates to how all file-networking protocols interact
with local filesystems?
#
# LOGS AND OUTPUT #
#
# kern.log;
Sep 26 16:09:25 raspberrypi kernel: [ 222.906719] hfsplus: trying to free free
bnode 0(1)
Sep 26 16:09:25 raspberrypi kernel: [ 222.906844] hfsplus: trying to free free
bnode 0(1)
Sep 26 16:09:25 raspberrypi kernel: [ 222.906893] Unable to handle kernel NULL
pointer dereference at virtual address
Sep 26 16:09:25 raspberrypi kernel: [ 222.906906] pgd = bc442823
Sep 26 16:09:25 raspberrypi kernel: [ 222.906914] [] *pgd=11d05003,
*pmd=
Sep 26 16:09:25 raspberrypi kernel: [ 222.906933] Internal error: Oops: 206
[#1] SMP ARM
Sep 26 16:09:25 raspberrypi kernel: [ 222.906942] Modules linked in: nls_utf8
hfsplus bnep hci_uart btbcm serdev bluetooth ecdh_generic 8021q garp stp llc
vc4 v3d drm_kms_helper brcmfmac gpu_sched brcmutil drm
drm_panel_orientation_quirks snd_bcm2835(C) snd_soc_core sha256_generic
snd_compress snd_pcm_dmaengine snd_pcm sg snd_timer syscopyarea sysfillrect
sysimgblt fb_sys_fops cfg80211 rfkill snd raspberrypi_hwmon hwmon
bcm2835_codec(C) bcm2835_v4l2(C) v4l2_mem2mem v4l2_common videobuf2_vmalloc
bcm2835_mmal_vchiq(C) videobuf2_dma_contig videobuf2_memops videobuf2_v4l2
videobuf2_common videodev media vc_sm_cma(C) rpivid_mem uio_pdrv_genirq uio
fixed ip_tables x_tables ipv6
Sep 26 16:09:25 raspberrypi kernel: [ 222.907150] CPU: 3 PID: 634 Comm: smbd
Tainted: G C4.19.66-v7l+ #1253
Sep 26 16:09:25 raspberrypi kernel: [ 222.907160] Hardware name:
Bug#941712: hfs partitions corrupted when removing lots of files over network
Source: linux Source-Version: 4.19.118-1 Hi Graham, On Mon, Sep 07, 2020 at 01:45:00PM +1000, Graham Coster wrote: > Hi Salvatore, > > Thank you for following up on this. Unfortunately I can no longer test > this out. The hardware is no longer unavailable and since "upgrading" to > Catalina I can't get virtualbox running on my mac :(. > > Given I can't test this out, would you like me to close the bug report? No worries, too bad we only replied too late. I'm relatively confident that the mentioned commit might be the fix for the issue you were seeing, so let's procoeed with the bug closing, if someone later on re-encounters a similar problem we can reopen it and re-investigate. Thanks for your time taken for writing up the reports! Regards, Salvatore
