Kernel 2.4.23 on Cobalt Qube2

Hi.

Has anyone got a 2.4.23 kernel running on the Cobalt Qube 2 ?

I've cross compiled the latest kernel from CVS (using the default Cobalt config in the tree) on a PC using gcc 2.95.4 and binutils 2.12.90.0.1 (both from Debian sources).

The kernel boots okay from the HD, but I get strange segmentation faults and other errors whilst running Debian's "dpkg" to install packages. If I repeat the installation from scratch I get exactly the same errors in exactly the same places :-(

I've changed both the memory SIMMs for new ones and the problem is still the same. I've done the same Debian install on an Au1100 board with no problems at all.

Neither of the on-board ethernet ports work correctly with new kernel either. The primary port seems to work fine pinging single packets back and forth, but seems to stall for periods of approx 20 seconds when performing bulk transfers. I've been using an RTL8139 card in the PCI slot for network access.

TIA,

P.

I've got a RaQ2 with which I tinker with every so often. I recently
tried one of the 2.4.23 rc* kernels, and gave up after the network issues stung me. It's surprising you get ~20sec stalls with the onboard tulip driver. On my RaQ2, I get a virtual freeze, with very small amounts of data slowly leaking in at about I dunno, 5 bits per sec. What triggers it, I'm not sure of.

My current theory is the problem is either in the tulip driver, or the
network system that only surfaces with cobalt machines. But beyond that, I haven't managed to further isolate the problem. Other than that annoying network issue, the kernel seems to run fine for me, aside from having to strip virtually everything out to make the kernel's size just right.

--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

I've mentioned it before - the Cobalt kernel is suffering a bit from bitrot as nobody is taking care of it anymore since a while. It's a while since I did consulting work for Cobalt and I don't have production Cobalt hardware but I think I still have a reasonable understanding of the machine so I think I can help whoever dares trying - any takers?

Ralf

Hi Peter,

This has been reported several times. AFAIK 2.4.17 worked for several people, but people who actually own the hardware will now better. It would be a _huge_ help if somebody could track down the date in linux-mips.org CVS where things broke exactly.
Cheers,
-- Guido

Thanks. I'll start at 2.4.17 and work my way forwards ...

P.

Hello,

Karsten told me that things broke after 2.4.20 pre6

Bye

Oli 

Would this be the debian dpkg breakage, or the network issues I've reported?

--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

Not on a Qube2, but on a nasraq, which is essentially the same, just without the second ethernet port and the pci slot but a scsi port instead. Last kernel I tried on my Qube2 seems to be 2.4.22-rc2.

Works fine, as far as I can tell.

For me, it's 2.95.4-15 and 2.12.90.0.9-1, and I'm compiling my kernels natively.

I just tried updating, removing and installing a package without any problems.

I haven't tried my Qube2 yet, since that one's already wrapped up and ready for Karsten Merker to pick up - he's going to send it to the Tulip Expert, so those problems may go away soon, hopefully. As to kernel versions starting about 2.4.17, I've never had the tulip driver running reliably on my Qube2, but always got at least 2.4.18 and later working properly on my nasRaq (there was some patching involved at times, if I recall correctly).

Rainer

Are these patches lying around someplace by chance? I've used the patches on Paul Martin's site (which enables detection of the cobalt's "modified" tulip), as well as a patch from Karsten which fixed serial console and also enabled the tulip driver. Both of those patches don't seem to fix the tulip's issue of halting though, so either I have broken hardware, or I've done something unique in my setup that triggers the issue.

I'd like to get ahold of any patches that I haven't tried yet in an attempt to either nail the problem or isolate the cause.

btw, anyone ever gotten tulip-diag to compile on mips?

--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

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

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

That's different from what I'm seeing. My box doesn't respond at all.

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?

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.

I have a 21041, using 10-baseT on a 10 Mbit hub. What Tulip does the Cube have?

@@ -580,7 +580,15 @@
 				} else
 					dev->if_port = 0;
 			else
+			{
+printk("tulip: old driver would switch to 10base2, ");
+			if (dev->if_port != 0 || (csr12 & 0x0004) != 0) {
+printk("and we do\n");
 				dev->if_port = 1;
+			} else {
+printk("but we don't\n");
+			}
+			}
 			tulip_select_media(dev, 0);
 		}
 	} else if (tp->chip_id == DC21140 || tp->chip_id == DC21142

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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'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).

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.

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

Are there any differences in the CPUs of your nasraq and Peter's Qube2? Cheers,
-- Guido