Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #929549
| From | Cesare Leonardi <celeonar@gmail.com> |
|---|---|
| Newsgroups | linux.debian.bugs.dist, linux.debian.kernel |
| Subject | Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1 |
| Date | 2018-11-24 00:50 +0100 |
| Message-ID | <wXtmV-7o7-1@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <wWYMa-56M-13@gated-at.bofh.it> <wWYMa-56M-11@gated-at.bofh.it> <wWYMa-56M-11@gated-at.bofh.it> <wWYMa-56M-13@gated-at.bofh.it> <wWYMa-56M-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Cross-posted to 2 groups.
Bug still present with the new 4.18.0-3-amd64 (4.18.20-1). This morning I've tryed to boot this new kernel version, removing the workaround given by the following kernel parameters: scsi_mod.use_blk_mq=0 dm_mod.use_blk_mq=0 The system showed disk hangs in less than 5 hours, and, as in previous 4.17 and 4.18, normal disk activities was restored after some minutes, without apparent data loss. I experienced two hangs before rebooting, but one of them didn't produce an oops in dmesg. It was not the first time I saw an hang without oops: maybe those that can recover in less than 120 seconds, doesn't produce oopses in dmesg? And just to be clear, it doesn't seem a bug related to LVM but more precisely to various types (all?) of LVM RAID. In fact my notebook disk uses LVM linear volumes and never showed those hangs and oopses. Cesare.
Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1 Cesare Leonardi <celeonar@gmail.com> - 2018-11-22 16:10 +0100
Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1 Cesare Leonardi <celeonar@gmail.com> - 2018-11-24 00:50 +0100
Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1 Cesare Leonardi <celeonar@gmail.com> - 2018-11-24 02:30 +0100
csiph-web