On 21 Dec 2002, Juan Quintela wrote:
> maciej> Yep, for quite some time now, running a DECstation 5000/260 with an
> maciej> R4400SC. Yep, a few.
> Here it is bigendian (SGI Indigo 2).
The endianness shouldn't matter, but who knows?
> ARCH: SGI-IP22
> PROMLIB: ARC firmware Version 1 Revision 10
> CPU: MIPS-R4400 FPU<MIPS-R4400FPC> ICACHE DCACHE SCACHE
> CPU revision is: 00000450
> FPU revision is: 00000500
> Primary instruction cache 16kb, linesize 16 bytes.
> Primary data cache 16kb, linesize 16 bytes.
> Secondary cache sized at 1024K linesize 128 bytes.
try it and send me the boot log, specifically the bug checks. My PRId is
00000440 and that is definitely buggy revision 1.0. Yours is probably
revision 2.0 and should work better, but it won't hurt checking.
Note the patch is unfinished code; I had to modify it a bit for you to
make it work at all with standard tools. It does not necessarily make
much sense. ;-)
> I am using the egcs-1.1.2 from ralf for doing compiles, I think that
> you have a more modern compiler, if so, I will be happy to download.
Indeed, I use heavily patched gcc 2.95.4. It's available at my site,
too, as RPM packages. For mips64 there are only source and i386 binary
packages of a bootstrap cross-compiler -- look for
mips64el-linux-boot-gcc. It should be fairly easy to build big-endian
packages from the sources.
But there is a drawback -- the packages have a patch to handle the daddiu
erratum and the workaround is unconditional now. The result is somewhat
worse code is emitted.
> Corruption is that when I do a ssh to that host, I got parts of
> /proc/ksyms into the console.
SSH works just fine for me. I haven't tried connecting over IPv6 to
64-bit Linux, though (for 32-bit version it works).
> maciej> My system seems reasonably stable, but sometimes it crashes under a
> maciej> I have yet to get at tracking the problem down.
> mine in 32bits is stable, don't crash under load (not very high load
> yet). But in 64bits (with exactly the same userland) got losts of
Well, for me the 32-bit configuration is rock-solid. It's the 64-bit one
that causes some problems, but it's stable enough for most of the recent
package builds to be done with it. I debugged showstopper problems last
> Already found a couple of problems in c-r4k.c send to the list, and
I haven't seen any problems with caching recently. I might have been
lucky. But my cache configuration differs a bit:
CPU revision is: 00000440
FPU revision is: 00000500
Loading R4000 MMU routines.
Primary instruction cache 16kb, linesize 16 bytes.
Primary data cache 16kb, linesize 16 bytes.
Secondary cache sized at 1024K linesize 32 bytes.
> now a couple of problems in sgiseeq.c and sgiserial.c. Notice that I
That's driver-specific. The declance.c and zs.c drivers work.
> am running that machine with nfsroot, i.e. I don't have basically more
> devices than the serial console and the network card. No real console
> support and not harddisk support either.
Ditto here. Except a keyboard and a framebuffer also work; the latter
also under X11.
> If you have any patches, I will like to take a look.
Nothing ready for inclusion. And probably nothing critical (except for
the DECstation), but please send me the report first.
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: email@example.com, PGP key available +