Control: tag -1 moreinfo On Sunday, 3 July 2022 14:40:36 CET Jean-Marc LACROIX wrote: > Package: linux-image-5.18.0-2-arm64 > Version: 5.18.5-1 > > Please find in attached file success story (!) on recent boot for > target rock64 (pine64) with 64 Go class10 MMC card with Debian 11.3 > Bullseye and Bookworm 5.18.5-1 kernel with following configuration ... There is no attached file ... > ansible@hn-rock64-130:~$ uname -a > Linux hn-rock64-130 5.18.0-2-arm64 #1 SMP Debian 5.18.5-1 (2022-06-16) > aarch64 GNU/Linux > ... > ansible@hn-rock64-130:~$ cat > /etc/apt/preferences.d/preferences_debian_v_11_bullseye* |grep -v "#" > |grep -v ^$ > > Package: vmdb2 > Pin: release o=Debian,l=Debian,n=bullseye > Pin-Priority: 920 > Package: * > Pin: release o=Debian,l=Debian,n=bullseye/updates > Pin-Priority: 500 > Package: * > Pin: release o=Debian,l=Debian,n=bullseye-update > Pin-Priority: 500 > Package: * > Pin: release o=Debian,l=Debian,n=bullseye > Pin-Priority: 500 > Package: * > Pin: release o=Debian,l=Debian,n=bullseye-backports > Pin-Priority: 100 > Package: * > Pin: release o=Debian,l=Debian,n=buster > Pin-Priority: 90 > Package: * > Pin: release o=Debian,l=Debian,n=bookworm > Pin-Priority: 80 > Package: * > Pin: release o=Debian,l=Debian,n=sid > Pin-Priority: 70 > Package: * > Pin: release o=Debian,l=Debian,n=experimental > Pin-Priority: 60 > Package: avahi-daemon > Pin: release * > Pin-Priority: -1 > Package: dbus > Pin: release a=bullseye > Pin-Priority: -1 > > Package: dhcpcd5 > Pin: release * > Pin-Priority: -1 > Package: rtkit > Pin: release * > Pin-Priority: -1 > Package: systemd > Pin: release * > Pin-Priority: -1 This looks rather troublesome to me as you're combining oldstable/stable/ testing/unstable/experimental*, but AFAICT you're mostly running a Bullseye system and then using kernel 5.18.5-1 isn't the most logical choice. If you want to try a newer kernel on a Bullseye system, using bullseye- backports would be the most logical choice ... *) I'm aware of how APT preferences work, so there's no need to explain that. It's probably not relevant to this bug, but this is called a FrankenDebian: https://wiki.debian.org/DontBreakDebian > ... list of loaded kernel modules > After installing kernel 5.18.0-2-arm64, the good news is that the mmc > device number now looks ALWAYS correct (!). Previously, in the kernel > (5.10.xx), when booting target, sometimes mmc id was either > /dev/mmcblk0 or /dev/mmcblk1 for unknown reasons (?). > > Now either with a soft reboot command (sudo reboot) or with a forced > shutdown (power ON/OFF), the identification is still good,i.e. /dev/mmcblk0. Great. > But [ref 1], there is still some stranges messages in dmesg ... I'm guessing [ref 1] and [ref 2] were mentioned in the file which was NOT attached? The consequence is that I can't tell what the issue is what this bug is/should be about. Can you clarify? > [ 7.585764] dwmmc_rockchip ff520000.mmc: DW MMC controller at irq > 40,32 bit host data width,256 deep fifo > [ 7.586886] rockchip-pinctrl pinctrl: pin gpio0-2 already requested > by vcc-host-5v-regulator; cannot claim for vcc-host1-5v-regulator > [ 7.588110] rockchip-pinctrl pinctrl: pin-2 (vcc-host1-5v-regulator) > status -22 > [ 7.588576] ehci-platform ff5c0000.usb: USB 2.0 started, EHCI 1.00 > [ 7.588797] rockchip-pinctrl pinctrl: could not request pin 2 > (gpio0-2) from group usb20-host-drv on device rockchip-pinctrl > [ 7.589899] usb usb1: New USB device found, idVendor=1d6b, > idProduct=0002, bcdDevice= 5.18 > [ 7.590353] reg-fixed-voltage vcc-host1-5v-regulator: Error applying > setting, reverse things back Ideally these warnings should be resolved some time, but I'm seeing them too (I also have Rock64 devices), but AFAICT they're harmless. > [ 7.694550] rk_gmac-dwmac ff540000.ethernet: phy regulator is not > available yet, deferred probing The 'deferred probing' just means it will be tried again at a later point. If ethernet would not work after it finished booting, that would be a problem, but I'm not aware that actually happens. > As a result, it is not very clear for me why there is one warning > message ([ref 2]) ? Not having [ref 2] so I don't know which warning that is. But as said earlier, there are several warnings (and maybe even errors) reported, but AFAIK they're harmless. > Any ideas or suggestions will be appreciated (!) If you could clearly state what issue/bug you encountered, that would help. And while you're at it, please also try whether a more recent kernel may have already fixed the issue you tried to report.
Attachment:
signature.asc
Description: This is a digitally signed message part.