[Bug 241980] panic: I/O to pool appears to be hung on vdev

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241980 --- Comment #24 from Eugene Grosbein --- After continuous stream of debugging messages stopped at 06:28:26, messages appeared again but only 3 times: one at 06:57:20 (all ZIO_TYPE_FREE), one at 06:57:25 (all ZIO_TYPE_FREE) and last at 06:57

[Bug 241980] panic: I/O to pool appears to be hung on vdev

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241980 --- Comment #23 from Eugene Grosbein --- As I've suspected, ZFS issues large number of BIO_DELETE/ZIO_TYPE_FREE requests due to massive removal of hourly/daily snapshots for this SSD-only pool. Clearing of SSD cells may be slow. The system

[Bug 242184] r354398 causes panic in nfs_unmount during shutdown

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242184 Bug ID: 242184 Summary: r354398 causes panic in nfs_unmount during shutdown Product: Base System Version: 12.0-STABLE Hardware: amd64 OS: Any Status: New

[Bug 241980] panic: I/O to pool appears to be hung on vdev

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241980 Eugene Grosbein changed: What|Removed |Added Attachment #209178|0 |1 is obsolete|

[Bug 241980] panic: I/O to pool appears to be hung on vdev

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241980 --- Comment #21 from Eugene Grosbein --- It took me unexpectedly long time to get debugging output as I struggled to force the loader perform one-time (nextboot) loading for patched zfs.ko being able to perform only one reboot per day for t

[Bug 242106] [panic] zfree(0xe4e9690,8224): wild pointer during install from 12.1R amd64 ISO in Parallels VM

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242106 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|virtualizat...@freebsd.org -- You

[Bug 242159] [em] I219-V connection lost under load

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242159 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiv

[Bug 241710] please increase ARG_MAX

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241710 --- Comment #21 from Pedro F. Giffuni --- (In reply to Thierry Thomas from comment #20) Hmm ... While we need a fix for this issue for Code Aster (rather important package in my line of engineering, so yes .. I am biased), we need a soluti

[Bug 242164] Suspend fail on MS-7507 after upgrade to 12.1

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242164 Mark Linimon changed: What|Removed |Added Keywords||regression -- You are receiving th

[Bug 241639] Fatal trap 12: page fault ... current process = 0 (vmbusdev) when using mlx4en

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241639 --- Comment #12 from Alexander Motin --- As I have answered to private email from originator, mine mentioned commit changed imeplementation of kern.cam.boot_delay withing its original semantics. The fact that it is no longer possible to us

[Bug 242180] kern.cam.boot_delay="10000" parameter in /boot/loader.conf stopped working. Catastrophe!

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242180 Mark Linimon changed: What|Removed |Added Keywords||regression CC|

[Bug 242180] kern.cam.boot_delay="10000" parameter in /boot/loader.conf stopped working. Catastrophe!

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242180 Bug ID: 242180 Summary: kern.cam.boot_delay="1" parameter in /boot/loader.conf stopped working. Catastrophe! Product: Base System Version: CURRENT Hardware: amd64

[Bug 241639] Fatal trap 12: page fault ... current process = 0 (vmbusdev) when using mlx4en

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241639 --- Comment #11 from Michael --- After applying the 4a46b2449c63e010014dc0fb2a3caa5e20b97933 commit, the kern.cam.boot_delay="1" parameter in /boot/loader.conf stopped working. Catastrophe! Now I have to load mlx4en.ko in firewall rules

[Bug 235017] 12.0-RELEASE (12.1 too) hangs at boot from official iso

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235017 --- Comment #7 from VVD --- (In reply to Denis Polygalov from comment #6) Weird, your CPU is almost same: CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3400.19-MHz K8-class CPU) Origin="GenuineIntel" Id=0xf43 Family=0xf Model=0x4 Stepping=3 F