This `tulip halting', is it `transmit timed out', following by the chip being thrown in 10-base2 mode and not recovering until ifconfig down/up?
I see that one on my PPC box, and I do have a fix. It's not perfect, but the box now recovers within 3 minutes, instead of needing manual intervention.
Gr{oetje,eeting}s,
Geert
To be honest, I'm not sure what's actually occuring. At first I thought it was simply halting, but it does not appear to halt completely. Data will still trickle in *very* slowly. If ping wouldn't time out after a few seconds, I would bet the box would respond after about 3 minutes. restarting the config does reset it back.
Now that you mention mode switching, however, May fit in with some data I gleaned using mii-diag that I spoke of in #mipslinux awhile back. When the tulip driver was working fine, mii-diag reported this:
MII PHY #1 transceiver registers: 1000 782d 7810 0003 01e1 45e1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4000 0000 3ffb 0010 0000 0002 0001 0000 0000 0000 0000 0000 0000 0000
Notice the setting of the 21st register (3rd row, 5th value). When the tulip driver started acting up, that value changed to this:
MII PHY #1 transceiver registers: 1000 782d 7810 0003 01e1 45e1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4000 0000 38c8 0010 0000 0002 0001 0000 0000 0000 0000 0000 0000 0000
I didn't do very detailed searching for the meaning of the registers, and never found out what the 21st register's specific purpose was, but is this the mode switching you're mentioning perhaps?
If so, I'll give your patch a run, see if it works and if the recovery time can be shortened, or help to isolate the problem so it can be nailed.
--Kumba
--
"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond
