from:"Floris van Essen ..\:\: House of Ancients Amstafs \:\:.."

Re: [OmniOS-discuss] Questions about - End the uncertainty -

2017-07-06 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

Hi All,


Fully agree with Gea!

Kr,

Floris

Van: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] Namens 
Guenther Alka
Verzonden: woensdag 5 juli 2017 16:48
Aan: omnios-discuss 
Onderwerp: Re: [OmniOS-discuss] Questions about - End the uncertainty -


hello Tobi and Andy
the first good news for 10 Weeks!

cheers

Gea

Am 05.07.2017 um 16:30 schrieb Tobias Oetiker:
Gea,

the king is dead, long live the king

https://gitter.im/omniosorg/Lobby

www.omniosce.org
the story continues ...

cheers
tobi

- On Jul 5, 2017, at 4:05 PM, Guenther Alka 
 wrote:


about OmniOS and the silence for weeks

For my own future, I have already decided to switch back to OpenIndiana, the 
community based sister project of OmniOS. But like many users, I have yet 
OmniOS installations running perfectly. For them, it is essential to ask about 
the future for the next months or year and needed next steps (can wait some 
time or switch as soon as possible).


@OmniTi
The end of OmniOS@OmniTi seems final.

- How long will the website and the repo remain online?

- Is there an option to fix serious bugs or problems in OmniOS @OmniTi for
a limited time like 1 year or at least end of the year?

- Are you willing to transfer the website/name either to a new OmniOS community 
project (I cannot see this as an option regarding the silence about) or to the 
OpenIndiana community to use it as a name for a possible stable like 
OpenIndiana Hipster=dev and OpenIndiana OmniOS as a stable subset? (if OI is 
willing to go that route but the request or offer must come from OmniTi or 
OmniOS people).

OmniOS has a very strong reputation regarding production quality and stability, 
so such a step would help both if OpenIndiana and OmniOS would cooperate in a 
common project. Seems a pity if the name would die or remain as a name for a 
failed project.


@OmniOS developers (current or former - you have done a very good job!)

- Is there an option to fix serious bugs or problems in OmniOS for a limited 
time like 1 year or at least end of the year? This would help until a sucessor 
(less likely OmniOS 151024, maybe next OpenIndiana snap with a stable subset) 
is available. LX would then remain an OmniOS option in the meantime (I would 
not dare to ask about an upstream).



@all
comments?



Gea
@napp-it.org

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

--


...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Bug ?

2017-06-29 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

Hi All,

With pain in my heart, i fear OmniOs has started it's slow descent to death :-(



-Oorspronkelijk bericht-
Van: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] Namens 
Paul B. Henson
Verzonden: donderdag 29 juni 2017 22:13
Aan: 'Guenther Alka' ; omnios-discuss@lists.omniti.com
Onderwerp: Re: [OmniOS-discuss] Bug ?

> From: Guenther Alka
> Sent: Thursday, June 29, 2017 12:33 AM
>
> There are no signs from OmniTi to add any fixes.

An OmniTI person posted an intention to back port security fixes to r151022 for 
one year, although I'm not sure whether that was under the auspices of OmniTI 
employment or just on his personal time. So far though, there have been no new 
commits in the r151022 repo since Dan's last one on 5/10..


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151022 is now out!

2017-05-12 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

Thanks Dan,

Also for past help and all your very hard work, it really is a shame that 
OmniTI just pulled the plug, and you leaving them.
I certainly wish you the very best for the future, and do hope you will 
continue working on solarish OS'es

flrois

-Oorspronkelijk bericht-
Van: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] Namens Dan 
McDonald
Verzonden: vrijdag 12 mei 2017 16:51
Aan: OmniOS-discuss 
Onderwerp: [OmniOS-discuss] OmniOS r151022 is now out!

As always, please start with the release notes:

https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022

And for this release, there are upgrade notes:

https://omnios.omniti.com/wiki.php/Upgrade_to_r151022

This is an LTS and Stable update.  Highlights include:

- BSD Loader is now available.  This has its own wiki page, including how to 
stick with GRUB if you think you need to.

- Kayak Interactive Installer --> No more Caiman, no more F-keys & curses, and 
no-more hacking timezone names.  Also, one less repo to maintain for OmniOS. 
Kayak does it all now.

- Python is now 2.7. This means an IPS/pkg(5) update too. There's a subtle, but 
noteworthy, update to linked-image semantics ("pkg update -r") AND upgrading 
non-linked-image "ipkg" zones is a bit more difficult due to the transition 
(chicken & egg problem with ipkg brand "attach").

- Perl is now 5.24.1.

- USB 3.0 support.

With OmniTI withdrawing funding for OmniOS-as-product, this will be the last 
OmniTI-pushed "release" of OmniOS. It contains all of the most recent (as of 
May) illumos-gate changes, AND illumos-joyent LX brand changes.

This release broke the 6-month cadence, due to Loader, Python2.7, and the need 
for Kayak to take over ALL installation duties.  I'm sorry for it being 1-2 
months late, but I wanted to make sure these changes were comfortably in place 
during the 021 bloody.

Because of the sheer volume of change in this release, I had to update many 
OmniOS wiki pages.  Here's a list of all of those I changed nontrivially due to 
r151022.  Please check them out to make sure I'm not missing anything...

https://omnios.omniti.com/wiki.php/ReleaseNotes/r151022

https://omnios.omniti.com/wiki.php/Installation

https://omnios.omniti.com/wiki.php/LXZones

https://omnios.omniti.com/wiki.php/Upgrade_to_r151022

https://omnios.omniti.com/wiki.php/NewLinkedImages

https://omnios.omniti.com/wiki.php/linked_images

https://omnios.omniti.com/wiki.php/KayakInteractive

https://omnios.omniti.com/wiki.php/BSDLoader

https://omnios.omniti.com/wiki.php/ReleaseCycle

https://omnios.omniti.com/wiki.php/Packaging

https://omnios.omniti.com/wiki.php/ReleaseNotes/

https://omnios.omniti.com/wiki.php/WikiStart

https://omnios.omniti.com/wiki.php/BuildInstructions

https://omnios.omniti.com/wiki.php/Maintainers

https://omnios.omniti.com/wiki.php/illumos-tools

https://omnios.omniti.com/wiki.php/buildctl

https://omnios.omniti.com/wiki.php/ReleaseMedia

I'll have more to say about my departure from OmniTI in a distinct e-mail.

Thanks, and happy upgrading!
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] otherwise stable system sudden crashing

2015-11-16 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

Hi Dan,

Just tell me were to upload it :-)

Funny thing is, this was happening by just connecting to a share, not even 
browsing or putting file activity on it

Kr,

Floris

-Oorspronkelijk bericht-
Van: Dan McDonald [mailto:dan...@omniti.com] 
Verzonden: maandag 16 november 2015 14:05
Aan: Floris van Essen ..:: House of Ancients Amstafs ::.. 
<i...@houseofancients.nl>
CC: OmniOS-discuss (omnios-discuss@lists.omniti.com) 
<omnios-discuss@lists.omniti.com>; Dan McDonald <dan...@omniti.com>
Onderwerp: Re: [OmniOS-discuss] otherwise stable system sudden crashing

There were some SMB updates in r151016.

There are even BIGGER ones that landed in illumos just after 016 closed, so I 
don't have a handy reference from upstream.

Looking at '016, your problem is likely in a function whose frame isn't in your 
dump:  smb_sign_begin().  There are two potential bcopy() calls there, and one 
of them is calling with a NULL pointer.

bcopy(token->tkn_session_key, sign->mackey, SSN_KEY_LEN);
if (sinfo->ssi_cspwlen > 0) {
bcopy(sinfo->ssi_cspwd, sign->mackey + SSN_KEY_LEN,
sinfo->ssi_cspwlen);
}

I'm not sure which of those two gets called.

Having said that, I'm not sure how much help I can get or give you without an 
actual coredump to inspect.

Dan

