[OmniOS-discuss] sed on bloody crashes when compiling cdrtools
I'm compiling omnios bloody and I get this crash during cdrtools compilation: make: Warning: Ignoring DistributedMake -j option --== MAKING SYMLINKS in ./RULES/ sh: line 1: 14171: Memory fault(coredump) mksh: Fatal error: The command `uname -s | sed 'y%ABCDEFGHIJKLMNOPQRSTUVWXYZ, /\\()%abcdefghijklmnopqrstuvwxyz,--%'' returned status `0' This creates a core with this stack trace: root@bloody:/var/cores# mdb core.sed.6628 Loading modules: [ libc.so.1 ld.so.1 ] ::walk thread | ::findstack -v stack pointer for thread 1: 80462a8 [ 080462a8 libc.so.1`_UTF8_mbsnrtowcs+0x2d() ] 080462d8 libc.so.1`mbsrtowcs_l+0x35(0, 804736c, 0, 0, fee01a00, 8067da7) 08046308 libc.so.1`mbsrtowcs+0x42(0, 804736c, 0, 0, 0, 0) 08047388 compile_tr+0x132(8067d61, 806a274, 0, fefcac10, fee10048, 38) 08047be8 compile_stream+0x7b8(806a260, 8047c7c, 8047c48, 80531a8, 1, 8047d60) 08047c08 compile+0x10(0, 3, 0, 0, 3, feffb0a4) 08047c48 main+0x1a8(8047c3c, fef72668, 8047c70, 805251b, 2, 8047c7c) 08047c70 _start+0x83(2, 8047d5c, 8047d60, 0, 8047da8, 8047dbd) Did anyone else run into this? ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] NFSv4 client soft lockups
Hi, I am wondering if anyone else has experience running NFSv4 from OmniOS to RHEL (6.5) clients. We are running it with sec=krb5p and are getting these errors (soft lockups) at the end of this mail across all the nodes causing them to be unresponsive after. The OmniOS server doesn't report anything wrong in the logs. I have submitted a ticket to Red Hat about this already but since it happens on all my RHEL clients at once and references the same OmniOS server (172.19.0.98) then it may have something to do either Omni NFS server or the interoperability of the RHEL NFSv4 client and the Omni NFSv4 server. Thanks, derek Sep 11 23:00:54 nauseated kernel: BUG: soft lockup - CPU#5 stuck for 67s! [172.19.0.98-man:12273] Sep 11 23:00:54 nauseated kernel: Modules linked in: aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 aes_generic cbc cts nfs lockd fscache nfs_acl autofs4 rpcsec_gss_krb5 auth_rpcgss sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 power_meter microcode iTCO_wdt iTCO_vendor_support dcdbas serio_raw lpc_ich mfd_core sg i7core_edac edac_core bnx2 ext4 jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix mptsas mptscsih mptbase scsi_transport_sas dm_mirror dm_region_hash dm_log dm_mod [last unloaded: speedstep_lib] Sep 11 23:00:54 nauseated kernel: CPU 5 Sep 11 23:00:54 nauseated kernel: Modules linked in: aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 aes_generic cbc cts nfs lockd fscache nfs_acl autofs4 rpcsec_gss_krb5 auth_rpcgss sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 power_meter microcode iTCO_wdt iTCO_vendor_support dcdbas serio_raw lpc_ich mfd_core sg i7core_edac edac_core bnx2 ext4 jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix mptsas mptscsih mptbase scsi_transport_sas dm_mirror dm_region_hash dm_log dm_mod [last unloaded: speedstep_lib] Sep 11 23:00:54 nauseated kernel: Sep 11 23:00:54 nauseated kernel: Pid: 12273, comm: 172.19.0.98-man Not tainted 2.6.32-431.29.2.el6.x86_64 #1 Dell Inc. PowerEdge R610/0F0XJ6 Sep 11 23:00:54 nauseated kernel: RIP: 0010:[a02f568d] [a02f568d] nfs4_run_state_manager+0x38d/0x620 [nfs] Sep 11 23:00:54 nauseated kernel: RSP: 0018:88042b249e90 EFLAGS: 0206 Sep 11 23:00:54 nauseated kernel: RAX: 88042b249fd8 RBX: 88042b249ee0 RCX: 0034 Sep 11 23:00:54 nauseated kernel: RDX: 115b RSI: 880429e7ed90 RDI: a0247568 Sep 11 23:00:54 nauseated kernel: RBP: 8100bb8e R08: f000 R09: fbb8191d81fb3e00 Sep 11 23:00:54 nauseated kernel: R10: 0001 R11: R12: 88042b249ee0 Sep 11 23:00:54 nauseated kernel: R13: 8100bb8e R14: ff10 R15: a0247568 Sep 11 23:00:54 nauseated kernel: FS: () GS:88002824() knlGS: Sep 11 23:00:54 nauseated kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b Sep 11 23:00:54 nauseated kernel: CR2: 006e19b8 CR3: 00042b026000 CR4: 07e0 Sep 11 23:00:54 nauseated kernel: DR0: DR1: DR2: Sep 11 23:00:54 nauseated kernel: DR3: DR6: 0ff0 DR7: 0400 Sep 11 23:00:54 nauseated kernel: Process 172.19.0.98-man (pid: 12273, threadinfo 88042b248000, task 8804299b9540) Sep 11 23:00:54 nauseated kernel: Stack: Sep 11 23:00:54 nauseated kernel: 0286 03fb 880429e7ecf9 880429e7ed00 Sep 11 23:00:54 nauseated kernel: d 88042b249ee0 88042a5e1898 88042b249ef8 a02f5300 Sep 11 23:00:54 nauseated kernel: d 880429e7ec00 88042cc89500 88042b249f40 8109abf6 Sep 11 23:00:54 nauseated kernel: Call Trace: Sep 11 23:00:54 nauseated kernel: [a02f5300] ? nfs4_run_state_manager+0x0/0x620 [nfs] Sep 11 23:00:54 nauseated kernel: [8109abf6] ? kthread+0x96/0xa0 Sep 11 23:00:54 nauseated kernel: [8100c20a] ? child_rip+0xa/0x20 Sep 11 23:00:54 nauseated kernel: [8109ab60] ? kthread+0x0/0xa0 Sep 11 23:00:54 nauseated kernel: [8100c200] ? child_rip+0x0/0x20 Sep 11 23:00:54 nauseated kernel: Code: 89 df e8 f7 8b 00 00 e9 e3 fc ff ff 66 90 48 89 df e8 d8 e4 ff ff 48 83 bb f8 00 00 00 00 0f 84 f7 fc ff ff f0 41 0f ba 2c 24 00 19 c0 85 c0 0f 84 df fc ff ff e9 e1 fc ff ff 0f 1f 40 00 41 81 Sep 11 23:00:54 nauseated kernel: Call Trace: Sep 11 23:00:54 nauseated kernel: [a02f5300] ? nfs4_run_state_manager+0x0/0x620 [nfs] Sep 11 23:00:54 nauseated kernel: [8109abf6] ? kthread+0x96/0xa0 Sep 11 23:00:54 nauseated kernel: [8100c20a] ? child_rip+0xa/0x20 Sep 11 23:00:54 nauseated kernel: [8109ab60] ?
Re: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools
On Sep 12, 2014, at 9:19 AM, Dan Vatca d...@syneto.net wrote: I'm compiling omnios bloody and I get this crash during cdrtools compilation: make: Warning: Ignoring DistributedMake -j option --== MAKING SYMLINKS in ./RULES/ sh: line 1: 14171: Memory fault(coredump) mksh: Fatal error: The command `uname -s | sed 'y%ABCDEFGHIJKLMNOPQRSTUVWXYZ, /\\()%abcdefghijklmnopqrstuvwxyz,--%'' returned status `0' This creates a core with this stack trace: root@bloody:/var/cores# mdb core.sed.6628 Loading modules: [ libc.so.1 ld.so.1 ] ::walk thread | ::findstack -v stack pointer for thread 1: 80462a8 [ 080462a8 libc.so.1`_UTF8_mbsnrtowcs+0x2d() ] 080462d8 libc.so.1`mbsrtowcs_l+0x35(0, 804736c, 0, 0, fee01a00, 8067da7) 08046308 libc.so.1`mbsrtowcs+0x42(0, 804736c, 0, 0, 0, 0) 08047388 compile_tr+0x132(8067d61, 806a274, 0, fefcac10, fee10048, 38) 08047be8 compile_stream+0x7b8(806a260, 8047c7c, 8047c48, 80531a8, 1, 8047d60) 08047c08 compile+0x10(0, 3, 0, 0, 3, feffb0a4) 08047c48 main+0x1a8(8047c3c, fef72668, 8047c70, 805251b, 2, 8047c7c) 08047c70 _start+0x83(2, 8047d5c, 8047d60, 0, 8047da8, 8047dbd) Did anyone else run into this? No, but I'm off bloody for now... (trying to bringup 012 and 013), and trying to beat back serious IPS problems I accidentally introduced. Can you reproduce this crash with just the command listed above all by itself? Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools
Yes. And it also reproduces with a simple transliteration. But it does go awry only with /usr/bin/sed, not with /usr/gnu/bin/sed. Replacements also work just fine. root@bloody:/var/cores# ls root@bloody:/var/cores# env HZ= SHELL=/usr/bin/bash TERM=xterm LC_ALL=en_US.UTF-8 PAGER=/usr/bin/less -ins MAIL=/var/mail/root PATH=/usr/gnu/bin:/usr/bin:/usr/sbin:/sbin PWD=/var/cores LANG=en_US.UTF-8 TZ=Europe/Bucharest SHLVL=1 HOME=/root LOGNAME=root OLDPWD=/root _=/usr/gnu/bin/env root@bloody:/var/cores# uname -a SunOS bloody 5.11 omnios-fa65b1e i86pc i386 i86pc root@bloody:/var/cores# *echo x | /usr/bin/sed 'y%,%,%'* Segmentation Fault (core dumped) root@bloody:/var/cores# ls core core.sed.971 root@bloody:/var/cores# pstack core.sed.971 core 'core.sed.971' of 971: /usr/bin/sed y%,%,% feeb67b9 _UTF8_mbsnrtowcs (0, 80474fc, , 0, 0, 3) + 2d feea8d8b mbsrtowcs_l (0, 80474fc, 0, 0, fee01a00, 8067d66) + 35 feea8dcf mbsrtowcs (0, 80474fc, 0, 0, 0, 0) + 42 08053f2b compile_tr (8067d61, 806a274, 0, fee10268, 58, fee10048) + 132 08054939 compile_stream (806a260, 8047e18, 8047dd8, 80531a8, 1, 8047ee1) + 7b8 08054af0 compile (0, 3, fef6ec80, 0, 100, feffb0a4) + 10 080531b3 main (8047dcc, fef72668, 8047e0c, 805251b, 2, 8047e18) + 1a8 0805251b _start (2, 8047ed4, 8047ee1, 0, 8047ee8, 8047eec) + 83 root@bloody:/var/cores# echo a | /usr/bin/sed 'y%a%b%' Segmentation Fault (core dumped) root@bloody:/var/cores# echo a | /usr/gnu/bin/sed 'y%a%b%' b root@bloody:/var/cores# echo x | /usr/bin/sed 's%,%,%' x On Fri, Sep 12, 2014 at 5:28 PM, Dan McDonald dan...@omniti.com wrote: On Sep 12, 2014, at 9:19 AM, Dan Vatca d...@syneto.net wrote: I'm compiling omnios bloody and I get this crash during cdrtools compilation: make: Warning: Ignoring DistributedMake -j option --== MAKING SYMLINKS in ./RULES/ sh: line 1: 14171: Memory fault(coredump) mksh: Fatal error: The command `uname -s | sed 'y%ABCDEFGHIJKLMNOPQRSTUVWXYZ, /\\()%abcdefghijklmnopqrstuvwxyz,--%'' returned status `0' This creates a core with this stack trace: root@bloody:/var/cores# mdb core.sed.6628 Loading modules: [ libc.so.1 ld.so.1 ] ::walk thread | ::findstack -v stack pointer for thread 1: 80462a8 [ 080462a8 libc.so.1`_UTF8_mbsnrtowcs+0x2d() ] 080462d8 libc.so.1`mbsrtowcs_l+0x35(0, 804736c, 0, 0, fee01a00, 8067da7) 08046308 libc.so.1`mbsrtowcs+0x42(0, 804736c, 0, 0, 0, 0) 08047388 compile_tr+0x132(8067d61, 806a274, 0, fefcac10, fee10048, 38) 08047be8 compile_stream+0x7b8(806a260, 8047c7c, 8047c48, 80531a8, 1, 8047d60) 08047c08 compile+0x10(0, 3, 0, 0, 3, feffb0a4) 08047c48 main+0x1a8(8047c3c, fef72668, 8047c70, 805251b, 2, 8047c7c) 08047c70 _start+0x83(2, 8047d5c, 8047d60, 0, 8047da8, 8047dbd) Did anyone else run into this? No, but I'm off bloody for now... (trying to bringup 012 and 013), and trying to beat back serious IPS problems I accidentally introduced. Can you reproduce this crash with just the command listed above all by itself? Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] NFSv4 client soft lockups
Is you RHEL 6.5 client a virtual machine? If so this message is a red herring to your problem. See the VMware KB article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1009996 I run all NFSv4 from CentOS 6.5 to OmniOS, but do not use kerberos. It's been rock solid. -Chip On Fri, Sep 12, 2014 at 8:30 AM, Derek Yarnell de...@umiacs.umd.edu wrote: Hi, I am wondering if anyone else has experience running NFSv4 from OmniOS to RHEL (6.5) clients. We are running it with sec=krb5p and are getting these errors (soft lockups) at the end of this mail across all the nodes causing them to be unresponsive after. The OmniOS server doesn't report anything wrong in the logs. I have submitted a ticket to Red Hat about this already but since it happens on all my RHEL clients at once and references the same OmniOS server (172.19.0.98) then it may have something to do either Omni NFS server or the interoperability of the RHEL NFSv4 client and the Omni NFSv4 server. Thanks, derek Sep 11 23:00:54 nauseated kernel: BUG: soft lockup - CPU#5 stuck for 67s! [172.19.0.98-man:12273] Sep 11 23:00:54 nauseated kernel: Modules linked in: aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 aes_generic cbc cts nfs lockd fscache nfs_acl autofs4 rpcsec_gss_krb5 auth_rpcgss sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 power_meter microcode iTCO_wdt iTCO_vendor_support dcdbas serio_raw lpc_ich mfd_core sg i7core_edac edac_core bnx2 ext4 jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix mptsas mptscsih mptbase scsi_transport_sas dm_mirror dm_region_hash dm_log dm_mod [last unloaded: speedstep_lib] Sep 11 23:00:54 nauseated kernel: CPU 5 Sep 11 23:00:54 nauseated kernel: Modules linked in: aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 aes_generic cbc cts nfs lockd fscache nfs_acl autofs4 rpcsec_gss_krb5 auth_rpcgss sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 power_meter microcode iTCO_wdt iTCO_vendor_support dcdbas serio_raw lpc_ich mfd_core sg i7core_edac edac_core bnx2 ext4 jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix mptsas mptscsih mptbase scsi_transport_sas dm_mirror dm_region_hash dm_log dm_mod [last unloaded: speedstep_lib] Sep 11 23:00:54 nauseated kernel: Sep 11 23:00:54 nauseated kernel: Pid: 12273, comm: 172.19.0.98-man Not tainted 2.6.32-431.29.2.el6.x86_64 #1 Dell Inc. PowerEdge R610/0F0XJ6 Sep 11 23:00:54 nauseated kernel: RIP: 0010:[a02f568d] [a02f568d] nfs4_run_state_manager+0x38d/0x620 [nfs] Sep 11 23:00:54 nauseated kernel: RSP: 0018:88042b249e90 EFLAGS: 0206 Sep 11 23:00:54 nauseated kernel: RAX: 88042b249fd8 RBX: 88042b249ee0 RCX: 0034 Sep 11 23:00:54 nauseated kernel: RDX: 115b RSI: 880429e7ed90 RDI: a0247568 Sep 11 23:00:54 nauseated kernel: RBP: 8100bb8e R08: f000 R09: fbb8191d81fb3e00 Sep 11 23:00:54 nauseated kernel: R10: 0001 R11: R12: 88042b249ee0 Sep 11 23:00:54 nauseated kernel: R13: 8100bb8e R14: ff10 R15: a0247568 Sep 11 23:00:54 nauseated kernel: FS: () GS:88002824() knlGS: Sep 11 23:00:54 nauseated kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b Sep 11 23:00:54 nauseated kernel: CR2: 006e19b8 CR3: 00042b026000 CR4: 07e0 Sep 11 23:00:54 nauseated kernel: DR0: DR1: DR2: Sep 11 23:00:54 nauseated kernel: DR3: DR6: 0ff0 DR7: 0400 Sep 11 23:00:54 nauseated kernel: Process 172.19.0.98-man (pid: 12273, threadinfo 88042b248000, task 8804299b9540) Sep 11 23:00:54 nauseated kernel: Stack: Sep 11 23:00:54 nauseated kernel: 0286 03fb 880429e7ecf9 880429e7ed00 Sep 11 23:00:54 nauseated kernel: d 88042b249ee0 88042a5e1898 88042b249ef8 a02f5300 Sep 11 23:00:54 nauseated kernel: d 880429e7ec00 88042cc89500 88042b249f40 8109abf6 Sep 11 23:00:54 nauseated kernel: Call Trace: Sep 11 23:00:54 nauseated kernel: [a02f5300] ? nfs4_run_state_manager+0x0/0x620 [nfs] Sep 11 23:00:54 nauseated kernel: [8109abf6] ? kthread+0x96/0xa0 Sep 11 23:00:54 nauseated kernel: [8100c20a] ? child_rip+0xa/0x20 Sep 11 23:00:54 nauseated kernel: [8109ab60] ? kthread+0x0/0xa0 Sep 11 23:00:54 nauseated kernel: [8100c200] ? child_rip+0x0/0x20 Sep 11 23:00:54 nauseated kernel: Code: 89 df e8 f7 8b 00 00 e9 e3 fc ff ff 66 90 48 89 df e8
Re: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools
On Sep 12, 2014, at 11:03 AM, Dan Vatca d...@syneto.net wrote: Yes. And it also reproduces with a simple transliteration. But it does go awry only with /usr/bin/sed, not with /usr/gnu/bin/sed. Replacements also work just fine. Hmmm. I want to try this out on on OI with a very latest illumos-gate. I suspect it was introduced with some recent changes in that space. I'll get back to you with those OI results. If they fail the same way on OI, I will file an illumos bug and see if someone up there can fix it. Be right back, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools
On Fri, Sep 12, 2014 at 11:05:31AM -0400, Dan McDonald wrote: On Sep 12, 2014, at 11:03 AM, Dan Vatca d...@syneto.net wrote: Yes. And it also reproduces with a simple transliteration. But it does go awry only with /usr/bin/sed, not with /usr/gnu/bin/sed. Replacements also work just fine. Hmmm. I want to try this out on on OI with a very latest illumos-gate. I suspect it was introduced with some recent changes in that space. Here's OI hipster: jeffpc@meili:~5$ uname -a SunOS meili 5.11 illumos-4ef97ab i86pc i386 i86pc Solaris jeffpc@meili:~6$ echo x | /usr/bin/sed 'y%,%,%' Segmentation Fault (core dumped) jeffpc@meili:~7$ pstack core core 'core' of 1739:/usr/bin/sed y%,%,% feeb68f9 _UTF8_mbsnrtowcs (0, 8046e5c, , 0, 0, 3) + 2d feea8e9d mbsrtowcs_l (0, 8046e5c, 0, 0, fee01a00, 8067d66) + 35 feea8ee1 mbsrtowcs (0, 8046e5c, 0, 0, 0, 0) + 42 08053f2e compile_tr (8067d61, 806a274, 0, fefcac27, fee10048, 38) + 132 0805493c compile_stream (806a260, 804776c, 8047738, 80531aa, 1, 80478c9) + 7b8 08054af3 compile (0, 3, 0, 0, 3, feffb0a4) + 10 080531b5 main (804772c, fef72668, 8047760, 805251b, 2, 804776c) + 1a8 0805251b _start (2, 80478bc, 80478c9, 0, 80478d0, 80478e2) + 83 Jeff. -- Failure is not an option, It comes bundled with your Microsoft product. ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] NFSv4 client soft lockups
On 9/12/14 11:05 AM, Schweiss, Chip wrote: Is you RHEL 6.5 client a virtual machine? If so this message is a red herring to your problem. See the VMware KB article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1009996 I run all NFSv4 from CentOS 6.5 to OmniOS, but do not use kerberos. It's been rock solid. Hi Chip, No we are running on physical hardware. It also looks like the parameter they talk about is something different[1] post RHEL 6.1. We are trying to drop to just sec=krb5 to see if that provides any relief and may increase the watchdog timer a bit to see if this is just a race condition. [1] - https://access.redhat.com/solutions/57811? Thanks, derek -- Derek T. Yarnell University of Maryland Institute for Advanced Computer Studies ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools
Dan V. -- As a workaround, set your LANG to 'C' instead of en_US.UTF-8. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools
It crashes with LANG=C too. Just tested that. As a workaround I will use tr instead of sed. On Fri, Sep 12, 2014 at 6:36 PM, Dan McDonald dan...@omniti.com wrote: Dan V. -- As a workaround, set your LANG to 'C' instead of en_US.UTF-8. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] NFSv4 client soft lockups
Not sure if this is the same issue, but I had the same behavior with Windows 8.1 on my laptop; everything has been fine for many months with clients running Win 7, Ubuntu 12.04 LTS, Ubuntu 14.04 LTS, OpenIndiana and XStreamOS (Illumos-based). But the Win 8.1 laptop causes NFSv4 to lock up, and (obviously) blocks the rest of the clients from accessing the server when it does, until NFS is reset. Interestingly, it doesn't seem to do this immediately; NFSv4 works just fine for maybe 15 minutes before the lockup occurs, but I haven't exactly troubleshot the details. Is there a particular log file which might be helpful to examine? Thanks! Peter On Fri, Sep 12, 2014 at 11:25 AM, Derek Yarnell de...@umiacs.umd.edu wrote: On 9/12/14 11:05 AM, Schweiss, Chip wrote: Is you RHEL 6.5 client a virtual machine? If so this message is a red herring to your problem. See the VMware KB article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1009996 I run all NFSv4 from CentOS 6.5 to OmniOS, but do not use kerberos. It's been rock solid. Hi Chip, No we are running on physical hardware. It also looks like the parameter they talk about is something different[1] post RHEL 6.1. We are trying to drop to just sec=krb5 to see if that provides any relief and may increase the watchdog timer a bit to see if this is just a race condition. [1] - https://access.redhat.com/solutions/57811? Thanks, derek -- Derek T. Yarnell University of Maryland Institute for Advanced Computer Studies ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] NFSv4 client soft lockups
I do not know if it is relevant but I came from open Indiana and it had a similar issue where nfsv4 had a bug that wouldn't unlock files Valrhona valrh...@gmail.com wrote: Not sure if this is the same issue, but I had the same behavior with Windows 8.1 on my laptop; everything has been fine for many months with clients running Win 7, Ubuntu 12.04 LTS, Ubuntu 14.04 LTS, OpenIndiana and XStreamOS (Illumos-based). But the Win 8.1 laptop causes NFSv4 to lock up, and (obviously) blocks the rest of the clients from accessing the server when it does, until NFS is reset. Interestingly, it doesn't seem to do this immediately; NFSv4 works just fine for maybe 15 minutes before the lockup occurs, but I haven't exactly troubleshot the details. Is there a particular log file which might be helpful to examine? Thanks! Peter On Fri, Sep 12, 2014 at 11:25 AM, Derek Yarnell de...@umiacs.umd.edu wrote: On 9/12/14 11:05 AM, Schweiss, Chip wrote: Is you RHEL 6.5 client a virtual machine? If so this message is a red herring to your problem. See the VMware KB article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=dis playKCexternalId=1009996 I run all NFSv4 from CentOS 6.5 to OmniOS, but do not use kerberos. It's been rock solid. Hi Chip, No we are running on physical hardware. It also looks like the parameter they talk about is something different[1] post RHEL 6.1. We are trying to drop to just sec=krb5 to see if that provides any relief and may increase the watchdog timer a bit to see if this is just a race condition. [1] - https://access.redhat.com/solutions/57811? Thanks, derek -- Derek T. Yarnell University of Maryland Institute for Advanced Computer Studies ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Quick question -- FTP server usage in OmniOS?
Recently, but after the freeze for r151012, the FTP server was removed from illumos-gate. This means that it will be removed from the illumos-omnios gate for the new bloody (r151013) and the next stable+LTS (r151014). I'm curious if this is a big loss or not for our users. If it IS, then clearly part of the 013 bloody cycle is to replace the removed FTP server with something else, OR continue to maintain it. I'm inclined not to replace it, unless I get a large mob of torch-and-pitchfork-wielding folks. Curious, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] E5-2600 v3 Haswell
Dan McDonald wrote:
On Sep 11, 2014, at 2:40 PM, Jon Hull jh...@jncs.com wrote:
The board has 1g nics and those worked fine (igb). I was supposed to get a 10g
version of the board but my boss sold it before I had a chance to test it out.
The 10g may actually be a 40g with 4x 10G ports. If it's the part I'm thinking about, it's the
i40e, which illumos does not yet support. Do you know what 1GigE igb part it is? Is
it I350, or something newer?
It's the i350.
This is a dual-socket board, you said? I'd be interested to know if you see
any odd latencies - I've seen {Sandy,Ivy} Bridge-E boards occasionally exhibit
odd latencies with 10GigE, but it was very difficult to characterize and
reproduce.
Fortunately that are still using X540 on these boards.
How have these latencies shown up? I have a number of X9 boards with
X540 10GE on board and I haven't notices anything untoward.
--
Ian.
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
