Bug#925496: Fix available upstream

Control: tags -1 + fixed-upstream The workaround is included in upstream v4.19.35 onwards: b787544dc5e707fec86161b881391eb9342806e6. Mike.

Bug#925496: Fix pending upstream

Control: found -1 linux/4.19.28-2 Control: tags -1 + patch The upstream maintainer has provided a workaround[1] for this which has apparently been queued[2] for stable, so I imagine that the fix will be merged in due course. Mike. [1] https://lore.kernel.org/netdev/e2e76e38-3155-e421-deeb-4ec05

Bug#925496: Problem comes back with "EPU Power Saving Mode" enabled in the BIOS

Control: reopen -1 Control: found linux/4.19.28-2 Control: tags upstream I wrote: > However, this inspired me to check the BIOS version on the Asus H87M-E > motherboards we're using. Both were using the rather ancient version > 1001. I upgraded one machine to the latest version 2201 and the proble

Bug#925496: Introduced between v4.18 and v4.19, not fixed in v5.0

I've tested some other kernel versions. In the description below, "fast" means that the NFS clients booted quickly (~20s) whereas "slow" means that the NFS clients booted slowly (~100s). In all cases, rx-usecs=200, rx-frames=4. Debian versions: v4.18.0-3-amd64: fast (not tested recently) v4.19.0

Bug#925496: linux-image-4.19.0-2-amd64: Latency increase with r8169 and default coalescing settings

Package: src:linux Version: 4.19.16-1 Severity: normal After upgrading the "server" from Stretch to Buster, performance of our embedded client devices which mount their root filesystem over NFSv2 from said server dropped considerably. The time from mount to full system operation of these clients w

Bug#869886: Problem goes away when downgrading to Jessie 3.16 kernel

Previously, I wrote: > A few days after upgrading to Stretch and its 4.9 kernel we got an RCU > stall in the middle of the night: A series of very-similar-looking RCU stalls happened again a week later. The machine is under moderate load most of the time. I switched to running Jessie's kernel, an

Bug#869886: linux-image-4.9.0-3-amd64: rcu_sched self-detected stall on CPU in nfs_reap_expired_delegations

Package: src:linux Version: 4.9.30-2+deb9u2 Severity: important Dear Maintainer, This particular machine has successfully been running Debian for many years, through Lenny to Jessie. It looks like I needed to add "nointremap" to the kernel command line when it was upgraded to Wheezy back in 2013.

Bug#777683: Disabling TSO may avoid the problem

I seem to be seeing the same problem on: 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux with: 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 05) Subsystem: Intel Corporation Device 2002 Flags: bus master, fast de

Bug#779350: linux-image-3.2.0-4-amd64: Bridge no longer passes some multicast packets

Package: src:linux Version: 3.2.65-1+deb7u2 Severity: normal Dear Maintainer, Upon upgrading my linux-image-3.2.0-4-amd64 package from 3.2.65-1+deb7u1 to 3.2.65-1+deb7u2 it appears that my bridge device is no longer able to pass (at least some) multicast packets. I've reproduced the problem on t

Bug#754354: Something holds dentry-related mutex forever in Wheezy amd64 kernel

On Sunday 28 September 2014 at 15:01:21 +0100, Ben Hutchings wrote: > On Sat, 2014-09-27 at 19:41 +0100, Mike Crowe wrote: > > I compiled my own version of the Debian 3.2.60-1+deb7u3 kernel with > > CONFIG_LOCKDEP and panic on hung task enabled. > > >

Bug#754354: Something holds dentry-related mutex forever in Wheezy amd64 kernel

I compiled my own version of the Debian 3.2.60-1+deb7u3 kernel with CONFIG_LOCKDEP and panic on hung task enabled. >From the crash dump: [25202.156175] INFO: task nfsd:3247 blocked for more than 900 seconds. [25202.162565] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Bug#754354: Something holds dentry-related mutex forever in Wheezy amd64 kernel

On Monday 21 July 2014 at 15:01:31 +0100, Mike Crowe wrote: > It is possible that I'm seeing the same problem. Our AMD Opteron 4386 (16 > cores) machine is also getting stuck with lots of hung tasks. [snip] > PID: 4087 TASK: 88040ea63840 CPU: 2 COMMAND: "nfsd"

Bug#754354: Something holds dentry-related mutex forever in Wheezy amd64 kernel

It is possible that I'm seeing the same problem. Our AMD Opteron 4386 (16 cores) machine is also getting stuck with lots of hung tasks. Although it responds to ping, and even a KVM virtual machine running on it appears to continue working correctly, the host itself is locked up. This happens once

Bug#517716: Acknowledgement (linux-image-2.6.26-1-686: ehci_hcd 0000:00:02.2: HC died; cleaning up when importing photographs via PTP using gthumb)

Unfortunately the motherboard that I saw this problem on died. :( I tried to reproduce it on my new Intel motherboard using linux-image-2.6.26-2-686 v2.6.26-24 but could not do so. Thanks. Mike. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscrib

Bug#517716: Acknowledgement (linux-image-2.6.26-1-686: ehci_hcd 0000:00:02.2: HC died; cleaning up when importing photographs via PTP using gthumb)

Further to my original report I've done some more experiments and noted that: - The problem does indeed seem to be file size related. Small images and video files do not cause the host controller to die. A transfer of four video files totalling over 700MiB did cause the failure. - The system

Bug#517716: linux-image-2.6.26-1-686: ehci_hcd 0000:00:02.2: HC died; cleaning up when importing photographs via PTP using gthumb

Package: linux-image-2.6.26-1-686 Version: 2.6.26-13 Severity: normal When downloading pictures from one of my PTP cameras my USB host controller appears to "die". Pictures that have been successfully transferred are not deleted from the camera. The ports connected to that controller don't work un