...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] otherwise stable system sudden crashing

2015-11-15 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

Hi All,

After some further investigation, found something that may be of importance to 
some.
Found out this system also had a cifs share, serving out some media files to a 
Openelec 6.0 Kodi media center.
That Media center coincidentally was shut down the same time I restarted the 
Esx machines

When starting and browsing a smb session from that linux system, immediately 
OmniOS crashes with the below crash report.
When doing the same from a windows 7, xp , 8.1 and 2012 machine the OmniOS keep 
running as expected.

Are the any other having the same issues ?
If someone wants the complete crash report, let me know

Kr,

Floris

Van: Floris van Essen ..:: House of Ancients Amstafs ::..
Verzonden: zaterdag 14 november 2015 20:21
Aan: OmniOS-discuss <omnios-discuss-boun...@lists.omniti.com>
Onderwerp: otherwise stable system sudden crashing

Hi All,

Just had something strange happen, and would like to pick some of you minds.
Updated OmniOS v11 r151016 yesterday.

Basically it runs as a ISCSI storage backend to 2 VMWare Esx 5.5 build 2638301 
hosts.

This system has been running extremely stable for over 2 years now, until this 
evening.
Out of the blue started rebooting, with a kernel dumps.

Log shows :

Nov 14 19:05:38 PSD01 genunix: [ID 335743 kern.notice] BAD TRAP: type=e (#pf 
Page fault) rp=ff0079ff6710 addr=0 occurred in module "unix" due to a NULL 
pointer dereference
Nov 14 19:05:38 PSD01 unix: [ID 10 kern.notice]
Nov 14 19:05:38 PSD01 unix: [ID 839527 kern.notice] sched:
Nov 14 19:05:38 PSD01 unix: [ID 753105 kern.notice] #pf Page fault
Nov 14 19:05:38 PSD01 unix: [ID 532287 kern.notice] Bad kernel fault at addr=0x0
Nov 14 19:05:38 PSD01 unix: [ID 243837 kern.notice] pid=0, 
pc=0xfb854cf8, sp=0xff0079ff6808, eflags=0x10286
Nov 14 19:05:38 PSD01 unix: [ID 211416 kern.notice] cr0: 8005003b cr4: 406f8
Nov 14 19:05:38 PSD01 unix: [ID 624947 kern.notice] cr2: 0
Nov 14 19:05:38 PSD01 unix: [ID 625075 kern.notice] cr3: c00
Nov 14 19:05:38 PSD01 unix: [ID 625715 kern.notice] cr8: c
Nov 14 19:05:38 PSD01 unix: [ID 10 kern.notice]
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]   rdi:   10 
rsi: ff11678f6828 rdx:   10
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]   rcx:  178 
 r8:0  r9:0
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]   rax: ff11678f6818 
rbx: ff115e6d7168 rbp: ff0079ff6860
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]   r10: fb854cf8 
r11:2 r12: ff1155fe7650
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]   r13: ff1167903ea8 
r14: ff1164c9b288 r15: ff11678d18e0
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]   fsb:0 
gsb: ff1142c83b00  ds:   4b
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]es:   4b 
 fs:0  gs:  1c3
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]   trp:e 
err:0 rip: fb854cf8
Nov 14 19:05:38 PSD01 unix: [ID 592667 kern.notice]cs:   30 
rfl:10286 rsp: ff0079ff6808
Nov 14 19:05:38 PSD01 unix: [ID 266532 kern.notice]ss:   38
Nov 14 19:05:38 PSD01 unix: [ID 10 kern.notice]
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ff0079ff65f0 
unix:die+df ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ff0079ff6700 
unix:trap+dc0 ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ff0079ff6710 
unix:cmntrap+e6 ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ff0079ff6860 
unix:bcopy+1a8 ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ff0079ff6990 
smbsrv:smb_authenticate_core+3cb ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ff0079ff69e0 
smbsrv:smb_authenticate+44 ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ff0079ff6a60 
smbsrv:smb_com_session_setup_andx+2e ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ff0079ff6b50 
smbsrv:smb_dispatch_request+5c5 ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ff0079ff6b90 
smbsrv:smb_session_worker+a0 ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ff0079ff6c20 
genunix:taskq_d_thread+b7 ()
Nov 14 19:05:38 PSD01 genunix: [ID 655072 kern.notice] ff0079ff6c30 
unix:thread_start+8 ()
Nov 14 19:05:38 PSD01 unix: [ID 10 kern.notice]
Nov 14 19:05:38 PSD01 genunix: [ID 672855 kern.notice] syncing file systems...
Nov 14 19:05:39 PSD01 genunix: [ID 904073 kern.notice]  done
Nov 14 19:05:40 PSD01 genunix: [ID 111219 kern.notice] dumping to 
/dev/zvol/dsk/rpool/dump, offset 65536, content: kernel
Nov 14 19:06:55 PSD01 genunix: [ID 10 kern.notice]
Nov 14 19:06:55 PSD01 genunix: [ID 665016 kern.notice] ^M100% done: 87 
pages dumped,
Nov 14 19:06:55 PSD01 genunix: [ID 851671 kern.notice] dump succeed

Re: [OmniOS-discuss] OmniOS-discuss Digest, Vol 44, Issue 7

2015-11-04 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

Hi All,

Already found the issue.

Mbuffer, provided by ms.omniti.com<http://ms.omniti.com> was the culprit.
Removed it,and it's going :)

Van: Floris van Essen ..:: House of Ancients Amstafs ::..
Verzonden: woensdag 4 november 2015 21:20
Aan: omnios-discuss@lists.omniti.com
Onderwerp: RE: OmniOS-discuss Digest, Vol 44, Issue 7


Hi All,



While trying to update 151014 to 151016.



Creating Plan (Running solver): /

pkg update: No solution was found to satisfy constraints

Plan Creation: Package solver has not found a solution to update to latest 
available versions.

This may indicate an overly constrained set of packages are installed.



latest incorporations:



  
pkg://omnios/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151016:20151102T183750Z

  pkg://omnios/incorporation/jeos/illumos-gate@11,5.11-0.151016:20151102T185724Z

  
pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151016:20151102T185924Z

  pkg://omnios/entire@11,5.11-0.151016:20151102T202622Z



The following indicates why the system cannot update to the latest version:



  No suitable version of required package 
pkg://omnios/network/openssh@7.1.1,5.11-0.151016:20151102T190704Z found:

Reject:  pkg://omnios/network/openssh@7.1.1,5.11-0.151016:20151102T190704Z

Reason:  Package contains 'exclude' dependency pkg:/network/ssh on 
installed package

  No suitable version of required package 
pkg://omnios/network/openssh-server@7.1.1,5.11-0.151016:20151102T190719Z found:

Reject:  
pkg://omnios/network/openssh-server@7.1.1,5.11-0.151016:20151102T190719Z

Reason:  Package contains 'exclude' dependency pkg:/service/network/ssh on 
installed package





This is a remote server , without remote management, so removing openssh 
manually seems like removing all my access.

Any tips?



Thanks,



Floris





...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS-discuss Digest, Vol 44, Issue 7

2015-11-04 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

Hi All,



While trying to update 151014 to 151016.



Creating Plan (Running solver): /

pkg update: No solution was found to satisfy constraints

Plan Creation: Package solver has not found a solution to update to latest 
available versions.

This may indicate an overly constrained set of packages are installed.



latest incorporations:



  
pkg://omnios/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151016:20151102T183750Z

  pkg://omnios/incorporation/jeos/illumos-gate@11,5.11-0.151016:20151102T185724Z

  
pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151016:20151102T185924Z

  pkg://omnios/entire@11,5.11-0.151016:20151102T202622Z



The following indicates why the system cannot update to the latest version:



  No suitable version of required package 
pkg://omnios/network/openssh@7.1.1,5.11-0.151016:20151102T190704Z found:

Reject:  pkg://omnios/network/openssh@7.1.1,5.11-0.151016:20151102T190704Z

