Re: em0 link fail
(replies inline) On Tue, 31 Jul 2018, R. Tyler Croy wrote: > On Wed, 25 Jul 2018, R. Tyler Croy wrote: > > > On Sun, 15 Jul 2018, Michael Butler wrote: > > > > > On 07/05/18 09:54, I wrote: > > > > On 07/05/18 09:27, tech-lists wrote: > > > >> On 03/07/2018 19:47, Michael Butler wrote: > > > >>> That would've been .. > > > >>> > > > >>> Jun 1 09:56:15 toshi kernel: FreeBSD 12.0-CURRENT #35 r334484: Fri > > > >>> Jun > > > >>> 1 08:25:58 EDT 2018 > > > >>> > > > >>> I'm going to build one with SVN r334862 reverted to see if that works, > > > >> > > > >> Is it working now? Am asking because a system I'd like to take from > > > >> 11-stable to 12 uses the em driver. > > > > > > > > No :-( I haven't had the chance yet to revisit it, > > > > > > As it turns out, SVN r336313 (committed today) solves the issue I was > > > having with the hardware stalling, > > > > I'll give r336313 a try as soon as possible and corroborate the fixes! > > After a couple days with this new build, it looks like i can corroborate the > fix referenced by Michael. :D Regrettably I spoke too soon. I've had two failures thus far today unfortunately :( It appears to be correlated either with my link state changing rapidly due to upstream fluctuations from my ISP, or a new DHCP lease being offered. Some relevant snippets from syslog around the time of the link loss: Aug 1 16:17:10 strawberry kernel: em1: link state changed to DOWN Aug 1 16:17:20 strawberry kernel: em1: link state changed to UP Aug 1 16:17:26 strawberry kernel: em1: link state changed to DOWN Aug 1 16:17:28 strawberry kernel: em1: link state changed to UP Aug 1 16:17:32 strawberry kernel: em1: link state changed to DOWN Aug 1 16:17:34 strawberry kernel: em1: link state changed to UP Aug 1 16:17:41 strawberry kernel: em1: link state changed to DOWN Aug 1 16:17:43 strawberry kernel: em1: link state changed to UP Aug 1 16:18:04 strawberry dhclient: New IP Address (em1): 173.228.82.91 Aug 1 16:18:04 strawberry dhclient: New Subnet Mask (em1): 255.255.255.0 Aug 1 16:18:04 strawberry dhclient: New Broadcast Address (em1): 173.228.82.255 Aug 1 16:18:04 strawberry dhclient: New Routers (em1): 173.228.82.1 Aug 5 22:32:32 strawberry syslogd: last message repeated 1 times Aug 5 23:44:53 strawberry kernel: em1: Watchdog timeout Queue[0]-- resetting Aug 5 23:44:53 strawberry kernel: Interface is RUNNING and ACTIVE Aug 5 23:44:53 strawberry kernel: em1: TX Queue 0 -- Aug 5 23:44:53 strawberry kernel: em1: hw tdh = 282, hw tdt = 176 Aug 5 23:44:53 strawberry kernel: em1: Tx Queue Status = -2147483648 Aug 5 23:44:53 strawberry kernel: em1: TX descriptors avail = 106 Aug 5 23:44:53 strawberry kernel: em1: Tx Descriptors avail failure = 0 Aug 5 23:44:53 strawberry kernel: em1: RX Queue 0 -- Aug 5 23:44:53 strawberry kernel: em1: hw rdh = 176, hw rdt = 174 Aug 5 23:44:53 strawberry kernel: em1: RX discarded packets = 0 Aug 5 23:44:53 strawberry kernel: em1: RX Next to Check = 175 Aug 5 23:44:53 strawberry kernel: em1: RX Next to Refresh = 174 Aug 5 23:44:53 strawberry kernel: em1: link state changed to DOWN Aug 5 23:44:55 strawberry kernel: em1: link state changed to UP Aug 5 23:46:18 strawberry dhclient: New IP Address (em1): 173.228.82.91 Aug 5 23:46:18 strawberry dhclient: New Subnet Mask (em1): 255.255.255.0 Aug 5 23:46:18 strawberry dhclient: New Broadcast Address (em1): 173.228.82.255 Aug 5 23:46:18 strawberry dhclient: New Routers (em1): 173.228.82.1 Aug 5 23:46:19 strawberry syslogd: last message repeated 1 times Aug 5 23:49:35 strawberry dhclient[12645]: send_packet: No route to host At the tail end of the syslog I was trying to get a new lease but was then unable to get a lease or restore functionality to the em1 device. This is rather perplexing to me, but I'm not savvy enough to figure out how to further be a useful debugger here :-/ Any suggestions would be appreciated! Cheers -R Tyler Croy signature.asc Description: PGP signature
Re: em0 link fail
(replies inline) On Wed, 25 Jul 2018, R. Tyler Croy wrote: > (replies inline) > > On Sun, 15 Jul 2018, Michael Butler wrote: > > > On 07/05/18 09:54, I wrote: > > > On 07/05/18 09:27, tech-lists wrote: > > >> On 03/07/2018 19:47, Michael Butler wrote: > > >>> That would've been .. > > >>> > > >>> Jun 1 09:56:15 toshi kernel: FreeBSD 12.0-CURRENT #35 r334484: Fri Jun > > >>> 1 08:25:58 EDT 2018 > > >>> > > >>> I'm going to build one with SVN r334862 reverted to see if that works, > > >> > > >> Hi, > > >> > > >> Is it working now? Am asking because a system I'd like to take from > > >> 11-stable to 12 uses the em driver. > > > > > > No :-( I haven't had the chance yet to revisit it, > > > > As it turns out, SVN r336313 (committed today) solves the issue I was > > having with the hardware stalling, > > > > I'll give r336313 a try as soon as possible and corroborate the fixes! After a couple days with this new build, it looks like i can corroborate the fix referenced by Michael. :D signature.asc Description: PGP signature
Re: em0 link fail
(replies inline)
On Sun, 15 Jul 2018, Michael Butler wrote:
> On 07/05/18 09:54, I wrote:
> > On 07/05/18 09:27, tech-lists wrote:
> >> On 03/07/2018 19:47, Michael Butler wrote:
> >>> That would've been ..
> >>>
> >>> Jun 1 09:56:15 toshi kernel: FreeBSD 12.0-CURRENT #35 r334484: Fri Jun
> >>> 1 08:25:58 EDT 2018
> >>>
> >>> I'm going to build one with SVN r334862 reverted to see if that works,
> >>
> >> Hi,
> >>
> >> Is it working now? Am asking because a system I'd like to take from
> >> 11-stable to 12 uses the em driver.
> >
> > No :-( I haven't had the chance yet to revisit it,
>
> As it turns out, SVN r336313 (committed today) solves the issue I was
> having with the hardware stalling,
Just to add a bit more metadata to this thread, I've seen this exact same
behavior for a few months now! I've recently rebuilt to r336294 which still
exhibited the problem, with periodic logs such as these:
Jul 26 04:09:53 strawberry kernel: em1: Watchdog timeout Queue[0]--
resetting
Jul 26 04:09:53 strawberry kernel: Interface is RUNNING and ACTIVE
Jul 26 04:09:53 strawberry kernel: em1: TX Queue 0 --
Jul 26 04:09:53 strawberry kernel: em1: hw tdh = 524, hw tdt = 544
Jul 26 04:09:53 strawberry kernel: em1: Tx Queue Status = -2147483648
Jul 26 04:09:53 strawberry kernel: em1: TX descriptors avail = 1004
Jul 26 04:09:53 strawberry kernel: em1: Tx Descriptors avail failure = 0
Jul 26 04:09:53 strawberry kernel: em1: RX Queue 0 --
Jul 26 04:09:53 strawberry kernel: em1: hw rdh = 172, hw rdt = 170
Jul 26 04:09:53 strawberry kernel: em1: RX discarded packets = 0
Jul 26 04:09:53 strawberry kernel: em1: RX Next to Check = 171
Jul 26 04:09:53 strawberry kernel: em1: RX Next to Refresh = 170
Jul 26 04:09:53 strawberry kernel: em1: link state changed to DOWN
Jul 26 04:09:54 strawberry kernel: em1: link state changed to UP
Jul 26 04:10:20 strawberry kernel: em1: Watchdog timeout Queue[0]--
resetting
Jul 26 04:10:20 strawberry kernel: Interface is RUNNING and ACTIVE
Jul 26 04:10:20 strawberry kernel: em1: TX Queue 0 --
Jul 26 04:10:20 strawberry kernel: em1: hw tdh = 0, hw tdt = 358
Jul 26 04:10:20 strawberry kernel: em1: Tx Queue Status = -2147483648
Jul 26 04:10:20 strawberry kernel: em1: TX descriptors avail = 666
Jul 26 04:10:20 strawberry kernel: em1: Tx Descriptors avail failure = 0
Jul 26 04:10:20 strawberry kernel: em1: RX Queue 0 --
Jul 26 04:10:20 strawberry kernel: em1: hw rdh = 0, hw rdt = 1023
Jul 26 04:10:20 strawberry kernel: em1: RX discarded packets = 0
Jul 26 04:10:20 strawberry kernel: em1: RX Next to Check = 0
Jul 26 04:10:20 strawberry kernel: em1: RX Next to Refresh = 1023
Jul 26 04:10:20 strawberry kernel: em1: link state changed to DOWN
I'll give r336313 a try as soon as possible and corroborate the fixes!
Cheers,
R Tyler Croy
signature.asc
Description: PGP signature
Re: linux64.ko fails to load in -CURRENT
(replies inline) On Fri, 28 Jul 2017, Alexander Kabaev wrote: > On Fri, 28 Jul 2017 08:50:32 -0700 > "R. Tyler Croy" <ty...@monkeypox.org> wrote: > > > I have noticed this over the past couple weeks with my -CURRENT > > laptop that 64-bit linux compatibility is failing to load, and I'm > > not entirely sure why. My current kernel is based off of r321626. > > > > When I run `kldload linux64` it fails with the following: > > > > link_elf_obj: symbol elf64_linux_vdso_fixup undefined > > linker_load_file: /boot/kernel/linux64.ko - unsupported file type > > > > > > It's unclear to me whether this is old cruft sitting around, a > > regression, or something else entirely floating around my system. Any > > pointer would help :) > > > > > > Cheers > > - R. Tyler Croy > > I am guessing you have COMPAT_LINUX in your kernel and 32bit emulation > is compiled into it. This does not work for linux64, one needs to build > all three required components as modules: COMPAT_LINUX32 was in the kernel configuration, guess I know that these things are incompatible now :) I think the handbook notes on statically linking linux support should probably be removed: <https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu-lbc-install.html> - R. Tyler Croy -- Code: <https://github.com/rtyler> Chatter: <https://twitter.com/agentdero> xmpp: rty...@jabber.org % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F -- signature.asc Description: PGP signature
linux64.ko fails to load in -CURRENT
I have noticed this over the past couple weeks with my -CURRENT laptop that 64-bit linux compatibility is failing to load, and I'm not entirely sure why. My current kernel is based off of r321626. When I run `kldload linux64` it fails with the following: link_elf_obj: symbol elf64_linux_vdso_fixup undefined linker_load_file: /boot/kernel/linux64.ko - unsupported file type It's unclear to me whether this is old cruft sitting around, a regression, or something else entirely floating around my system. Any pointer would help :) Cheers - R. Tyler Croy -- Code: <https://github.com/rtyler> Chatter: <https://twitter.com/agentdero> xmpp: rty...@jabber.org % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F -- signature.asc Description: PGP signature
UFS lock order reversal stack trace with r264677 on i386
I've noticed this as of late on my i386 -CURRENT Thinkpad T43 when I perform some file operations, but an exact reproduction case I've not yet stumbled upon: Apr 20 01:29:32 lemon kernel: lock order reversal: Apr 20 01:29:32 lemon kernel: 1st 0xc5832358 bufwait (bufwait) @ /usr/home/tyler/source/github/freebsd/sys/kern/vfs_bio.c:3081 Apr 20 01:29:32 lemon kernel: 2nd 0xc6f1d600 dirhash (dirhash) @ /usr/home/tyler/source/github/freebsd/sys/ufs/ufs/ufs_dirhash.c:284 Apr 20 01:29:32 lemon kernel: KDB: stack backtrace: Apr 20 01:29:32 lemon kernel: db_trace_self_wrapper(c115aa9d,79732f64,66752f73,66752f73,66752f73,...) at db_trace_self_wrapper+0x2d/frame 0xe93ba918 Apr 20 01:29:32 lemon kernel: kdb_backtrace(c115e882,c6f1d600,c1192fe7,c5dae950,c1192c15,...) at kdb_backtrace+0x30/frame 0xe93ba980 Apr 20 01:29:32 lemon kernel: witness_checkorder(c6f1d600,9,c1192c15,11c,0,...) at witness_checkorder+0xd04/frame 0xe93ba9cc Apr 20 01:29:32 lemon kernel: _sx_xlock(c6f1d600,0,c1192c15,11c,c5832300,...) at _sx_xlock+0x75/frame 0xe93ba9fc Apr 20 01:29:32 lemon kernel: ufsdirhash_remove(c6c26bc8,db6e02fc,2fc,e93baa58,e93baa54,...) at ufsdirhash_remove+0x37/frame 0xe93baa24 Apr 20 01:29:32 lemon kernel: ufs_dirremove(c6c1f238,c73c0d98,400800c,0,c6c1f238,...) at ufs_dirremove+0x12c/frame 0xe93baa68 Apr 20 01:29:32 lemon kernel: ufs_remove(e93bac00,c11683ae,a8b,e93babfc,0,...) at ufs_remove+0x76/frame 0xe93baaac Apr 20 01:29:32 lemon kernel: VOP_REMOVE_APV(c13e8d1c,e93bac00,c73c2e6c,e93babd4,81a5b18,...) at VOP_REMOVE_APV+0xfe/frame 0xe93baad8 Apr 20 01:29:32 lemon kernel: kern_unlinkat(c6958000,ff9c,81a5b18,0,0) at kern_unlinkat+0x27a/frame 0xe93bac24 Apr 20 01:29:32 lemon kernel: sys_unlink(c6958000,e93bacc8,c0feeaef,c1c25c90,0,...) at sys_unlink+0x32/frame 0xe93bac40 Apr 20 01:29:32 lemon kernel: syscall(e93bad08) at syscall+0x30c/frame 0xe93bacfc Apr 20 01:29:32 lemon kernel: Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe93bacfc Apr 20 01:29:32 lemon kernel: --- syscall (10, FreeBSD ELF32, sys_unlink), eip = 0x2848bd37, esp = 0xbfbfd1bc, ebp = 0xbfbfd248 --- Apr 20 01:29:54 lemon kernel: lock order reversal: Apr 20 01:29:54 lemon kernel: 1st 0xc699e388 ufs (ufs) @ /usr/home/tyler/source/github/freebsd/sys/kern/vfs_subr.c:2101 Apr 20 01:29:54 lemon kernel: 2nd 0xc5859e98 bufwait (bufwait) @ /usr/home/tyler/source/github/freebsd/sys/ufs/ffs/ffs_vnops.c:262 Apr 20 01:29:54 lemon kernel: 3rd 0xc7d27c68 ufs (ufs) @ /usr/home/tyler/source/github/freebsd/sys/kern/vfs_subr.c:2101 Apr 20 01:29:54 lemon kernel: KDB: stack backtrace: Apr 20 01:29:54 lemon kernel: db_trace_self_wrapper(c115aa9d,762f6e72,735f7366,2e726275,31323a63,...) at db_trace_self_wrapper+0x2d/frame 0xe93ba260 Apr 20 01:29:54 lemon kernel: kdb_backtrace(c115e89b,c7d27c68,c1144d4e,c5dae8e8,c11683ae,...) at kdb_backtrace+0x30/frame 0xe93ba2c4 Apr 20 01:29:54 lemon kernel: witness_checkorder(c7d27c68,9,c11683ae,835,c7d27c88,...) at witness_checkorder+0xd04/frame 0xe93ba310 Apr 20 01:29:54 lemon kernel: __lockmgr_args(c7d27c68,80100,c7d27c88,0,0,...) at __lockmgr_args+0x8f3/frame 0xe93ba3f0 Apr 20 01:29:54 lemon kernel: ffs_lock(e93ba470,c116537f,c5d8d110,c5d93840,c5d8d110,...) at ffs_lock+0x87/frame 0xe93ba42c Apr 20 01:29:54 lemon kernel: VOP_LOCK1_APV(c13e8d1c,e93ba470,c116537f,227,c13fe1f0,...) at VOP_LOCK1_APV+0x10a/frame 0xe93ba458 Apr 20 01:29:54 lemon kernel: _vn_lock(c7d27c34,80100,c11683ae,835,c11675a0,...) at Apr 20 01:29:54 lemon kernel: _vn_lock+0xa6/frame 0xe93ba498 Apr 20 01:29:54 lemon kernel: vget(c7d27c34,80100,c6958000,57,0,...) at vget+0x74/frame 0xe93ba4d0 Apr 20 01:29:54 lemon kernel: vfs_hash_get(c63fad20,70aa44,8,c6958000,e93ba5d0,...) at vfs_hash_get+0xfc/frame 0xe93ba4fc Apr 20 01:29:54 lemon kernel: ffs_vgetf(c63fad20,70aa44,8,e93ba5d0,1,...) at ffs_vgetf+0x44/frame 0xe93ba558 Apr 20 01:29:54 lemon kernel: softdep_sync_buf(c699e354,c5859e40,1,0,0,...) at softdep_sync_buf+0xbdf/frame 0xe93ba5e8 Apr 20 01:29:54 lemon kernel: ffs_syncvnode(c699e354,1,0,c13c3cdc,0,...) at ffs_syncvnode+0x2dd/frame 0xe93ba640 Apr 20 01:29:54 lemon kernel: ffs_truncate(c699e354,200,0,880,c5ed0300,...) at ffs_truncate+0x6eb/frame 0xe93ba Apr 20 01:29:54 lemon kernel: 7f0 Apr 20 01:29:54 lemon kernel: ufs_direnter(c699e354,c7d27c34,e93ba8b8,e93babcc,0,...) at ufs_direnter+0x79e/fra Apr 20 01:29:54 lemon kernel: me 0xe93ba870 Apr 20 01:29:54 lemon kernel: ufs_makeinode(e93babb8,e93babcc) at Apr 20 01:29:54 lemon kernel: ufs_makeinode+0x534/frame 0xe93ba9f0 Apr 20 01:29:54 lemon kernel: ufs_create(e93baad8,614,c63fad30,2,c63fad74,...) at Apr 20 01:29:54 lemon kernel: ufs_create+0x2f/frame 0xe93baa04 Apr 20 01:29:54 lemon kernel: VOP_CREATE_APV(c13e8d1c,e93baad8,e93babcc,e93baa68,c0acc930,...) at VOP_CREATE_APV+0xfe/frame 0xe93baa30 Apr 20 01:29:55 lemon kernel: vn_open_cred(e93bab70,e93babfc,180,0,c5ed0300,c6960118) at vn_open_cred+0x2f0/frame 0xe93bab00 Apr 20 01:29:55 lemon
Re: ZFS panic in -CURRENT
(follow up below) On 04/01/2014 06:57, R. Tyler Croy wrote: On Tue, 01 Apr 2014 09:41:45 +0300 Andriy Gapon a...@freebsd.org wrote: on 01/04/2014 02:22 R. Tyler Croy said the following: Bumping this with more details On Fri, 28 Mar 2014 09:53:32 -0700 R Tyler Croy ty...@monkeypox.org wrote: Apologies for the rough format here, I had to take a picture of this failure because I didn't know what else to do. http://www.flickr.com/photos/agentdero/13469355463/ I'm building off of the GitHub freebsd.git mirror here, and the latest commit in the tree is neel@'s Add an ioctl to suspend.. My dmesg/pciconf are here: https://gist.github.com/rtyler/1faa854dff7c4396d9e8 As linked before, the dmesg and `pciconf -lv` output can be found here: https://gist.github.com/rtyler/1faa854dff7c4396d9e8 Also in addition to the photo from before of the panic, here's another reproduction photo: https://www.flickr.com/photos/agentdero/13472248423/ Are you or have you even been running with any ZFS-related kernel patches? Negative, I've never run any specific ZFS patches on this machine (or any machine for that matter!) One other unique clue might be that I'm running with an encrypted zpool, other than that, nothing fancy here. I've upgraded my machine to r264387 and I still experience the issue, here's the latest pretty picture of my panicked laptop :) https://secure.flickr.com/photos/agentdero/13880032704/ The issue still seems to stem from a failed assertion in zap_leaf_lookup_closest() (http://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_leaf.c?revision=249195view=markup#l446) but I'm not sure which assertion might be failing. This is somewhat problematic because I cannot perform *any* FS operations with the tainted directory tree, not even a `du -hcs *` to find out how much space I can never access again :P I can reproduce this consistently, if anybody has the time to get onto IRC (rtyler on Freenode and EFNet) and debug this, I can certainly act as remote hands with kdb to help ascertain more information about the panic. Cheers ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS panic in -CURRENT
On Wed, 02 Apr 2014 09:58:37 +0300 Andriy Gapon a...@freebsd.org wrote: on 01/04/2014 16:57 R. Tyler Croy said the following: On Tue, 01 Apr 2014 09:41:45 +0300 Andriy Gapon a...@freebsd.org wrote: on 01/04/2014 02:22 R. Tyler Croy said the following: ... Also in addition to the photo from before of the panic, here's another reproduction photo: https://www.flickr.com/photos/agentdero/13472248423/ Are you or have you even been running with any ZFS-related kernel patches? Negative, I've never run any specific ZFS patches on this machine (or any machine for that matter!) One other unique clue might be that I'm running with an encrypted zpool, other than that, nothing fancy here. Your problem looks like a corruption of on-disk data. I can not say how it came to be or how to fix it now. This is concerning to me, I'm using an intel 128GB SSD which is less than 6 months old. If there is an actual disk-level corruption, shouldn't that manifest itself as a zpool error? :/ -- - R. Tyler Croy -- Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F -- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS panic in -CURRENT
On Tue, 01 Apr 2014 09:41:45 +0300 Andriy Gapon a...@freebsd.org wrote: on 01/04/2014 02:22 R. Tyler Croy said the following: Bumping this with more details On Fri, 28 Mar 2014 09:53:32 -0700 R Tyler Croy ty...@monkeypox.org wrote: Apologies for the rough format here, I had to take a picture of this failure because I didn't know what else to do. http://www.flickr.com/photos/agentdero/13469355463/ I'm building off of the GitHub freebsd.git mirror here, and the latest commit in the tree is neel@'s Add an ioctl to suspend.. My dmesg/pciconf are here: https://gist.github.com/rtyler/1faa854dff7c4396d9e8 As linked before, the dmesg and `pciconf -lv` output can be found here: https://gist.github.com/rtyler/1faa854dff7c4396d9e8 Also in addition to the photo from before of the panic, here's another reproduction photo: https://www.flickr.com/photos/agentdero/13472248423/ Are you or have you even been running with any ZFS-related kernel patches? Negative, I've never run any specific ZFS patches on this machine (or any machine for that matter!) One other unique clue might be that I'm running with an encrypted zpool, other than that, nothing fancy here. - R. Tyler Croy -- Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F -- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS panic in -CURRENT
Bumping this with more details On Fri, 28 Mar 2014 09:53:32 -0700 R Tyler Croy ty...@monkeypox.org wrote: Apologies for the rough format here, I had to take a picture of this failure because I didn't know what else to do. http://www.flickr.com/photos/agentdero/13469355463/ I'm building off of the GitHub freebsd.git mirror here, and the latest commit in the tree is neel@'s Add an ioctl to suspend.. My dmesg/pciconf are here: https://gist.github.com/rtyler/1faa854dff7c4396d9e8 As linked before, the dmesg and `pciconf -lv` output can be found here: https://gist.github.com/rtyler/1faa854dff7c4396d9e8 Also in addition to the photo from before of the panic, here's another reproduction photo: https://www.flickr.com/photos/agentdero/13472248423/ I'm running -CURRENT as of r263881 right now, with a custom kernel which is built on top of the VT kernel (https://github.com/rtyler/freebsd/blob/5e324960f1f2b7079de369204fe228db4a2ec99d/sys/amd64/conf/KIWI) I'm able to get this panic *consistently* whenever a process accesses my maildir folder which I sync with the mbsync program (isync package), such as `mbsync personal` or when I back up the maildir with duplicity. The commonality seems to be listing or accessing portions of this file tree. Curiously enough it only seems to be isolated to that single portion of the filesystem tree. The zpool is also clean as far as errors go: [16:11:03] tyler:freebsd git:(master*) $ zpool status zroot pool: zroot state: ONLINE status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(7) for details. scan: scrub repaired 0 in 0h18m with 0 errors on Fri Mar 28 11:55:03 2014 config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 ada0p3.eli ONLINE 0 0 0 errors: No known data errors [16:19:57] tyler:freebsd git:(master*) $ I'm not sure what other data would be useful here, I can consistently see the panic, but this data is highly personal, so I'm not sure how much of a repro case I can give folks. :( Cheers -- - R. Tyler Croy -- Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F -- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ZFS panic in -CURRENT
Apologies for the rough format here, I had to take a picture of this failure because I didn't know what else to do. http://www.flickr.com/photos/agentdero/13469355463/ I'm building off of the GitHub freebsd.git mirror here, and the latest commit in the tree is neel@'s Add an ioctl to suspend.. My dmesg/pciconf are here: https://gist.github.com/rtyler/1faa854dff7c4396d9e8 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
