Kernel 2.4.23 on Cobalt Qube2

Kernel 2.4.23 on Cobalt Qube2

[Peter Horton]

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.

Re: Kernel 2.4.23 on Cobalt Qube2

[Kumba]

Peter Horton wrote:

> 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

Re: Kernel 2.4.23 on Cobalt Qube2

[Ralf Baechle]

On Tue, Dec 09, 2003 at 04:54:25PM +0000, Peter Horton wrote:

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

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

Re: Kernel 2.4.23 on Cobalt Qube2

[Guido Guenther]

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

Hi Peter,
On Tue, Dec 09, 2003 at 04:54:25PM +0000, Peter Horton wrote:
> 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 :-(
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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Kernel 2.4.23 on Cobalt Qube2

[Peter Horton]

Guido Guenther wrote:

>Hi Peter,
>On Tue, Dec 09, 2003 at 04:54:25PM +0000, Peter Horton wrote:
>  
>
>>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 :-(
>>    
>>
>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.

Re: Kernel 2.4.23 on Cobalt Qube2

[Oliver Schwank]

Hello,

> would be a _huge_ help if somebody could track down the date in
> linux-mips.org CVS where things broke exactly.

Karsten told me that things broke after 2.4.20 pre6 

Bye 

-- 
Oli 

Re: Kernel 2.4.23 on Cobalt Qube2

[Kumba]

Oliver Schwank wrote:

> Karsten told me that things broke after 2.4.20 pre6 

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

Re: Kernel 2.4.23 on Cobalt Qube2

[Rainer Canavan]

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

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.
 
> 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).
 
For me, it's 2.95.4-15 and 2.12.90.0.9-1, and I'm compiling my kernels
natively.

> 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 just tried updating, removing and installing a package without 
any problems.
 
> 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.

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

Re: Kernel 2.4.23 on Cobalt Qube2

[Kumba]

Rainer Canavan wrote:

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

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

Re: Kernel 2.4.23 on Cobalt Qube2

[Geert Uytterhoeven]

On Tue, 9 Dec 2003, Kumba wrote:
> Rainer Canavan wrote:
> > 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).
> 
> 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.

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 -- geert@linux-m68k.org

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

Re: Kernel 2.4.23 on Cobalt Qube2

[Kumba]

Geert Uytterhoeven wrote:

> 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

Re: Kernel 2.4.23 on Cobalt Qube2

[Geert Uytterhoeven]

On Wed, 10 Dec 2003, Kumba wrote:
> Geert Uytterhoeven wrote:
> > 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.
> 
> 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.

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

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

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?

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

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?

--- linux-2.4.23/drivers/net/tulip/tulip_core.c.orig	Fri Nov 28 21:04:35 2003
+++ linux-2.4.23/drivers/net/tulip/tulip_core.c	Sun Nov 30 11:37:45 2003
@@ -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 -- geert@linux-m68k.org

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

Re: Kernel 2.4.23 on Cobalt Qube2

[Kumba]

Geert Uytterhoeven wrote:

> 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

Re: Kernel 2.4.23 on Cobalt Qube2

[Guido Guenther]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On Tue, Dec 09, 2003 at 11:03:51PM +0100, Rainer Canavan wrote:
> > 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 just tried updating, removing and installing a package without 
> any problems.
Are there any differences in the CPUs of your nasraq and Peter's Qube2?
Cheers,
 -- Guido

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]