Reason:  Package contains 'exclude' dependency pkg:/network/ssh on 
installed package

  No suitable version of required package 
pkg://omnios/network/openssh-server@7.1.1,5.11-0.151016:20151102T190719Z found:

Reject:  
pkg://omnios/network/openssh-server@7.1.1,5.11-0.151016:20151102T190719Z

Reason:  Package contains 'exclude' dependency pkg:/service/network/ssh on 
installed package





This is a remote server , without remote management, so removing openssh 
manually seems like removing all my access.

Any tips?



Thanks,



Floris





...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] OmniOS r151014 update - needs reboot!

2015-09-16 Thread Floris van Essen ..:: House of Ancients Amstafs ::..



Hi All,

When i install the update, it no longer sees my HP Network card.
Even when installing the HP driver (NTXNxge.pkg), it will no longer see the PCI 
device.

When I perform a roll back, it comes back online straight away :

Sep 15 22:22:41 PSD01 genunix: [ID 805372 kern.info] pcplusmp: pciex8086,1096 
(e1000g) instance 0 irq 0x33 vector 0x60 ioapic 0xff intin 0xff is bound to cpu 
3
Sep 15 22:22:41 PSD01 genunix: [ID 469746 kern.info] NOTICE: e1000g0 registered
Sep 15 22:22:41 PSD01 genunix: [ID 805372 kern.info] pcplusmp: pciex8086,1096 
(e1000g) instance 1 irq 0x34 vector 0x61 ioapic 0xff intin 0xff is bound to cpu 0
Sep 15 22:22:41 PSD01 genunix: [ID 469746 kern.info] NOTICE: e1000g1 registered
Sep 15 22:22:42 PSD01 genunix: [ID 805372 kern.info] pcplusmp: pci4040,100 
(ntxn) instance 0 irq 0x35 vector 0x62 ioapic 0xff intin 0xff is bound to cpu 1
Sep 15 22:22:44 PSD01 genunix: [ID 435574 kern.info] NOTICE: e1000g0 link up, 
1000 Mbps, full duplex
Sep 15 22:22:44 PSD01 genunix: [ID 435574 kern.info] NOTICE: e1000g1 link up, 
1000 Mbps, full duplex
Sep 15 22:22:52 PSD01 genunix: [ID 469746 kern.info] NOTICE: ntxn0 registered
Sep 15 22:22:52 PSD01 genunix: [ID 805372 kern.info] pcplusmp: pci4040,100 
(ntxn) instance 1 irq 0x36 vector 0x63 ioapic 0xff intin 0xff is bound to cpu 2
Sep 15 22:22:53 PSD01 genunix: [ID 469746 kern.info] NOTICE: ntxn1 registered
Sep 15 22:22:54 PSD01 genunix: [ID 792948 kern.notice] NOTICE: ntxn0: NIC Link 
is up
Sep 15 22:22:54 PSD01 genunix: [ID 435574 kern.info] NOTICE: ntxn0 link up, 
1000 Mbps, full duplex
Sep 15 22:22:54 PSD01 genunix: [ID 805372 kern.info] pcplusmp: pci4040,100 
(ntxn) instance 2 irq 0x37 vector 0x64 ioapic 0xff intin 0xff is bound to cpu 3
Sep 15 22:22:54 PSD01 genunix: [ID 792948 kern.notice] NOTICE: ntxn1: NIC Link 
is up
Sep 15 22:22:54 PSD01 genunix: [ID 435574 kern.info] NOTICE: ntxn1 link up, 
1000 Mbps, full duplex
Sep 15 22:22:55 PSD01 genunix: [ID 469746 kern.info] NOTICE: ntxn2 registered
Sep 15 22:22:55 PSD01 genunix: [ID 805372 kern.info] pcplusmp: pci4040,100 
(ntxn) instance 3 irq 0x38 vector 0x65 ioapic 0xff intin 0xff is bound to cpu 0
Sep 15 22:22:56 PSD01 genunix: [ID 469746 kern.info] NOTICE: ntxn3 registered
Sep 15 22:22:56 PSD01 genunix: [ID 792948 kern.notice] NOTICE: ntxn2: NIC Link 
is up
Sep 15 22:22:56 PSD01 genunix: [ID 435574 kern.info] NOTICE: ntxn2 link up, 
1000 Mbps, full duplex
Sep 15 22:22:56 PSD01 genunix: [ID 792948 kern.notice] NOTICE: ntxn3: NIC Link 
is up
Sep 15 22:22:56 PSD01 genunix: [ID 435574 kern.info] NOTICE: ntxn3 link up, 
1000 Mbps, full duplex

The integrated e1000g driver/nics do not show this behavior

This concerns this card : 
http://h17007.www1.hp.com/us/en/enterprise/servers/supportmatrix/solaris.aspx
NC375i embedded NIC is supported with Solaris10 08/11 using the following 
driver / FW combination: NTXNxge-2.14-solaris10-i386 / FW 4.0.585.

Any ideas ?


...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Slow Drive Detection and boot-archive

2015-07-21 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

Michael,

I know v20 does cause lots of issue's.
V19 , to the best of my knowledge doesn't contain any, so I would downgrade to 
v19


Kr,


Floris
-Oorspronkelijk bericht-
Van: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] Namens 
Michael Talbott
Verzonden: dinsdag 21 juli 2015 4:57
Aan: Marion Hakanson hakan...@ohsu.edu
CC: omnios-discuss omnios-discuss@lists.omniti.com
Onderwerp: Re: [OmniOS-discuss] Slow Drive Detection and boot-archive

Thanks for the reply. The bios for the card is disabled already. The 8 second 
per drive scan happens after the kernel has already loaded and it is scanning 
for devices. I wonder if it's due to running newer firmware. I did update the 
cards to fw v.20.something before I moved to omnios. Is there a particular 
firmware version on the cards I should run to match OmniOS's drivers?



