I give you... # dladm show-link LINK CLASS MTU STATE OVER e1000g0 phys 1500 up -- # dladm create-vnic -l e1000g0 vnic0 dladm: vnic creation over e1000g0 failed: object already exists # ifconfig vnic0 plumb ifconifg: cannot open link "vnic0": DLPI link does not exist I''ve opened CR#6798106 for this... Now while booting, there were messages on the console about e1000g1 and e1000g2 failing to plumb (I''d reconfigured those NICs out.) The error messages were about DL_ATTACH_REQ, etc, failing. Those error messages aren''t are recorded in /var/adm/messages nor dmesg output :-( Seems like 4116990...although I''d call that a bug, not an RFE...so CR#6798099. So what led to this... I was running with e1000g0,1,2 and then halted the vm. Removed all three NICs, then added back in a new e1000g0. Booted... I don''t know how it got into this state with vnic0... And it is reproducible over a reboot :-D I''ll upload a crash dump if someone wants to look at the various kernel structures and find my vnic0 :) btw, when we get this error: e1000g1: DL_ATTACH_REQ failed: DL_SYSERR (errno 22) Why isn''t it enacted upon? Why are we doing a DL_BIND_REQ and more if the attach fails? e1000g1: DL_BIND_REQ failed: DL_OUTSTATE e1000g1: DL_PHYS_ADDR_REQ failed: DL_OUTSTATE e1000g1: DL_UNBIND_REQ failed: DL_OUTSTATE Darren
Darren, Is this the same system where you earlier had the snoop/vnic issue? Seems like there is something strange with this system. Any chance you can give access to the system itself rather than just core dump? Thanks, Sunay Darren Reed wrote:> I give you... > > # dladm show-link > LINK CLASS MTU STATE OVER > e1000g0 phys 1500 up -- > # dladm create-vnic -l e1000g0 vnic0 > dladm: vnic creation over e1000g0 failed: object already exists > # ifconfig vnic0 plumb > ifconifg: cannot open link "vnic0": DLPI link does not exist > > I''ve opened CR#6798106 for this... > > Now while booting, there were messages on the console about > e1000g1 and e1000g2 failing to plumb (I''d reconfigured those > NICs out.) The error messages were about DL_ATTACH_REQ, etc, > failing. Those error messages aren''t are recorded in /var/adm/messages > nor dmesg output :-( Seems like 4116990...although I''d call > that a bug, not an RFE...so CR#6798099. > > So what led to this... > > I was running with e1000g0,1,2 and then halted the vm. > Removed all three NICs, then added back in a new e1000g0. > Booted... > > I don''t know how it got into this state with vnic0... > > And it is reproducible over a reboot :-D > I''ll upload a crash dump if someone wants to look at the > various kernel structures and find my vnic0 :) > > btw, when we get this error: > e1000g1: DL_ATTACH_REQ failed: DL_SYSERR (errno 22) > > Why isn''t it enacted upon? > Why are we doing a DL_BIND_REQ and more if the attach fails? > > e1000g1: DL_BIND_REQ failed: DL_OUTSTATE > e1000g1: DL_PHYS_ADDR_REQ failed: DL_OUTSTATE > e1000g1: DL_UNBIND_REQ failed: DL_OUTSTATE > > Darren > > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
Sunay Tripathi wrote:> Darren, > > Is this the same system where you earlier had the snoop/vnic issue?It is indeed.> Seems like there is something strange with this system. Any chance > you can give access to the system itself rather than just core dump?That''s going to be ... difficult this week. Next week will be easier. Darren> > Thanks, > Sunay > > Darren Reed wrote: >> I give you... >> >> # dladm show-link >> LINK CLASS MTU STATE OVER >> e1000g0 phys 1500 up -- >> # dladm create-vnic -l e1000g0 vnic0 >> dladm: vnic creation over e1000g0 failed: object already exists >> # ifconfig vnic0 plumb >> ifconifg: cannot open link "vnic0": DLPI link does not exist >> >> I''ve opened CR#6798106 for this... >> >> Now while booting, there were messages on the console about >> e1000g1 and e1000g2 failing to plumb (I''d reconfigured those >> NICs out.) The error messages were about DL_ATTACH_REQ, etc, >> failing. Those error messages aren''t are recorded in /var/adm/messages >> nor dmesg output :-( Seems like 4116990...although I''d call >> that a bug, not an RFE...so CR#6798099. >> >> So what led to this... >> >> I was running with e1000g0,1,2 and then halted the vm. >> Removed all three NICs, then added back in a new e1000g0. >> Booted... >> >> I don''t know how it got into this state with vnic0... >> >> And it is reproducible over a reboot :-D >> I''ll upload a crash dump if someone wants to look at the >> various kernel structures and find my vnic0 :) >> >> btw, when we get this error: >> e1000g1: DL_ATTACH_REQ failed: DL_SYSERR (errno 22) >> >> Why isn''t it enacted upon? >> Why are we doing a DL_BIND_REQ and more if the attach fails? >> >> e1000g1: DL_BIND_REQ failed: DL_OUTSTATE >> e1000g1: DL_PHYS_ADDR_REQ failed: DL_OUTSTATE >> e1000g1: DL_UNBIND_REQ failed: DL_OUTSTATE >> >> Darren >> >> _______________________________________________ >> crossbow-discuss mailing list >> crossbow-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss > >
On 2009?01?27? 06:35, Darren Reed wrote:> I give you... > > # dladm show-link > LINK CLASS MTU STATE OVER > e1000g0 phys 1500 up -- > # dladm create-vnic -l e1000g0 vnic0 > dladm: vnic creation over e1000g0 failed: object already exists > # ifconfig vnic0 plumb > ifconifg: cannot open link "vnic0": DLPI link does not exist > > I''ve opened CR#6798106 for this... >Is it possible that this vnic was created but only in the persistent form?> Now while booting, there were messages on the console about > e1000g1 and e1000g2 failing to plumb (I''d reconfigured those > NICs out.) The error messages were about DL_ATTACH_REQ, etc, > failing. Those error messages aren''t are recorded in /var/adm/messages > nor dmesg output :-( Seems like 4116990...although I''d call > that a bug, not an RFE...so CR#6798099. > > So what led to this... > > I was running with e1000g0,1,2 and then halted the vm. > Removed all three NICs, then added back in a new e1000g0. > Booted... > > I don''t know how it got into this state with vnic0... > > And it is reproducible over a reboot :-D > I''ll upload a crash dump if someone wants to look at the > various kernel structures and find my vnic0 :) > > btw, when we get this error: > e1000g1: DL_ATTACH_REQ failed: DL_SYSERR (errno 22) > > Why isn''t it enacted upon? > Why are we doing a DL_BIND_REQ and more if the attach fails? > > e1000g1: DL_BIND_REQ failed: DL_OUTSTATE > e1000g1: DL_PHYS_ADDR_REQ failed: DL_OUTSTATE > e1000g1: DL_UNBIND_REQ failed: DL_OUTSTATE >I think if you have these links DRed out, then it is expected and it should be the same as how it behaves before snv_106. Looking at ill_dl_phys(), it send bind_req no matter whether attach_req succeeded or not. Thanks - Cathy
> > btw, when we get this error:> > e1000g1: DL_ATTACH_REQ failed: DL_SYSERR (errno 22) > > > > Why isn''t it enacted upon? > > Why are we doing a DL_BIND_REQ and more if the attach fails? > > > > e1000g1: DL_BIND_REQ failed: DL_OUTSTATE > > e1000g1: DL_PHYS_ADDR_REQ failed: DL_OUTSTATE > > e1000g1: DL_UNBIND_REQ failed: DL_OUTSTATE > > > I think if you have these links DRed out, then it is expected and it > should be the same as how it behaves before snv_106. Looking at > ill_dl_phys(), it send bind_req no matter whether attach_req succeeded or not. Right, this is longstanding behavior in IP, unrelated to Crossbow. -- meem
On Tue, Jan 27, 2009 at 3:35 PM, Darren Reed <Darren.Reed at sun.com> wrote:> I give you... > > # dladm show-link > LINK CLASS MTU STATE OVER > e1000g0 phys 1500 up -- > # dladm create-vnic -l e1000g0 vnic0 > dladm: vnic creation over e1000g0 failed: object already exists > # ifconfig vnic0 plumb > ifconifg: cannot open link "vnic0": DLPI link does not exist > > I''ve opened CR#6798106 for this... >Hi, I saw a similar issue on Opensolaris 2008.11, updated to snv_105. I have reported it to the Opensolaris bug database, but did not get any response so far (and not bug id). I created 3 etherstubs and 2 vnics per etherstub, all working fine. After a crash of my system (freeze) ''dladm show-link'' did not show any of the virtual devices, but they were all in the datalink.conf file. The ''create-vnic'' and ''create-etherstub'' resulted in the same "object already exists" messages, plumbing created also the above error message. The workaround I found was deleting all virtual devices via ''delete-vnic'' and ''delete-etherstub'', which worked fine, and re-creating them again. This happened twice on my system so far. Regards, Marcus
Hello, i have Opensolaris 2008.11, updated to snv_109... and i have the same problem... after i create etherstub and vnics it works fine... but after reboot it disappeared. I try to re-create it, but see same message: object "already exists". i can show you all related information about my system p.s. information about it i can see in output of "dladm show-link -P" but not from "dladm show-vnic" or "dladm show-etherstub" -- This message posted from opensolaris.org
On Mar 22, 2009, at 7:33 AM, Daniil Churikov wrote:> Hello, i have Opensolaris 2008.11, updated to snv_109... and i have > the same problem... > after i create etherstub and vnics it works fine... but after reboot > it disappeared. I try to re-create it, but see same message: object > "already exists". > i can show you all related information about my system > p.s. > information about it i can see in output of "dladm show-link -P" but > not from "dladm show-vnic" or "dladm show-etherstub"Do you have NWAM enabled? It could be caused by 6776009 (nwam doesn''t bring up pseudo data-links at boot time.) Nicolas.> > -- > This message posted from opensolaris.org > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss-- Nicolas Droux - Solaris Kernel Networking - Sun Microsystems, Inc. droux at sun.com - http://blogs.sun.com/droux