Re: Netbooting a sparc64 (netbsd-6)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> On cisco 2924 switches, you can give the command:
> spanning-tree portfast default
> in the main configuration mode to turn off the 15 second
> auto-negotiation process.

In my case, I have "no spanning-tree vlan 1", "no spanning-tree vlan
2", "no spanning-tree vlan 3", etc.  I also have "spanning-tree
portfast" set on each interface.

It still doesn't work - I just tried it.  Copied from the console:

ok boot net -s
Boot device: /iommu/sbus/ledma@f,400010/le@f,c00000  File and args: -s
Lost Carrier  (transceiver cable problem?)  
Cable problem or twisted pair hub link-test disabled.
Use the PROM command "help ethernet" for more information.

Timeout waiting for ARP/RARP packet

The switch reports

Feb 29 15:05:43: %LINK-3-UPDOWN: Interface FastEthernet0/23, changed state to up
Feb 29 15:05:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
FastEthernet0/23, changed state to up

but apparently it didn't change state fast enough.

"help ethernet" output says, in part,

 For a TPE network, the 10BaseT Link-Integrity-Test function may be con-
 figured to be enabled or disabled.  For the TPE network port to work
 properly, the system should be configured the same as its network hub
 connection.  The system is normally configured with the 10BaseT compliant
 Link-Integrity-Test enabled.  The network hub's connection to the system
 should also be configured for Link-Integrity-Test enabled.  If you experience
 problems with the TPE interface, after making sure the cable is plugged in,
 contact your system administrator to check your network hub configuration.

It suggests "setenv tpe-link-test? false"; the default is true, but
setting it to false doesn't help - it makes it workse.  Then, my 2924
doesn't report link coming up at all, and netbooting doesn't work even
if I explicitly "boot net-tpe", which works fine with tpe-link-test?
set true.

The delay involved is also far less than 15 seconds.  More like one, or
maybe even less - I havne't tried to measure it.

So I'm pretty confident the problem, at least in my case, is not
spanning-tree.

I don't know how much of this is relevant to the original sparc64
problem.  But it does seem to me to indicate that issues talking with a
2924 may well not indicate driver bugs; my experience is with the
SS20's on-board Ethernet, which is not bge; it's Lance:

ledma0 at sbus0 slot 15 offset 0x400010: rev 2
le0 at ledma0 slot 15 offset 0xc00000 level 6: address 08:00:20:78:4e:79
le0: 8 receive buffers, 2 transmit buffers
le0: supplying EUI64: 08:00:20:ff:fe:78:4e:79

The syndrome I'm seeing is also OS-independent, as it happens entirely
before the ROMs even start to load the booter, much less the kernel.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B