Michael Talbott
Systems Administrator
La Jolla Institute

 On Jul 20, 2015, at 6:06 PM, Marion Hakanson hakan...@ohsu.edu wrote:
 
 Michael,
 
 I've not seen this;  I do have one system with 120 drives and it 
 definitely does not have this problem.  A couple with 80+ drives are 
 also free of this issue, though they are still running OpenIndiana.
 
 One thing I pretty much always do here, is to disable the boot option 
 in the LSI HBA's config utility (accessible from the during boot after 
 the BIOS has started up).  I do this because I don't want the BIOS 
 thinking it can boot from any of the external JBOD disks;  And also 
 because I've had some system BIOS crashes when they tried to enumerate 
 too many drives.  But, this all happens at the BIOS level, before the 
 OS has even started up, so in theory it should not affect what you are 
 seeing.
 
 Regards,
 
 Marion
 
 
 
 Subject: Re: [OmniOS-discuss] Slow Drive Detection and boot-archive
 From: Michael Talbott mtalb...@lji.org
 Date: Fri, 17 Jul 2015 16:15:47 -0700
 To: omnios-discuss omnios-discuss@lists.omniti.com
 
 Just realized my typo. I'm using this on my 90 and 180 drive systems:
 
 # svccfg -s boot-archive setprop start/timeout_seconds=720 # svccfg -s 
 boot-archive setprop start/timeout_seconds=1440
 
 Seems like 8 seconds to detect each drive is pretty excessive.
 
 Any ideas on how to speed that up?
 
 
 
 Michael Talbott
 Systems Administrator
 La Jolla Institute
 
 On Jul 17, 2015, at 4:07 PM, Michael Talbott mtalb...@lji.org wrote:
 
 I have multiple NAS servers I've moved to OmniOS and each of them have 
 90-180 4T disks. Everything has worked out pretty well for the most part. 
 But I've come into an issue where when I reboot any of them, I'm getting 
 boot-archive service timeouts happening. I found a workaround of increasing 
 the timeout value which brings me to the following. As you can see below in 
 a dmesg output, it's taking the kernel about 8 seconds to detect each of the 
 drives. They're connected via a couple SAS2008 based LSI cards.
 
 Is this normal?
 Is there a way to speed that up?
 
 I've fixed my frustrating boot-archive timeout problem by adjusting the 
 timeout value from the default of 60 seconds (I guess that'll work ok on 
 systems with less than 8 drives?) to 8 seconds * 90 drives + a little extra 
 time = 280 seconds (for the 90 drive systems). Which means it takes between 
 12-24 minutes to boot those machines up.
 
 # svccfg -s boot-archive setprop start/timeout_seconds=280
 
 I figure I can't be the only one. A little googling also revealed: 
 https://www.illumos.org/issues/4614 
 https://www.illumos.org/issues/4614
 
 Jul 17 15:40:15 store2 genunix: [ID 583861 kern.info] sd29 at 
 mpt_sas3: unit-address w5c0f0401bd43,0: w5c0f0401bd43,0 Jul 
 17 15:40:15 store2 genunix: [ID 936769 kern.info] sd29 is 
 /pci@0,0/pci8086,e06@2,2/pci1000,3080@0/iport@f/disk@w5c0f0401bd4
 3,0 Jul 17 15:40:16 store2 genunix: [ID 408114 kern.info] 
 /pci@0,0/pci8086,e06@2,2/pci1000,3080@0/iport@f/disk@w5c0f0401bd4
 3,0 (sd29) online Jul 17 15:40:24 store2 genunix: [ID 583861 
 kern.info] sd30 at mpt_sas3: unit-address w5c0f045679c3,0: 
 w5c0f045679c3,0 Jul 17 15:40:24 store2 genunix: [ID 936769 
 kern.info] sd30 is 
 /pci@0,0/pci8086,e06@2,2/pci1000,3080@0/iport@f/disk@w5c0f045679c
 3,0 Jul 17 15:40:24 store2 genunix: [ID 408114 kern.info] 
 /pci@0,0/pci8086,e06@2,2/pci1000,3080@0/iport@f/disk@w5c0f045679c
 3,0 (sd30) online Jul 17 15:40:33 store2 genunix: [ID 583861 
 kern.info] sd31 at mpt_sas3: unit-address w5c0f045712b3,0: 
 w5c0f045712b3,0 Jul 17 15:40:33 store2 genunix: [ID 936769 
 kern.info] sd31 is 
 /pci@0,0/pci8086,e06@2,2/pci1000,3080@0/iport@f/disk@w5c0f045712b
 3,0 Jul 17 15:40:33 store2 genunix: [ID 408114 kern.info] 
 /pci@0,0/pci8086,e06@2,2/pci1000,3080@0/iport@f/disk@w5c0f045712b
 3,0 (sd31) online Jul 17 15:40:42 store2 genunix: [ID 583861 
 kern.info] sd32 at mpt_sas3: unit-address w5c0f04571497,0:

[OmniOS-discuss] heads up

2015-03-26 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

Hi Dann,

Running latest Bloody , and after running a weekly check of available updates :

pkg update -nv
Creating Plan (Running solver): |
pkg update: No solution was found to satisfy constraints
Plan Creation: Package solver has not found a solution to update to latest 
available versions.
This may indicate an overly constrained set of packages are installed.

latest incorporations:

  
pkg://omnios/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151014:20150324T181107Z

The following indicates why the system cannot update to the latest version:

  No suitable version of required package 
pkg://omnios/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151014:20150324T181107Z
 found:
Reject:  
pkg://omnios/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151014:20150324T181107Z
Reason:  A version for 'incorporate' dependency on 
pkg:/SUNWcs@0.5.11,5.11-0.151014 cannot be found

Can I just install osnet-incorporation@0.5.11,5.11-0.151014:20150324T181107Z ?

Best regards,

Floris
...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] FINALLY - OmniOS bloody is now updated. (long, please read)

2015-02-03 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

Hi Dan,

Actually, they have, although those weren’t a major upgrade.
Any chance of these drivers making it within the standard OmniOS Drivers 
packages ?

These seem to be in Oracle Solaris :

http://docs.oracle.com/cd/E19253-01/816-5177/6mbbc4g8l/index.html

and are HP Nic drivers
genunix: [ID 469746 kern.info] NOTICE: ntxn0 registered
genunix: [ID 805372 kern.info] pcplusmp: pci4040,100 (ntxn) instance 1 irq 0x36 
vector 0x63 ioapic 0xff intin 0xff is bound to cpu 2
genunix: [ID 792948 kern.notice] NOTICE: ntxn0: NIC Link is up
genunix: [ID 435574 kern.info] NOTICE: ntxn0 link up, 1000 Mbps, full duplex


Met vriendelijke groet / With kind regards,



   Floris van Essen

Van: Dan McDonald [mailto:dan...@omniti.com]
Verzonden: dinsdag 3 februari 2015 23:59
Aan: Floris van Essen ..:: House of Ancients Amstafs ::..
CC: omnios-discuss@lists.omniti.com
Onderwerp: Re: [OmniOS-discuss] FINALLY - OmniOS bloody is now updated. (long, 
please read)

Likely yes.  These drivers were installed manually?  Yeah, that's likely. Have 
they survived a prior pkg update?

Dan

Sent from my iPhone (typos, autocorrect, and all)

On Feb 3, 2015, at 5:38 PM, Floris van Essen ..:: House of Ancients Amstafs 
::.. i...@houseofancients.nlmailto:i...@houseofancients.nl wrote:
Hi Dan,

Immediately after updating, drivers for ntxn ethernet are gone ( they were 
manually installed, as I had “funky stuff” with the IGB nics), and need 
reinstalling.
Is that normal behavior?
Rolling back to the before snapshot, and drivers are there again, and traffic 
is back to normal

Met vriendelijke groet / With kind regards,



   Floris van Essen

Van: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] Namens Dan 
McDonald
Verzonden: dinsdag 3 februari 2015 21:36
Aan: omnios-discuss@lists.omniti.commailto:omnios-discuss@lists.omniti.com
Onderwerp: [OmniOS-discuss] FINALLY - OmniOS bloody is now updated. (long, 
please read)

There is no TL;DR for this.  Please read all of this before you upgrade.

This is a big one.  I've updated install media AND the repo servers. Users who 
use pkg update will be getting a big wad (I'm not taking chances with missed 
packages or components).  I'm sorry it took longer than I expected, but there 
was an illumos-gate ZFS bug (5531) I wanted fixed before I released the next 
bloody update.

This is r151013-20150203:

- omnios-build master branch, revision 0c38601

- NEW UPDATE to pkg(5).  This carries a LOT with it, and gets its own section 
below.

- OpenSSL is now at 1.0.2.

- One bugfix to illumos-kvm-cmd that needed to be cherrypicked (because we 
can't catch up until VND is upstreamed from SmartOS).

- Longstanding bug with GCC 4.4.4's cc1 not being properly linked. (Thanks 
Richard Yao of ZFS-on-Linux for catching this.)

- Curl is now at 7.40.0.

- NTP dependency fix, from the community. (Thanks to takashiary.)

- Git is now at 2.2.1.

- ncurses have their auxiliary libs now in /usr/gnu/lib.  (Thanks to Lauri 
lotheac Tirkkonen.)

- illumos-omnios master branch, revision aef6850 (last illumos-gate merge 
6309835)

- Several ZFS enhancements, and sometimes followup fixes for them (one, 5531, 
was what made this release take longer than it should have).

- dis(1) supports cross-target disassembly  (Illumos 3317)

- NFS improvements in the authentication cache (Illumos 5509)

- Several ELF safety improvements from Rich Lowe.

- kmem_reap() performance improvements

- preadv() and pwritev()
 NOTE: KVM's poor handling of these (assuming all the world's Linux) is why we 
have a cherrypick above.

