类似于有关 kern.log 和 syslog 中无法控制的膨胀的其他问题,但在我的情况下,我无法弄清楚内核中的原因是什么,因为我不认识这个过程并且我的谷歌搜索没有帮助我很多。
两个独立的树莓派 4 运行 Ubuntu 20.04 数周。一切都好。昨晚,我运行了一个标准的 apt 升级,然后我的 kern.log 和 syslog 开始以每小时 0.5-1 Gb 的速度不受控制地增长,现在我在试图弄清楚时一次又一次地截断它们这是什么填充内核日志。这是尾随 kern.log 文件的输出。就是这样一遍又一遍地重复,每秒100次。
May 23 07:43:03 raspi2 kernel: [12298.982475] WARNING: CPU: 0 PID: 4409 at drivers/mmc/host/sdhci.c:1101 sdhci_prepare_data+0x3dc/0x7b0
May 23 07:43:03 raspi2 kernel: [12298.982478] Modules linked in: binfmt_misc iptable_filter bpfilter dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua btsdio bluetooth 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 multipath linear crct10dif_ce spidev phy_generic ses enclosure scsi_transport_sas uas usb_storage aes_neon_bs aes_neon_blk crypto_simd cryptd
May 23 07:43:03 raspi2 kernel: [12298.982532] CPU: 0 PID: 4409 Comm: kworker/0:0H Tainted: G WC E 5.4.0-1011-raspi #11-Ubuntu
May 23 07:43:03 raspi2 kernel: [12298.982533] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT)
May 23 07:43:03 raspi2 kernel: [12298.982545] Workqueue: kblockd blk_mq_run_work_fn
May 23 07:43:03 raspi2 kernel: [12298.982551] pstate: a0400085 (NzCv daIf +PAN -UAO)
May 23 07:43:03 raspi2 kernel: [12298.982553] pc : sdhci_prepare_data+0x3dc/0x7b0
May 23 07:43:03 raspi2 kernel: [12298.982556] lr : sdhci_prepare_data+0x2cc/0x7b0
May 23 07:43:03 raspi2 kernel: [12298.982557] sp : ffff80001156b9b0
May 23 07:43:03 raspi2 kernel: [12298.982558] x29: ffff80001156b9b0 x28: ffff0000eb62ec00
May 23 07:43:03 raspi2 kernel: [12298.982560] x27: 0000000000000002 x26: 0000000000000000
May 23 07:43:03 raspi2 kernel: [12298.982562] x25: ffff0000eb5e7000 x24: ffff0000eb5e7580
May 23 07:43:03 raspi2 kernel: [12298.982564] x23: 0000000000418958 x22: ffff0000eb06a158
May 23 07:43:03 raspi2 kernel: [12298.982566] x21: ffff0000277d0000 x20: ffff0000eb06a1d8
May 23 07:43:03 raspi2 kernel: [12298.982568] x19: ffff0000eb5e7580 x18: 0000000000000000
May 23 07:43:03 raspi2 kernel: [12298.982570] x17: 0000000000000000 x16: 0000000000000000
May 23 07:43:03 raspi2 kernel: [12298.982572] x15: 0000000000000000 x14: 622061756c615f68
May 23 07:43:03 raspi2 kernel: [12298.982574] x13: 645f697363732063 x12: 6d655f68645f6973
May 23 07:43:03 raspi2 kernel: [12298.982576] x11: 637320636164725f x10: 68645f6973637320
May 23 07:43:03 raspi2 kernel: [12298.982577] x9 : 6874617069746c75 x8 : 6d5f6d6420726574
May 23 07:43:03 raspi2 kernel: [12298.982579] x7 : 6c69667062207265 x6 : ffffcb8fd5209a44
May 23 07:43:03 raspi2 kernel: [12298.982581] x5 : ffffffffffffffff x4 : 0000000000000020
May 23 07:43:03 raspi2 kernel: [12298.982583] x3 : 0000000000000001 x2 : fffffe0003581300
May 23 07:43:03 raspi2 kernel: [12298.982585] x1 : fffffe0003581300 x0 : 00000000ffffffe4
May 23 07:43:03 raspi2 kernel: [12298.982588] Call trace:
May 23 07:43:03 raspi2 kernel: [12298.982591] sdhci_prepare_data+0x3dc/0x7b0
May 23 07:43:03 raspi2 kernel: [12298.982593] sdhci_send_command+0xe0/0x5f0
May 23 07:43:03 raspi2 kernel: [12298.982595] sdhci_request+0x110/0x150
May 23 07:43:03 raspi2 kernel: [12298.982599] __mmc_start_request+0x88/0x1a8
May 23 07:43:03 raspi2 kernel: [12298.982601] mmc_start_request+0x98/0xc0
May 23 07:43:03 raspi2 kernel: [12298.982603] mmc_blk_mq_issue_rq+0x30c/0x778
May 23 07:43:03 raspi2 kernel: [12298.982605] mmc_mq_queue_rq+0x14c/0x320
May 23 07:43:03 raspi2 kernel: [12298.982608] blk_mq_dispatch_rq_list+0xa4/0x5f8
May 23 07:43:03 raspi2 kernel: [12298.982612] blk_mq_do_dispatch_sched+0x68/0x108
May 23 07:43:03 raspi2 kernel: [12298.982614] blk_mq_sched_dispatch_requests+0x164/0x1c0
May 23 07:43:03 raspi2 kernel: [12298.982617] __blk_mq_run_hw_queue+0xfc/0x158
May 23 07:43:03 raspi2 kernel: [12298.982619] blk_mq_run_work_fn+0x28/0x38
May 23 07:43:03 raspi2 kernel: [12298.982622] process_one_work+0x1d0/0x430
May 23 07:43:03 raspi2 kernel: [12298.982624] worker_thread+0x54/0x4a0
May 23 07:43:03 raspi2 kernel: [12298.982628] kthread+0xfc/0x128
May 23 07:43:03 raspi2 kernel: [12298.982631] ret_from_fork+0x10/0x1c
May 23 07:43:03 raspi2 kernel: [12298.982634] ---[ end trace a7bb7a8fcc54873a ]---
一遍又一遍,直到日志填满磁盘。两个 pi 上的情况完全相同,我对它们所做的唯一更改是通过 apt upgrade 进行升级,如上所述。
看起来像 sdhci 的东西,但我不知道:a)升级的哪一部分导致这个开始[为什么以前没有发生这种情况] 和 b)如何解决潜在问题。
由于我的系统的操作看起来很正常,我是否只需要告诉 rsyslog 忽略来自 sdhci 的消息?我实际上想解决这个问题,而不是在可行时忽略。
谢谢!
我今天遇到了同样的问题(kern.log 增长很快;大约 2GB)并使用以下命令将内核降级到以前的版本:
从系统中删除 1001 版本:
重新安装以前版本的内核、模块和头文件:
我使用以前的内核版本成功地重新启动了 PI4。下一步是从更新中排除内核,直到问题得到解决:
之后,您可以删除未使用的内核版本:
从你的系统。
我的系统安装历史: