Bug#1059390: linux-image-6.5.0-5-amd64: Large number of missed packets reported by "e1000e" driver
On Thu, Dec 28, 2023 at 10:36:40AM +0100, Salvatore Bonaccorso wrote: > > There is another ehternet interface in this machine which is driven > > by the "igc" driver. It reports zero missed packets but it also not > > using mini jumbo frames. > > And I assume you have the same as well with 6.6.8-1 from the newest > stable series as present in unstable? I have not tried that so far. Is there a clean way (without messing up the package management) to install that kernel? > If so I guess you are in a good position to report that upstream, but > please keep this downstream bug as well in the loop (or ping it about > updates). What is the best way to report Linux kernel bugs? Kind regards -- Matthias Scheler http://zhadum.org.uk/
Bug#1059390: linux-image-6.5.0-5-amd64: Large number of missed packets reported by "e1000e" driver
Package: src:linux Version: 6.5.13-1 Severity: normal Tags: upstream Dear Maintainer, I'm using a Shuttle DS20UV2 as my broadband router and firewall. After updating it from Debian 12.4 to Trixie yesterday one of its network interfaces started reporting a large and ever increasing number of missed packets: > ip -s link show eno1 3: eno1: mtu 1508 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 80:ee:73:XX:XX:XX brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 991043595 846955 0 03691 0 TX: bytes packets errors dropped carrier collsns 890811461 793387 0 0 0 0 altname enp0s31f6 The number was much larger before I rebooted the machine to test out some kernel parameter changes. I originally had similar problems with Debian 12.x. But increasing the RX ring size from 256 to 1024 fixed the problem. Under Trixie neither this nor increasing the RX ring size to the maximum of 4096 helps. I also tried to restrict the maximum C-state to 3 (down from 9) which again didn't help. The interface in question is using an MTU of 1508 bytes to allow an MTU of 1500 bytes on PPPoE session running over it. The broadband link's maximum speed is 1 Gbit/sec. As such the incoming packet rate can be high at times. There is another ehternet interface in this machine which is driven by the "igc" driver. It reports zero missed packets but it also not using mini jumbo frames. -- Package-specific info: ** Version: Linux version 6.5.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 13.2.0-7) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC Debian 6.5.13-1 (2023-11-29) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.5.0-5-amd64 root=UUID=3f51e9a7-af14-4c6d-a6f3-da33d730389d ro pcie_aspm=off intel_idle.max_cstate=3 quiet ** Not tainted ** Kernel log: 2023-12-24T09:34:02.980398+00:00 [REDACTED] kernel: Linux version 6.5.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 13.2.0-7) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC Debian 6.5.13-1 (2023-11-29) 2023-12-24T09:34:02.980403+00:00 [REDACTED] kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.5.0-5-amd64 root=UUID=3f51e9a7-af14-4c6d-a6f3-da33d730389d ro pcie_aspm=off intel_idle.max_cstate=3 quiet 2023-12-24T09:34:02.980404+00:00 [REDACTED] kernel: BIOS-provided physical RAM map: 2023-12-24T09:34:02.980405+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x-0x0005dfff] usable 2023-12-24T09:34:02.980406+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x0005e000-0x0005efff] reserved 2023-12-24T09:34:02.980407+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x0005f000-0x0009] usable 2023-12-24T09:34:02.980407+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x000a-0x000f] reserved 2023-12-24T09:34:02.980410+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x0010-0x8dbcafff] usable 2023-12-24T09:34:02.980411+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x8dbcb000-0x8eefafff] reserved 2023-12-24T09:34:02.980411+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x8eefb000-0x8f02afff] ACPI data 2023-12-24T09:34:02.980412+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x8f02b000-0x8f460fff] ACPI NVS 2023-12-24T09:34:02.980413+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x8f461000-0x8f993fff] reserved 2023-12-24T09:34:02.980413+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x8f994000-0x8fc4dfff] type 20 2023-12-24T09:34:02.980414+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x8fc4e000-0x8fc4efff] usable 2023-12-24T09:34:02.980416+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x8fc4f000-0x9b7f] reserved 2023-12-24T09:34:02.980417+00:00 [REDACTED] kernel: BIOS-e820: [mem 0xe000-0xefff] reserved 2023-12-24T09:34:02.980418+00:00 [REDACTED] kernel: BIOS-e820: [mem 0xfe00-0xfe010fff] reserved 2023-12-24T09:34:02.980418+00:00 [REDACTED] kernel: BIOS-e820: [mem 0xfec0-0xfec00fff] reserved 2023-12-24T09:34:02.980419+00:00 [REDACTED] kernel: BIOS-e820: [mem 0xfed0-0xfed03fff] reserved 2023-12-24T09:34:02.980420+00:00 [REDACTED] kernel: BIOS-e820: [mem 0xfee0-0xfee00fff] reserved 2023-12-24T09:34:02.980422+00:00 [REDACTED] kernel: BIOS-e820: [mem 0xff00-0x] reserved 2023-12-24T09:34:02.980422+00:00 [REDACTED] kernel: BIOS-e820: [mem 0x0001-0x0004627f] usable 2023-12-24T09:34:02.980423+00:00 [REDACTED] kernel: NX (Execute Disable) protection: active 2023-12-24T09:34:02.980424+00:00 [REDACTED] kernel: efi: EFI v2.7 by American Megatrends 2023-12-24T09:34:02.980424+00:00 [REDACTED] kernel: efi: ACPI=0x8f419000 ACPI 2.0=0x8f419014 TPMFinalLog=0x8f41f000 SMBIOS=0x8f802000 SMBIOS 3.0=0x8f801000
Bug#1037034: coreutils: manifest still uses "/bin" although files are in "/usr/bin"
Package: coreutils Version: 9.1-1 Severity: minor On Debian 12 "/bin" has been changed to a symbolic link that points to "/usr/bin": > ls -l /bin lrwxrwxrwx 1 root root 7 May 14 08:39 /bin -> usr/bin However the package manifest of "coreutils" still claims that files are located in "/bin". This is confusing when the user tries to determine which package owns a file: > which ls /usr/bin/ls > dpkg -S /usr/bin/ls dpkg-query: no path found matching pattern /usr/bin/ls > dpkg -S /bin/ls coreutils: /bin/ls This oddity is not even consistent for the "coreutils" package: > which seq /usr/bin/seq > dpkg -S /usr/bin/seq coreutils: /usr/bin/seq > dpkg -S /bin/seq dpkg-query: no path found matching pattern /bin/seq I suspect that many more packages are affected. -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages coreutils depends on: ii libacl1 2.3.1-3 ii libattr1 1:2.5.1-4 ii libc62.36-9 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libselinux1 3.4-1+b5 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information
Bug#931544: arpwatch: "arpwatch" not started by "systemd" service file
On Sun, Jul 07, 2019 at 07:15:11PM +0200, Salvatore Bonaccorso wrote:
> > So the real bug here seems to be that the APT changes don't mention
> > this updated systemd configuration mechanism. And the existing comment
> > in "/etc/default/arpwatch" will not be visible on update systems,
> > at least not if the configuration file was change.
>
> Thanks a lot for your quick turnaround and feedback.
>
> Let's keep the bug open, maybe documenting that more prominently would
> make sense?
Yes, that would probably be helpful.
Thanks again for your help
--
Matthias Scheler http://zhadum.org.uk/
Bug#931544: arpwatch: "arpwatch" not started by "systemd" service file
On Sun, Jul 07, 2019 at 03:17:12PM +0200, Salvatore Bonaccorso wrote: > On Sun, Jul 07, 2019 at 01:03:17PM +0100, Matthias Scheler wrote: > > Package: arpwatch > > Version: 2.1a15-7 > > Severity: grave > > Tags: patch > > Justification: renders package unusable > > I do not think this severity is warranted, ... It is indeed not warranted with the information that you kindly provided. I marked this as "grave" because after an update from Debian 9 to 10 "arpwatch" was no longer working. Even a "systemctl restart arpwatch" couldn't bring the service back to life. > ... this is because of, the following as from /etc/default/arpwatch This file was already present on my system and didn't get overwritten by the update from Debian 9 to 10. > # when using systemd you have to enable arpwatch explicitly for each interface > # you want to run it on by running: > # systemctl enable arpwatch@IFACE > # systemctl start arpwatch@IFACE [...] > by the sysvinit service. > > Does this help? That does indeed solve the problem. Thank you very much. So the real bug here seems to be that the APT changes don't mention this updated systemd configuration mechanism. And the existing comment in "/etc/default/arpwatch" will not be visible on update systems, at least not if the configuration file was change. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Bug#931544: arpwatch: "arpwatch" not started by "systemd" service file
Package: arpwatch Version: 2.1a15-7 Severity: grave Tags: patch Justification: renders package unusable Hello, the "arpwatch" process is not started by "systemd". The reason seems to be an error in "/lib/systemd/system/arpwatch.service". ExecStart=/bin/true Changig the line to ... ExecStart=/usr/sbin/arpwatch ... fixes the problem for me. Kind regards -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages arpwatch depends on: ii adduser 3.118 ii gawk1:4.2.1+dfsg-1 ii libc6 2.28-10 ii libpcap0.8 1.8.1-6 ii lsb-base10.2019051400 Versions of packages arpwatch recommends: ii ieee-data 20180805.1 arpwatch suggests no packages. -- no debconf information
Bug#912696: emacs: default emacs X11 window is very small
Hello, this is not a Debian specific bug. The same happens under Fedora (see https://bugzilla.redhat.com/show_bug.cgi?id=1353063) and with Emacs built from "pkgrsc". It seems to be related to GTK+ 3 because building Emacs 26.1 using GTK+ 2 avoids the problem. Kind regards -- Matthias Scheler https://zhadum.org.uk/