- illumos-side hwdata (PCI  USB) updates.  (NOTE: OmniOS keeps a copy in 
omnios-userland, that will be updated closer to 014's release).

- Developer prototypes updated to 2015

- Introducing the linked-ipkg (lipkg) zone brand.  See below about how this 
relates to the new pkg(5) changes.

- Reducing RAM used in managing ZFS cache devices

- Many new, corrected, and updated man pages.

- Longstanding mailx(1) overflow fixes now in place.


NEW FOR 2015 -- updated pkg(5)

You may have known this from previous bloody releases, but we've been using the 
same oldish version of pkg(5) since at least r151006 in OmniOS.  Bloody 
releases have had a half-finished pkg(5) that breaks things like zoneadm -z 
zone attach -u.  When a release came, we reverted to the old r151006 version 
of pkg(5).  That changes now.

If you're interested in source, our new repo for pkg(5) is 
http://github.com/omniti-labs/pkg5 or 
src.omniti.comhttp://src.omniti.com:~omnios/core/pkg5.  It's a downstream of 
OI Hipster's for now.

The OpenIndiana Hipster folks have done some work to bring pkg(5) more up to 
date with its upstream. The new pkg(5) contains many under-the-hood 
improvements. It also includes two user-visible improvements:

- A bit more visible status information during pkg(1) operations.

- The ability to link images.

Linked images is the big one.  Way upstream, linked images

Re: [OmniOS-discuss] FINALLY - OmniOS bloody is now updated. (long, please read)

2015-02-03 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

Hi Dan,

Immediately after updating, drivers for ntxn ethernet are gone ( they were 
manually installed, as I had funky stuff with the IGB nics), and need 
reinstalling.
Is that normal behavior?
Rolling back to the before snapshot, and drivers are there again, and traffic 
is back to normal

Met vriendelijke groet / With kind regards,



   Floris van Essen

Van: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] Namens Dan 
McDonald
Verzonden: dinsdag 3 februari 2015 21:36
Aan: omnios-discuss@lists.omniti.com
Onderwerp: [OmniOS-discuss] FINALLY - OmniOS bloody is now updated. (long, 
please read)

There is no TL;DR for this.  Please read all of this before you upgrade.

This is a big one.  I've updated install media AND the repo servers. Users who 
use pkg update will be getting a big wad (I'm not taking chances with missed 
packages or components).  I'm sorry it took longer than I expected, but there 
was an illumos-gate ZFS bug (5531) I wanted fixed before I released the next 
bloody update.

This is r151013-20150203:

- omnios-build master branch, revision 0c38601

- NEW UPDATE to pkg(5).  This carries a LOT with it, and gets its own section 
below.

- OpenSSL is now at 1.0.2.

- One bugfix to illumos-kvm-cmd that needed to be cherrypicked (because we 
can't catch up until VND is upstreamed from SmartOS).

- Longstanding bug with GCC 4.4.4's cc1 not being properly linked. (Thanks 
Richard Yao of ZFS-on-Linux for catching this.)

- Curl is now at 7.40.0.

- NTP dependency fix, from the community. (Thanks to takashiary.)

- Git is now at 2.2.1.

- ncurses have their auxiliary libs now in /usr/gnu/lib.  (Thanks to Lauri 
lotheac Tirkkonen.)

- illumos-omnios master branch, revision aef6850 (last illumos-gate merge 
6309835)

- Several ZFS enhancements, and sometimes followup fixes for them (one, 5531, 
was what made this release take longer than it should have).

- dis(1) supports cross-target disassembly  (Illumos 3317)

- NFS improvements in the authentication cache (Illumos 5509)

- Several ELF safety improvements from Rich Lowe.

- kmem_reap() performance improvements

- preadv() and pwritev()
 NOTE: KVM's poor handling of these (assuming all the world's Linux) is why we 
have a cherrypick above.

- illumos-side hwdata (PCI  USB) updates.  (NOTE: OmniOS keeps a copy in 
omnios-userland, that will be updated closer to 014's release).

- Developer prototypes updated to 2015

- Introducing the linked-ipkg (lipkg) zone brand.  See below about how this 
relates to the new pkg(5) changes.

- Reducing RAM used in managing ZFS cache devices

- Many new, corrected, and updated man pages.

- Longstanding mailx(1) overflow fixes now in place.


NEW FOR 2015 -- updated pkg(5)

You may have known this from previous bloody releases, but we've been using the 
same oldish version of pkg(5) since at least r151006 in OmniOS.  Bloody 
releases have had a half-finished pkg(5) that breaks things like zoneadm -z 
zone attach -u.  When a release came, we reverted to the old r151006 version 
of pkg(5).  That changes now.

If you're interested in source, our new repo for pkg(5) is 
http://github.com/omniti-labs/pkg5 or src.omniti.com:~omnios/core/pkg5.  It's a 
downstream of OI Hipster's for now.

The OpenIndiana Hipster folks have done some work to bring pkg(5) more up to 
date with its upstream. The new pkg(5) contains many under-the-hood 
improvements. It also includes two user-visible improvements:

- A bit more visible status information during pkg(1) operations.

- The ability to link images.

Linked images is the big one.  Way upstream, linked images are the new default 
for ipkg-branded zones (i.e. the zones all OmniOS folks use). In OI Hipster, 
linked-images are currently disabled.  We decided to take a middle ground:


THE LINKED IPS BRAND (lipkg)

Currently deployed ipkg-branded zones stay the same as they have in previous 
OmniOS releases.  You update them how you're used to updating them:  Either the 
documented OmniOS way, or Dan's way, where you mount the newly upgraded BE 
and then update each zone prior to reboot.

If you detach a zone:  (zoneadm -z zone halt ; zoneadm -z zone detach) you 
may change its brand the the new linked-ipkg (lipkg) brand.  The default for a 
new zone is still ipkg, so if you want lipkg, you must explicitly set 
brand=lipkg in the zonecfg interaction or script.

How to convert an existing ipkg zone to an lipkg zone:

1.) Install the lipkg brand:  pkg install lipkg.

2.) Halt and detach the zone.  zoneadm -z zone halt ; zoneadm -z zone 
detach

3.) Change the zone's brand:  zonecfg -z zone set brand=lipkg.

4.) Attach the zone with the -u flag. pkg(5) needs to run its update check 
regardless:  zoneadm -z zone attach -u.

5.) Boot the zone: zoneadm -z zone boot.

The zone zone's image will be linked to the global zone's image.

Once you are running with lipkg zones, new things happen upon subsequent pkg 
updates.  Any packages in the global

Re: [OmniOS-discuss] VAAI Testing

2015-01-20 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

I would be more than willing to test too!

Met vriendelijke groet / With kind regards,



   Floris van Essen

Van: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] Namens W 
Verb
Verzonden: dinsdag 20 januari 2015 3:59
Aan: omnios-discuss@lists.omniti.com
Onderwerp: [OmniOS-discuss] VAAI Testing

Hi All,

After seeing the recent message regarding ZFS, iSCSI, zvols and ESXi, I decided 
to follow up on where full VAAI support is.

I found Dan’s message from August: 
http://lists.omniti.com/pipermail/omnios-discuss/2014-August/002957.html

Is anyone working on his points 1 and 2?

Is anyone keeping track of the testing offers for #3?

I do a fair amount of SQA, and am willing to organize and write tests if 
needed. I also have a reasonable lab environment with which to test the code.

-Warren V

...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LACP Omnios , igb and C3750

2014-12-13 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

So,

To add to the weirdness.

Got ready to reinstall the whole machine, to set the interface back to DHCP, 
set it back to VLAN I could use for reinstalling, was about to clear the arp 
table, and then I noticed something very strange :

Sh arp
Internet  x.x.x.10452   a036.9f17.abc0  ARPA   Vlanx

Wait, that is the mac of my IGB interface...  did I miss something ?

ifconfig
igb0: flags=1004843UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4 mtu 1500 
index 13
 inet 0.0.0.0 netmask ff00
 ether a0:36:9f:17:ab:c0

