That's different from what I'm seeing. My box doesn't respond at all.
That's what I thought was happening initially, but I noticed that a very, very minute trickle of data gets through. Not enough to really be useful, but it indicates that it isn't a total freeze. Things like ssh will eventually time out simply because they don't wait around long enough for a response.
I don't know what these registers mean, but tulip_select_media() doesn't seem to affect the 21st register directly. Perhaps as a hardware side effect?
I'm not too sure. The only tool I got running was mii-diag. tulip-diag won't compile on mips due to differences in the includes (I haven't tinkered with it enough to make it compile yet).
Here it is. I've been using it on 2.4.21 for more than 6 months. I upgraded to 2.4.23 9 days ago, and so far I haven't seen any of the printk()s, though.
Without the patch, the driver switches from 10-baseT to 10-base2 unconditionally if the problem happens. With the patch, the switch is performed only if there's no 10-baseT link beat, and the driver recovers after a few minutes. This may still cause an annoying hick up, but the network (incl. open TCP connections) recovers.
Well, this patch definitely alter's the tulip's behavior. It's staying up for longer periods of time. I have a gentoo install that I kludged on the cobalt over a pre-existing debian install, and before, an "emerge rsync" didn't even make its way through receiving the rsync file list. Now with this patch, "emerge rsync" got about 80% complete before tulip hung. I wound up powering the machine down and restarting it to get tulip to work again, and it lasted a good while before hanging again. I restarted the interface the second time, and now it's going fine, so I'll see if it hangs again.
When it does mess up, mii-diag reports the same exact change on the 21st register, so that means something...I just wish I knew what...
It would seem the patch does correct one of the conditions that makes tulip act up....It would appear there is another condition still triggering it, but not as frequently.
I have a 21041, using 10-baseT on a 10 Mbit hub. What Tulip does the Cube have?
My cobalt looks to have a Digital 21143-PD chip. I know it's got something funny with the eeprom, as it requires a kernel patch to read the eeprom properly and detect the chip in the first place. The machine itself is used in 100mbps mode on a 16-port netgear switch.
--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
