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=3D241980 --- Comment #20 from Eugene Grosbein <eugen@freebsd.org> --- This is dedicated server in Hetzner. Well, it has another SATA controller s= een as: ahci0@pci0:0:17:5: class=3D0x010601 card=3D0x07161028 chip=3D0xa1d2808= 6 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'C620 Series Chipset Family SSATA Controller [AHCI mode]' class =3D mass storage subclass =3D SATA But first I'd like to disable panicing by zfs_deadman and see if distinct Z= FS boot pool is alive in such moment. I already tried booting patched zfs.ko by means of nextboot.conf and module_path=3D"/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. --=20 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>