I just discovered this oops in my dmesg. Everythign seems to work still fine though. But maybe its worth reporting. Do you need anything else like .config? [1833124.816056] ------------[ cut here ]------------ [1833124.816071] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xe9/0x148() [1833124.816073] Hardware name: System Product Name [1833124.816076] NETDEV WATCHDOG: eth0 (ATL1E): transmit queue 0 timed out [1833124.816078] Modules linked in: udf crc_itu_t xt_hl nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_snmp nf_conntrack_broadcast ip6table_filter ip6_tables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables nfsd tun bridge stp llc btrfs crc32c libcrc32c sha256_generic kvm_amd kvm k8temp st hwmon i2c_piix4 pcspkr floppy atl1e scsi_transport_iscsi fuse xfs exportfs nfs nfs_acl auth_rpcgss lockd sunrpc zlib_deflate raid10 raid456 async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx raid0 dm_snapshot dm_crypt scsi_wait_scan usb_storage aic7xxx sr_mod cdrom sg [1833124.816119] Pid: 21655, comm: kworker/1:3 Not tainted 3.0.6-gentoo #1 [1833124.816121] Call Trace: [1833124.816123] <IRQ> [<ffffffff8103fe33>] ? warn_slowpath_common+0x78/0x8c [1833124.816131] [<ffffffff8103fee8>] ? warn_slowpath_fmt+0x45/0x4a [1833124.816134] [<ffffffff813869d5>] ? netif_tx_lock+0x43/0x76 [1833124.816138] [<ffffffff81386b3c>] ? dev_watchdog+0xe9/0x148 [1833124.816142] [<ffffffff8104bc44>] ? run_timer_softirq+0x1b7/0x27a [1833124.816145] [<ffffffff81386a53>] ? netif_tx_unlock+0x4b/0x4b [1833124.816149] [<ffffffff81045283>] ? __do_softirq+0xb5/0x170 [1833124.816153] [<ffffffff8143338c>] ? call_softirq+0x1c/0x30 [1833124.816158] [<ffffffff8100386e>] ? do_softirq+0x31/0x67 [1833124.816161] [<ffffffff810454e3>] ? irq_exit+0x3f/0xa3 [1833124.816164] [<ffffffff810035e1>] ? do_IRQ+0x85/0x9e [1833124.816167] [<ffffffff8142c713>] ? common_interrupt+0x13/0x13 [1833124.816169] <EOI> [<ffffffff811bad54>] ? crypto_cbc_decrypt_inplace.clone.3+0x9c/0xef [1833124.816178] [<ffffffff81027bc4>] ? dec128+0x80c/0x80c [1833124.816181] [<ffffffff811bae01>] ? crypto_cbc_decrypt+0x5a/0x125 [1833124.816185] [<ffffffff811b6c61>] ? async_decrypt+0x34/0x39 [1833124.816192] [<ffffffffa005015d>] ? crypt_iv_essiv_gen+0x30/0x37 [dm_crypt] [1833124.816197] [<ffffffffa0050ef9>] ? crypt_convert+0x232/0x2d7 [dm_crypt] [1833124.816202] [<ffffffffa0051185>] ? kcryptd_async_done+0xf1/0xf1 [dm_crypt] [1833124.816206] [<ffffffffa0051224>] ? kcryptd_crypt+0x9f/0x44c [dm_crypt] [1833124.816210] [<ffffffff8105474e>] ? process_one_work+0x191/0x299 [1833124.816215] [<ffffffffa0051185>] ? kcryptd_async_done+0xf1/0xf1 [dm_crypt] [1833124.816220] [<ffffffffa0051185>] ? kcryptd_async_done+0xf1/0xf1 [dm_crypt] [1833124.816223] [<ffffffff8105474e>] ? process_one_work+0x191/0x299 [1833124.816226] [<ffffffff810558e1>] ? worker_thread+0xeb/0x16a [1833124.816229] [<ffffffff810557f6>] ? manage_workers.clone.17+0x157/0x157 [1833124.816233] [<ffffffff810557f6>] ? manage_workers.clone.17+0x157/0x157 [1833124.816236] [<ffffffff81058968>] ? kthread+0x7a/0x82 [1833124.816250] [<ffffffff81433294>] ? kernel_thread_helper+0x4/0x10 [1833124.816254] [<ffffffff810588ee>] ? kthread_worker_fn+0x135/0x135 [1833124.816256] [<ffffffff81433290>] ? gs_change+0xb/0xb [1833124.816259] ---[ end trace 43d7dd573b304da7 ]---
Has this problem reoccurred?
This seems to fixed. I did not see it for a long time now. What is left is a reasonable amount of "jme 0000:03:00.0: eth0: UDP Checksum error" messages (or the same with TCP). According to the author of the driver this may be a general problem of that network chip though. I think this bug can be closed.
Thanks for the quick reply.
