Kern.log和Syslog不受控制地增长(详细信息)

类似于其他关于kern.log和syslog中无法控制的膨胀的问题,但就我而言,我无法确定内核中的原因是什么,因为我不认识该过程,而我对其进行的google搜索也没有帮助我许多。

两个单独的raspberry pi 4’将Ubuntu 20.04运行了几个星期。一切都好。昨晚,我执行了标准的apt升级,然后我的kern.log和syslog开始以每小时约0.5-1 Gb的速度不受控制地增长,现在我不得不一遍又一遍地将它们截断,而我试图弄清楚这是什么填充了内核日志。这是尾部kern.log文件的输出。就是如此,一遍又一遍,每秒重复100次。

5月23日07:43:03 raspi2内核:[12298.982475]警告:CPU:0 PID:4409在drivers / mmc / host / sdhci.c:1101 sdhci_prepare_data + 0x3dc / 0x7b0 5月23日7时43分03秒raspi2内核:[12298.982478]模块连接在:binfmt_misc iptable_filter bpfilter dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua btsdio蓝牙ecdh_generic ECC brcmfmac bcm2835_v4l2(CE)brcmutil bcm2835_mmal_vchiq(CE)videobuf2_vmalloc videobuf2_memops snd_bcm2835(CE)videobuf2_v4l2 cfg80211 videobuf2_common snd_pcm videodev snd_timer MC SND raspberrypi_hwmon vc_sm_cma(CE)rpivid_mem uio_pdrv_genirq UIO sch_fq_codel DRM ip_tables都是x_tables autofs4 BTRFS zstd_compress RAID10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx XOR xor_neon raid6_pq libcrc32c RAID1 RAID0多径线性crct10dif_ce spidev phy_generic SES外壳scsi_transport_sas UAS usb_storage aes_neon_bs aes_neon_blk crypto_simd cryptd 5月23日07:43:03 raspi2内核:[12298.982532] CPU:0 PID:4409 Comm:kworker / 0:0H污染:G WC E 5.4.0-1011-raspi#11-Ubuntu 5月23日07:43:03 raspi2内核:[12298.982533]硬件名称:Raspberry Pi 4 Model B Rev 1.2(DT) 5月23日07:43:03 raspi2内核:[12298.982545]工作队列:kblocked blk_mq_run_work_fn 5月23日07:43:03 raspi2内核:[12298.982551] pstate:a0400085(NzCv daIf + PAN -UAO) 5月23日07:43:03 raspi2内核:[12298.982553] pc:sdhci_prepare_data + 0x3dc / 0x7b0 5月23日07:43:03 raspi2内核:[12298.982556] lr:sdhci_prepare_data + 0x2cc / 0x7b0 5月23日07:43:03 raspi2内核:[12298.982557] sp:ffff80001156b9b0 5月23日07:43:03 raspi2内核:[12298.982558] x29:ffff80001156b9b0 x28:ffff0000eb62ec00 5月23日07:43:03 raspi2内核:[12298.982560] x27:0000000000000002 x26:0000000000000000 5月23日07:43:03 raspi2内核:[12298.982562] x25:ffff0000eb5e7000 x24:ffff0000eb5e7580 5月23日07:43:03 raspi2内核:[12298.982564] x23:0000000000418958 x22:ffff0000eb06a158 5月23日07:43:03 raspi2内核:[12298.982566] x21:ffff0000277d0000 x20:ffff0000eb06a1d8 5月23日07:43:03 raspi2内核:[12298.982568] x19:ffff0000eb5e7580 x18:0000000000000000 5月23日07:43:03 raspi2内核:[12298.982570] x17:0000000000000000 x16:0000000000000000 5月23日07:43:03 raspi2内核:[12298.982572] x15:0000000000000000 x14:622061756c615f68 5月23日07:43:03 raspi2内核:[12298.982574] x13:645f697363732063 x12:6d655f68645f6973 5月23日07:43:03 raspi2内核:[12298.982576] x11:637320636164725f x10:68645f6973637320 5月23日07:43:03 raspi2内核:[12298.982577] x9:6874617069746c75 x8:6d5f6d6420726574 5月23日07:43:03 raspi2内核:[12298.982579] x7:6c69667062207265 x6:ffffcb8fd5209a44 5月23日07:43:03 raspi2内核:[12298.982581] x5:ffffffffffffffffff x4:0000000000000020 5月23日07:43:03 raspi2内核:[12298.982583] x3:0000000000000001 x2:fffffe0003581300 5月23日07:43:03 raspi2内核:[12298.982585] x1:fffffe0003581300 x0:00000000ffffffe4 5月23日07:43:03 raspi2内核:[12298.982588]调用跟踪: 5月23日07:43:03 raspi2内核:[12298.982591] sdhci_prepare_data + 0x3dc / 0x7b0 5月23日07:43:03 raspi2内核:[12298.982593] sdhci_send_command + 0xe0 / 0x5f0 5月23日07:43:03 raspi2内核:[12298.982595] sdhci_request + 0x110 / 0x150 5月23日07:43:03 raspi2内核:[12298.982599] __mmc_start_request + 0x88 / 0x1a8 5月23日07:43:03 raspi2内核:[12298.982601] mmc_start_request + 0x98 / 0xc0 5月23日07:43:03 raspi2内核:[12298.982603] mmc_blk_mq_issue_rq + 0x30c / 0x778 5月23日07:43:03 raspi2内核:[12298.982605] mmc_mq_queue_rq + 0x14c / 0x320 5月23日07:43:03 raspi2内核:[12298.982608] blk_mq_dispatch_rq_list + 0xa4 / 0x5f8 5月23日07:43:03 raspi2内核:[12298.982612] blk_mq_do_dispatch_sched + 0x68 / 0x108 5月23日07:43:03 raspi2内核:[12298.982614] blk_mq_sched_dispatch_requests + 0x164 / 0x1c0 5月23日07:43:03 raspi2内核:[12298.982617] __blk_mq_run_hw_queue + 0xfc / 0x158 5月23日07:43:03 raspi2内核:[12298.982619] blk_mq_run_work_fn + 0x28 / 0x38 5月23日07:43:03 raspi2内核:[12298.982622] process_one_work + 0x1d0 / 0x430 5月23日07:43:03 raspi2内核:[12298.982624] worker_thread + 0x54 / 0x4a0 5月23日07:43:03 raspi2内核:[12298.982628] kthread + 0xfc / 0x128 5月23日07:43:03 raspi2内核:[12298.982631] ret_from_fork + 0x10 / 0x1c 5月23日07:43:03 raspi2内核:[12298.982634] --- [结束跟踪a7bb7a8fcc54873a]-

一遍又一遍,直到日志填满磁盘。如上所述,两个pi的情况完全相同,只是我对它们所做的更改是通过apt升级进行升级。

看起来像是带有sdhci的东西,但我无法弄清楚:a)升级的哪个部分导致了此操作的开始[为什么现在没有发生这种情况],以及b)如何解决根本的问题。

由于操作对于我的系统而言似乎是正常的,我是否只需要告诉rsyslog忽略来自sdhci的消息?我实际上想解决此问题,而不仅仅是在可行的情况下忽略它。

谢谢!