so it did do an ARP, did get an IP from DHCP server, but it's simply not 
registering on the Omnios box...
This means hardware, and drivers are ok!

then I booted the machine using a KNOPPIX os, just to confirm my suspicions 
about the hardware and got ip x.x.x.104 on IGB0

I think this is something within Omnios , however, would like some pointers 
where to look

Met vriendelijke groet / With kind regards,



   Floris van Essen

-Oorspronkelijk bericht-
Van: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] Namens 
Floris van Essen ..:: House of Ancients Amstafs ::..
Verzonden: vrijdag 12 december 2014 18:11
Aan: Dan McDonald
CC: omnios-discuss@lists.omniti.com
Onderwerp: Re: [OmniOS-discuss] LACP Omnios , igb and C3750






 On Dec 12, 2014, at 11:49 AM, Floris van Essen ..:: House of Ancients Amstafs 
 ::.. i...@houseofancients.nl wrote:
 
 Hi Dann,
 
 No problem, just happy you did :-)
 
 Right, so as might remember I had to reinstall because I was running 
 bloody R11 , but there was a problem upgrading , so just did a fresh install 
 Had to skip r12 because I simply couldn't install it, as there was a 
 installer issue with r12...

 Weird.  I JUST updated the 012 install media thanks to illumos #5421, so you 
 may want to try that again.

Did the installation 2 weeks ago, so guessing that that was before you did the 
changes.
No problem, I'll update to stable next release :-)

 So here we are again, running bloody r13 , fully updated :-)
 
 # dladm show-ether
 LINKPTYPESTATEAUTO  SPEED-DUPLEXPAUSE
 e1000g1 current  up   yes   1G-fbi
 e1000g0 current  up   yes   1G-fbi
 igb0current  up   yes   1G-fbi
 igb1current  up   yes   1G-fbi
 igb2current  up   yes   1G-fbi
 igb3current  up   yes   1G-fbi
 # dladm show-link
 LINKCLASS MTUSTATEBRIDGE OVER
 e1000g1 phys  1500   up   -- --
 e1000g0 phys  1500   up   -- --
 aggr0   aggr  1500   up   -- e1000g0 e1000g1
 igb0phys  1500   up   -- --
 igb1phys  1500   up   -- --
 igb2phys  1500   up   -- --
 igb3phys  1500   up   -- --

Tis all looks sane.  You're showing 1Gig, full dupliex, and up.  This seems 
sane.

 # ifconfig -a
 lo0: flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL mtu 8232 
 index 1
inet 127.0.0.1 netmask ff00
 aggr0: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 2
inet x.x.x.11 netmask ff00 broadcast x.x.x.255
ether 0:30:48:d5:ec:94

And you have no problems pinging x.x.x.0/24 addresses?  Or do you?

Non, actually connecting on that interface with ssh

 igb0: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 3
inet 192.168.0.1 netmask ff00 broadcast 192.168.0.255
ether a0:36:9f:2:c2:6c
 igb1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 4
inet 192.168.0.2 netmask ff00 broadcast 192.168.0.255
ether a0:36:9f:2:c2:6d
 igb2: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 5
inet 192.168.0.3 netmask ff00 broadcast 192.168.0.255
ether a0:36:9f:2:c2:6e
 igb3: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 6
inet 192.168.0.4 netmask ff00 broadcast 192.168.0.255
ether a0:36:9f:2:c2:6f

Now I can totally see some potential confusion here.  You've four addrs all 
in the same netstack and all with the same prefix.  Now granted, they're 
different MAC addresses, but packets coming in on one interface may have 
their return traffic going out another.

If these are the problem, try using just one (igb0) for starters and 
ifconfig igbX down for 1, 2, and 3.

That is exactly what i did.. for each test brought the others down Just to add, 
when doing a  SH ARP on my cisco's, don't see the macs popping up, which is 
even more worring , no arps on a switch usually is very bad news

Also, I need to ask -- are either of your e1000g0's shared IPMI/host links?  
If so, disable the sharing

Re: [OmniOS-discuss] LACP Omnios , igb and C3750

2014-12-13 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

Hi Dan,

Yes you did mention it,and I confirmed that is not the case.
System Configuration: Supermicro X7DB8
BIOS Configuration: Phoenix Technologies LTD 2.1c 07/04/2011
BMC Configuration: IPMI 1.0 (unknown)


Met vriendelijke groet / With kind regards,



   Floris van Essen 

-Oorspronkelijk bericht-
Van: Dan McDonald [mailto:dan...@omniti.com] 
Verzonden: zaterdag 13 december 2014 17:13
Aan: Floris van Essen ..:: House of Ancients Amstafs ::..
CC: omnios-discuss@lists.omniti.com
Onderwerp: Re: [OmniOS-discuss] LACP Omnios , igb and C3750

I thought I'd mentioned this on the thread, but does the machine attempt to use 
one of the IGB interfaces for IPMI as well?  We do not support dual-use NICs 
like that.  (Check your BIOS.)

Dan



Sent from my iPhone (typos, autocorrect, and all)

 On Dec 13, 2014, at 9:01 AM, Floris van Essen ..:: House of Ancients Amstafs 
 ::.. i...@houseofancients.nl wrote:
 
 So i replaced the Igb adapter with a HP NC375t, loaded the drivers from 
 HP,left cables and switch alone :
 
 ntxn0   ntxn0   Ethernet   up   1000   full   BOUND   
 192.168.249.104   255.255.255.0   78:ac:c0:11:d4:88   1500
ok 
 ntxn1   ntxn1   Ethernet   unknown   1000   full   
 static   unset   -   -   1500
 ntxn2   ntxn2   Ethernet   unknown   1000   full   
 static   unset   -   -   1500
 ntxn3   ntxn3   Ethernet   unknown   1000   full   
 static   unset   -   -   1500 
 
 this all lead me to conclude that there is something wrong with the 
 IGB implementation as it sits Weather it be drivers, or something more 
 to the background..don't know, but would love to find out
 
 Met vriendelijke groet / With kind regards,
 
 
 
Floris van Essen
 
 -Oorspronkelijk bericht-
 Van: Floris van Essen ..:: House of Ancients Amstafs ::.. 
 Verzonden: zaterdag 13 december 2014 11:38
 Aan: Dan McDonald
 CC: omnios-discuss@lists.omniti.com
 Onderwerp: Re: [OmniOS-discuss] LACP Omnios , igb and C3750
 
 So,
 
 To add to the weirdness.
 
 Got ready to reinstall the whole machine, to set the interface back to DHCP, 
 set it back to VLAN I could use for reinstalling, was about to clear the arp 
 table, and then I noticed something very strange :

Sh arp
Internet  x.x.x.10452   a036.9f17.abc0  ARPA   Vlanx
 
 Wait, that is the mac of my IGB interface...  did I miss something ?

ifconfig
igb0: flags=1004843UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4 mtu 1500 
 index 13
inet 0.0.0.0 netmask ff00
ether a0:36:9f:17:ab:c0
 
 so it did do an ARP, did get an IP from DHCP server, but it's simply not 
 registering on the Omnios box...
 This means hardware, and drivers are ok!
 
 then I booted the machine using a KNOPPIX os, just to confirm my 
 suspicions about the hardware and got ip x.x.x.104 on IGB0
 
 I think this is something within Omnios , however, would like some 
 pointers where to look
 
 Met vriendelijke groet / With kind regards,
 
 
 
