> Richard Skelton writes:
> > Hi James,
> 
> I'll assume that's me.  ;-}  If you must use the
> Java/Jive interface
> rather than subscribing to the list with regular
> email, then please
> make a habit of copying in some context.  Otherwise,
> your message can
> easily get lost.
Sorry
> 
> > I have modified the file /kernel/drv/e1000g.conf as
> you suggested and did a sys-unconfig so I could set
> the e1000g as my main interface.
> 
> OK; that eliminates one possible culprit.
> 
> > It still fails for work :-(
> > I have run all the test you listed with results
> below.
> 
> It looks to me like the interface is working -- at
> least, I don't see
> errors here.  (Are you sure you want to use NIS ...
> ?)
> 
> There's just one suspicious-looking bit of output I
> can see here:
> 
> >         lp_cap_1000fdx                  0
> >         lp_cap_1000hdx                  0
> >         lp_cap_100T4                    0
> >         lp_cap_100fdx                   0
> >         lp_cap_100hdx                   0
> >         lp_cap_10fdx                    0
> >         lp_cap_10hdx                    0
> >         lp_cap_asmpause                 0
> >         lp_cap_autoneg                  0
> >         lp_cap_pause                    0
> >         lp_rem_fault                    0
> 
> This says that the link peer is refusing to do
> standard
> auto-negotiation, which is required on at least
> gigabit links.  We're
> _somehow_ getting to 100Mbps full duplex, but I don't
> quite see how
> that's happening, or if it matches the peer's
> configuration.
> 
> The first thing I'd check would be the configuration
> of that link
> partner (the other end of the wire) -- why isn't it
> doing standard
> auto-negotiation?  

The card is currently plugged into a 100 BaseT switch just to eliminate the 
1000 BaseT switch port as it's the last one in the switch and was not sure if 
it was faulty :-)

After checking that out, I'd
> probably contact the
> driver folks to ask about this state (either
> [EMAIL PROTECTED] or just file a bug
> through
> bugs.opensolaris.org).
> 
> -- 
> James Carlson, Solaris Networking
>              <[EMAIL PROTECTED]>
> ems / 35 Network Drive        71.232W   Vox +1 781
> 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N
>   Fax +1 781 442 1677
> _____________________________________________
> networking-discuss mailing list
> [email protected]
--
This message posted from opensolaris.org
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to