On Jun 26, 12:53pm, smj@cirr.com (Stephen Jones) wrote:
-- Subject: Re: Serious SCB Timeout problems in 2.0.2 on Alpha w/ fxp devices

| That was a possibility I had considered.  The fxp0 interfaces are on a 
| seperate
| hardware switch from the fxp1.  Remember the 'port assertion' problem 
| in 1.6.0
| about two years ago when a CS20 could effectively lock up an entire 
| switch?

I do remember that.

| I'll get the details on the cisco ethernet switches I'm using and their 
| differences in
| configuration.  Another thing to note is that I ran these all on 1.6.x 
| for 2+ years
| with only minimal SCB timeout issues .. it was never this frequent.  
| The only thing
| that has changed is I moved all the systems from 1.6.x to 2.0.2 in a 
| single event.

Can you try to move one of the interfaces to a cheap, non-managed ethernet
switch? Maybe it is something screwy in the MII autonegotiation process.

| The DS10Ls which don't use fxp (they're tulip) use the same switches 
| for front end
| and back end traffic and run very well.

Yes, the fxp driver is a lot different. I have a few x86s connected to
ciscos through fxp's. Each time I run tcpdump, I lose connectivity for
30 seconds or more because entering and exiting promiscuous mode forces
a chip reset, which starts a new autonegotiation cycle. I hate that, but
there seems to be no easy way to enter and exit promiscuous mode without
re-sending the data structure that has the complete settings to the chip.
I should try looking at the linux driver, because all the BSD's seem to
have the same problem.

christos