Date: Wed, 20 Nov 2019 09:31:36 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 241980] panic: I/O to pool appears to be hung on vdev Message-ID: <bug-241980-227-QwbIST2Bun@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-241980-227@https.bugs.freebsd.org/bugzilla/> References: <bug-241980-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241980 --- Comment #20 from Eugene Grosbein <eugen@freebsd.org> --- This is dedicated server in Hetzner. Well, it has another SATA controller seen as: ahci0@pci0:0:17:5: class=0x010601 card=0x07161028 chip=0xa1d28086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'C620 Series Chipset Family SSATA Controller [AHCI mode]' class = mass storage subclass = SATA But first I'd like to disable panicing by zfs_deadman and see if distinct ZFS boot pool is alive in such moment. I already tried booting patched zfs.ko by means of nextboot.conf and module_path="/boot/nextboot;/boot/kernel;/boot/modules". Additionally, I've enabled hardware watchdog in BIOS setup (the server has distinct public IP for console via virtual KVM) and enabled watchdogd. Sadly, I made a misprint and it booted with default unpatched zfs.ko and I missed that, so another same panic that occured today gave me little but interesting information: the watchdog works and dmesg buffer is not cleared between reboots, so I have KDB trace in /var/log/kernel.log after reboot (kern.* messages logged there). I've fixed the misprint, will reboot again and wait. Thank you for your remark about early warning, now I see you are right. I'll fix it. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-241980-227-QwbIST2Bun>