Floris van Essen
 
 -Oorspronkelijk bericht-
 Van: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] Namens 
 Floris van Essen ..:: House of Ancients Amstafs ::..
 Verzonden: vrijdag 12 december 2014 18:11
 Aan: Dan McDonald
 CC: omnios-discuss@lists.omniti.com
 Onderwerp: Re: [OmniOS-discuss] LACP Omnios , igb and C3750
 
 
 
 
 
 
 On Dec 12, 2014, at 11:49 AM, Floris van Essen ..:: House of Ancients 
 Amstafs ::.. i...@houseofancients.nl wrote:
 
 Hi Dann,
 
 No problem, just happy you did :-)
 
 Right, so as might remember I had to reinstall because I was running 
 bloody R11 , but there was a problem upgrading , so just did a fresh install 
 Had to skip r12 because I simply couldn't install it, as there was a 
 installer issue with r12...
 
 Weird.  I JUST updated the 012 install media thanks to illumos #5421, so 
 you may want to try that again.
 
 Did the installation 2 weeks ago, so guessing that that was before you did 
 the changes.
 No problem, I'll update to stable next release :-)
 
 So here we are again, running bloody r13 , fully updated :-)
 
 # dladm show-ether
 LINKPTYPESTATEAUTO  SPEED-DUPLEXPAUSE
 e1000g1 current  up   yes   1G-fbi
 e1000g0 current  up   yes   1G-fbi
 igb0current  up   yes   1G-fbi
 igb1current  up   yes   1G-fbi
 igb2current  up   yes   1G-fbi
 igb3current  up   yes   1G-fbi
 # dladm show-link
 LINKCLASS MTUSTATEBRIDGE OVER
 e1000g1 phys  1500   up

Re: [OmniOS-discuss] LACP Omnios , igb and C3750

2014-12-12 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

 ..:: House of Ancients Amstafs ::..
CC: omnios-discuss@lists.omniti.com
Onderwerp: Re: [OmniOS-discuss] LACP Omnios , igb and C3750

Sorry for not replying earlier.

 On Dec 12, 2014, at 10:24 AM, Floris van Essen ..:: House of Ancients Amstafs 
 ::.. i...@houseofancients.nl wrote:
 
 Hi All,
  
 this just keeps getting stranger by the minute.
 after removing the aggr's and setting a static ip on each interface, i 
 can ping from the host itself, but not through a wire, direct or through a 
 switch.
 plugged in a new intel i350, same deal... 
 when looking at the driver, i see that the is a update date of november 6
  
 does anybody have an idea what could be going on ?

You were smart to reduce it to individual igb links first.

Please remind me what revision of OmniOS you have?

Also, please share the output of:

- dladm show-ether
- dladm show-link
- ifconfig -a
- netstat -rnv

Thanks,
Dan


...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LACP Omnios , igb and C3750

2014-12-12 Thread Floris van Essen ..:: House of Ancients Amstafs ::..


 
 If these are the problem, try using just one (igb0) for starters and 
 ifconfig igbX down for 1, 2, and 3.
 
 That is exactly what i did.. for each test brought the others down 
 Just to add, when doing a  SH ARP on my cisco's, don't see the macs 
 popping up, which is even more worring , no arps on a switch usually 
 is very bad news

And you've eliminated the switch as a problem?  I ask because of this recent 
push (don't let the commit date fool you, this went in in November):

Yes... using the e1000g's and the same switch/etherchannel works flawless, 
also, using one of my vmware machines, and testing the same etherchannel works 
perfect.
Beside this is a cisco c3750 e, running 12.2 firmware, which is about as proven 
as the way to rome :-)

commit b607c8a3bdb27d4fde6e3fc4bb6617a1d91bdca7
Author: Keith M Wesolowski wesol...@foobazco.org
Date:   Tue Aug 5 22:08:11 2014 +

5337 igb/ixgbe mishandle raw packets if cable problem
Reviewed by: Robert Mustacchi r...@joyent.com
Reviewed by: Dan McDonald dan...@nexenta.com
Reviewed by: Jason King jason.brian.k...@gmail.com
Reviewed by: Garrett D'Amore garr...@damore.org
Approved by: Richard Lowe richl...@richlowe.net

 usr/src/uts/common/io/igb/igb_tx.c | 10 +++---
 usr/src/uts/common/io/ixgbe/ixgbe_tx.c |  6 --
 2 files changed, 11 insertions(+), 5 deletions(-)

This is the ONLY change since the February of 2014 support for I354 that's gone 
into the Intel GigE NIC code.

 Also, I need to ask -- are either of your e1000g0's shared IPMI/host 
 links?  If so, disable the sharing feature in the BIOS.  We don't cope with 
 shared-with-IPMI NICs.
 
 They are not... besides.. the e1000G's ( and their aggr) are working fully as 
 expected.
 To make it more interesting.. this was the same setup as I had on r11 
 , and then it did seem to work 100%

The only difference between 011  012 and 013 is the above commit.  You 
*could*, if you're feeling adventurous, swap out the igb driver in 013 with 
one from 012 or 011.  And if you unplumb all of the igbs (both in IPv4 and 
IPv6), you MAY be able to do it without rebooting.

As i can't use the machine for it's primairy function ( ISCSI target utilizing 
those i350's), rebooting it's any issue.
Just not sure as HOW to change that driver, so would be great if you'd have 
some pointers

Do you know which PCI ID your igb (it's an I350, right?) board is?  prtconf -d 
| grep -i network should be a quick way to show me that.

pci8086,1 (pciex8086,1521) [Intel Corporation I350 Gigabit Network Connection], 
instance #0
pci8086,1 (pciex8086,1521) [Intel Corporation I350 Gigabit Network 
Connection], instance #1
pci8086,1 (pciex8086,1521) [Intel Corporation I350 Gigabit Network 
Connection], instance #2
pci8086,1 (pciex8086,1521) [Intel Corporation I350 Gigabit Network 
Connection], instance #3


floris
...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LACP Omnios , igb and C3750

2014-12-12 Thread Floris van Essen ..:: House of Ancients Amstafs ::..


 
 And you've eliminated the switch as a problem?  I ask because of this recent 
 push (don't let the commit date fool you, this went in in November):
 
 Yes... using the e1000g's and the same switch/etherchannel works flawless, 
 also, using one of my vmware machines, and testing the same etherchannel 
 works perfect.
 Beside this is a cisco c3750 e, running 12.2 firmware, which is about as 
 proven as the way to rome :-)

Okay, if the e1000gs work, then fine.

I'm assuming you've checked out the cables as well...

New cables, cables tested with e1000 also perfect

 
 As i can't use the machine for it's primairy function ( ISCSI target 
 utilizing those i350's), rebooting it's any issue.
 Just not sure as HOW to change that driver, so would be great if you'd have 
 some pointers

You're running bloody, so you can do these normally not-recommended-for-users 
steps:

1.) Backup the original igb:   cp /kernel/drv/amd64/igb somewhere

2.) Find an igb from 011 or 012.  Exercise left to the reader.  If you have an 
old boot-environment, beadm mount it and grab it from there.

As i had to do a reinstall , there's no r11 stuff left.
R12 was never installed... 

Is there a way to download this somewere from github or maybe some source ?

3.) Replace /kernel/drv/amd64/igb with the older version.

4.) Utter bootadm update-archive to make sure the replacement igb is there.

5.) Reboot.


Dan

...:: House of Ancients ::...
American Staffordshire Terriers

+31-628-161-350
+31-614-198-389
Het Perk 48
4903 RB
Oosterhout
Netherlands
www.houseofancients.nl
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] LACP Omnios , igb and C3750

2014-12-08 Thread Floris van Essen ..:: House of Ancients Amstafs ::..

Guys,
been having a odd issue with my Omnios box and c3750
the omnios box has 6 interfaces ( 2 e1000g and 4 igb)
somehow the LACP bonding between the igb's and my cisco's will not stay in 
sync, while the same lacp config runs fine over the e1000's :
channel 5 = e1000g's channel 6 and 7 are the igb's :
Channel group 5 neighbors
Partner's information:
LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Gi1/0/14 FA 4096 0030.48d5.ec94 23s 0x0 0x3E8 0x2 0x3F
Gi2/0/14 FA 4096 0030.48d5.ec94 23s 0x0 0x3E8 0x1 0x3F
Channel group 6 neighbors
Partner's information:
LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Gi1/0/10 FA 4096 a036.9f02.c13a 0s 0x0 0x3EA 0x6 0x47
Gi1/0/12 FA 4096 a036.9f02.c13a 0s 0x0 0x3EA 0x5 0x47
Channel group 7 neighbors
Partner's information:
LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Gi2/0/10 FA 4096 a036.9f02.c138 0s 0x0 0x3E9 0x4 0x47
Gi2/0/11 FA 4096 a036.9f02.c138 0s 0x0 0x3E9 0x3 0x47
LINK POLICY ADDRPOLICY LACPACTIVITY LACPTIMER FLAGS
aggr0 L4 auto active short -
aggr1 L4 auto active short -
aggr2 L4 auto active short -
aggr0 -- up 1000Mb full static x.x.x.x 255.255.255.0 x:x:x:x:x:x 1500
e1000g0 attached up 1000Mb full - - - x:x:x:x:x:x 1500
e1000g1 attached up 1000Mb full - - - x:x:x:x:x:x 1500
aggr1 -- up 1000Mb full static x.x.x.x 255.255.255.0 x:x:x:x:x:x 1500
igb0 attached up 1000Mb full - - - x:x:x:x:x:x 1500
igb1 attached up 1000Mb full - - - x:x:x:x:x:x 1500
aggr2 -- up 1000Mb full static x.x.x.x 255.255.255.0 x:x:x:x:x:x 1500
igb2 attached up 1000Mb full - - - x:x:x:x:x:x 1500
igb3 attached up 1000Mb full - - - x:x:x:x:x:x 1500
058673: Dec 8 22:15:51.593: lacp_mux Gi2/0/10 - mux: during state WAITING, got 
event 1(selected)
058674: Dec 8 22:15:51.593: @@@ lacp_mux Gi2/0/10 - mux: WAITING - WAITING
058675: Dec 8 22:15:51.593: LACP: Gi2/0/10 lacp_action_mx_waiting entered
058676: Dec 8 22:15:51.593: LACP: timer lacp_w(Gi2/0/10) started with interval 
2000.
058677: Dec 8 22:15:51.895: LACP :lacp_bugpak: Receive LACP-PDU packet via 
Gi2/0/10
058678: Dec 8 22:15:51.895: LACP : packet size: 124
058679: Dec 8 22:15:51.895: LACP: pdu: subtype: 1, version: 1
058680: Dec 8 22:15:51.895: LACP: Act: tlv:1, tlv-len:20, key:0x3E9, 
p-pri:0x1000, p:0x4, p-state:0x47,
s-pri:0x1000, s-mac:a036.9f02.c138
058681: Dec 8 22:15:51.895: LACP: Part: tlv:2, tlv-len:20, key:0x0, p-pri:0x0, 
p:0x0, p-state:0xA,
s-pri:0x0, s-mac:..
058682: Dec 8 22:15:51.895: LACP: col-tlv:3, col-tlv-len:16, col-max-d:0xA
058683: Dec 8 22:15:51.895: LACP: term-tlv:0 termr-tlv-len:0
058684: Dec 8 22:15:51.895: LACP: Gi2/0/10 LACP packet received, processing
058685: Dec 8 22:15:51.895: lacp_rx Gi2/0/10 - rx: during state CURRENT, got 
event 5(recv_lacpdu)
058686: Dec 8 22:15:51.895: @@@ lacp_rx Gi2/0/10 - rx: CURRENT - CURRENT
058687: Dec 8 22:15:51.895: LACP: Gi2/0/10 lacp_action_rx_current entered
058688: Dec 8 22:15:51.895: LACP: Gi2/0/10 set to UNSELECTED
058689: Dec 8 22:15:51.895: lacp_mux Gi2/0/10 - mux: during state WAITING, got 
event 3(unselected)
058690: Dec 8 22:15:51.895: @@@ lacp_mux Gi2/0/10 - mux: WAITING - DETACHED
058691: Dec 8 22:15:51.895: LACP: Gi2/0/10 lacp_action_mx_detached entered
058692: Dec 8 22:15:51.895: LACP: Gi2/0/10 Resetting hw_sw constraints
058693: Dec 8 22:15:51.895: LACP: lacp_insert_partner_cd_inhibitor: didn't 
change sync flag.
058694: Dec 8 22:15:51.895: LACP: lacp_send_lacpdu: (Gi2/0/10) About to send 
the 110 LACPDU
058695: Dec 8 22:15:51.895: LACP :lacp_bugpak: Send LACP-PDU packet via Gi2/0/10
058696: Dec 8 22:15:51.895: LACP : packet size: 124
058697: Dec 8 22:15:51.895: LACP: pdu: subtype: 1, version: 1
058698: Dec 8 22:15:51.895: LACP: Act: tlv:1, tlv-len:20, key:0x7, 
p-pri:0x8000, p:0x20B, p-state:0x5,
s-pri:0x8000, s-mac:0019.aa89.b580
058699: Dec 8 22:15:51.895: LACP: Part: tlv:2, tlv-len:20, key:0x3E9, 
p-pri:0x1000, p:0x4, p-state:0x47,
s-pri:0x1000, s-mac:a036.9f02.c138
058700: Dec 8 22:15:51.895: LACP: col-tlv:3, col-tlv-len:16, col-max-d:0x8000
058701: Dec 8 22:15:51.895: LACP: term-tlv:0 termr-tlv-len:0
058702: Dec 8 22:15:51.895: LACP: lacp_write: LACP 124 bytes out Gi2/0/10
058703: Dec 8 22:15:51.895: lacp_handle_standby_port_internal called, depth = 1
058704: Dec 8 22:15:51.895: LACP: recordPDU Gi2/0/10 LACP PDU Rcvd. Partners 
oper state is hex 47
058705: Dec 8 22:15:51.895: LACP: recordPDU Gi2/0/10 Partner out of sync
058706: Dec 8 22:15:51.895: LACP: Gi2/0/10 Partners oper state is hex 47
058707: Dec 8 22:15:51.895: LACP: timer lacp_c_l(Gi2/0/10) started with 
interval 9.
058708: Dec 8 22:15:51.895: LACP: Gi2/0/10 LAG_PARTNER_UP.
058709: Dec 8 22:15:51.895: LACP: Gi2/0/10 LAG unchanged
058710: Dec 8 22:15:51.903: LACP: Gi2/0/10 STANDBY aggregator hex address is 
5FB71A4
058711: Dec 8 22:15:51.903: LACP: Gi2/0/10 set to STANDBY
058712: Dec 8 22:15:51.903: lacp_mux Gi2/0/10 - mux: during state DETACHED, got 
event 2(standby)

Re: [OmniOS-discuss] Questions about - End the uncertainty -

Re: [OmniOS-discuss] Bug ?

Re: [OmniOS-discuss] OmniOS r151022 is now out!

Re: [OmniOS-discuss] otherwise stable system sudden crashing

Re: [OmniOS-discuss] otherwise stable system sudden crashing

Re: [OmniOS-discuss] OmniOS-discuss Digest, Vol 44, Issue 7

Re: [OmniOS-discuss] OmniOS-discuss Digest, Vol 44, Issue 7

[OmniOS-discuss] OmniOS r151014 update - needs reboot!

Re: [OmniOS-discuss] Slow Drive Detection and boot-archive

[OmniOS-discuss] heads up

Re: [OmniOS-discuss] FINALLY - OmniOS bloody is now updated. (long, please read)

Re: [OmniOS-discuss] FINALLY - OmniOS bloody is now updated. (long, please read)

Re: [OmniOS-discuss] VAAI Testing

Re: [OmniOS-discuss] LACP Omnios , igb and C3750

Re: [OmniOS-discuss] LACP Omnios , igb and C3750

Re: [OmniOS-discuss] LACP Omnios , igb and C3750

Re: [OmniOS-discuss] LACP Omnios , igb and C3750

Re: [OmniOS-discuss] LACP Omnios , igb and C3750

[OmniOS-discuss] LACP Omnios , igb and C3750

19 matches

Site Navigation

Mail list logo

Footer information