linux 2.4 and Indy
Hi,
I'm having big trouble getting linux 2.4.* to work on my SGI Indy. I want to use my indycam, and thus compile a kernel with support for that. The problem is that all the kernels I built do boot, but freeze some moments after starting the init process. The only kernels that do not have this problem are 2.4.16 and 2.4.17, but they do not have proper VINO support (they lack the i2c algo-sgi part).
Is there some patch flying around to fix this, or do I just have bad luck?
/proc/cpuinfo:
system type : SGI Indy
processor : 0
cpu model : R4600 V1.0 FPU V0.0
BogoMIPS : 99.73
byteorder : big endian
wait instruction : yes
microsecond timers : yes
extra interrupt vector : no
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
cheers,
Signature · 2 lines
Jorik Jonker http://boeventronie.net/
Quoted 8 lines · Jorik Jonker
Hi,
I'm having big trouble getting linux 2.4.* to work on my SGI Indy. I want to
use my indycam, and thus compile a kernel with support for that. The problem
is that all the kernels I built do boot, but freeze some moments after
starting the init process. The only kernels that do not have this problem are 2.4.16 and 2.4.17, but they do not have proper VINO support (they lack the i2c algo-sgi part).
Is there some patch flying around to fix this, or do I just have bad luck?
Check out a cvs tree no later than 12/11/2003, a change in CVS after that date seems to have nuked r4k kernels. It is believed the change in question is:
http://www.linux-mips.org/archives/linux-cvs/2003-12/msg00031.html
I've not yet been able to find a 'clean' way to remove the changes to those specific files in that commit while keeping all the changes made afterwards intact to test this idea.
--Kumba
Signature · 1 line
"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
Quoted 10 lines · Kumba
Quoted 6 lines
The problem
is that all the kernels I built do boot, but freeze some moments after starting the init process. The only kernels that do not have this problem are 2.4.16 and 2.4.17, but they do not have proper VINO support (they lack the i2c algo-sgi part).
Is there some patch flying around to fix this, or do I just have bad luck?Check out a cvs tree no later than 12/11/2003, a change in CVS after that date seems to have nuked r4k kernels. It is believed the change in question is:
Hmm, that's strange, I believe that should do the trick, but when I checkout a tree (cvs -z3 -d:.. co -r linux_2_4 -D 'December 10 2003' linux), I still get a 'half-booting' kernel. Shall I try to checkout an even older one, until something is starting to work, or is something else going wrong?
cheers,
Signature · 2 lines
Jorik Jonker http://boeventronie.net/
On Fri, Jan 30, 2004 at 11:59:03AM +0100, Jorik Jonker wrote:
[...]
Quoted 4 lines
Hmm, that's strange, I believe that should do the trick, but when I checkout a tree (cvs -z3 -d:.. co -r
linux_2_4-D 'December 10 2003' linux), I still get a 'half-booting' kernel. Shall I try to checkout an even older one, until something is starting to work, or is something else going wrong?
I have a working 5th December 2003 kernel running on R4600 V2.0, but since there were no changes between 5th and 11th December, I'd suspect that yours should boot fine, too. Did you check if the files you checked out are really not later than 11th December?
Signature · 3 lines
Dominik 'Rathann' Mierzejewski <[email protected]> Interdisciplinary Centre for Mathematical and Computational Modelling Warsaw University | http://www.icm.edu.pl | tel. +48 (22) 5540810
On Fri, Jan 30, 2004 at 12:12:56PM +0100, Dominik 'Rathann' Mierzejewski wrote:
[...]
Quoted 9 lines
Quoted 4 lines
Hmm, that's strange, I believe that should do the trick, but when I checkout a tree (cvs -z3 -d:.. co -r
linux_2_4-D 'December 10 2003' linux), I still get a 'half-booting' kernel. Shall I try to checkout an even older one, until something is starting to work, or is something else going wrong?I have a working 5th December 2003 kernel running on R4600 V2.0, but since there were no changes between 5th and 11th December, I'd suspect that yours should boot fine, too. Did you check if the files you checked out are really not later than 11th December?
I am really sure. The exact command used to checkout my tree was:
# cvs -z3 -d :pserver:[email protected]:/home/cvs co \ -D '5 Dec 2003' \ -r linux_2_4 linux
I am not extremely confident about my CVS skills, but the fine manual tought me this. I even checked out kernels from June 4th 2003, without success. I am now trying February 4th 2003.
cheers,
Signature · 2 lines
Jorik Jonker http://boeventronie.net/
Quoted 7 lines · Jorik Jonker
# cvs -z3 -d :pserver:[email protected]:/home/cvs co \ -D '5 Dec 2003' \ -r linux_2_4 linuxI am not extremely confident about my CVS skills, but the fine manual tought me this. I even checked out kernels from June 4th 2003, without success. I am now trying February 4th 2003.
Without success again.. I am beginning to suspect that I am doing something completely wrong. I must say I am building using a crosscompiler:
mips-linux-gcc (GCC) 3.2.3 20030221 (Debian prerelease), but.. I successfully produced a working 2.4.16 and 2.4.17. I am now going to do a native '5 december' build, hoping that will solve the problems.
Signature · 2 lines
Jorik Jonker http://boeventronie.net/
Quoted 9 lines · Kumba
Check out a cvs tree no later than 12/11/2003, a change in CVS after that date seems to have nuked r4k kernels. It is believed the change in question is:
http://www.linux-mips.org/archives/linux-cvs/2003-12/msg00031.html
I've not yet been able to find a 'clean' way to remove the changes to those specific files in that commit while keeping all the changes made afterwards intact to test this idea.
Over the past days a few fixes went into CVS, the last only a few minutes ago. Can you retry and let me know?
Ralf
Quoted 2 lines · Ralf Baechle
Over the past days a few fixes went into CVS, the last only a few minutes ago. Can you retry and let me know?
Well, it a little 'better'. It now hangs while configurating the network device, while in earlier versions the freeze appeared while calibrating the delay loop, or mounting the root fs.
Is there something else I could try?
Until I know what's going on, I am going to look for a kernel with proper VINO support which is 'old' enough to run without the freeze..
cheers,
Signature · 2 lines
Jorik Jonker http://boeventronie.net/
R4600 V1.7 errata
Quoted 11 lines · Jorik Jonker
Quoted 2 lines · Ralf Baechle
Over the past days a few fixes went into CVS, the last only a few minutes ago. Can you retry and let me know?
Well, it a little 'better'. It now hangs while configurating the network device, while in earlier versions the freeze appeared while calibrating the delay loop, or mounting the root fs.
Is there something else I could try?
Until I know what's going on, I am going to look for a kernel with proper VINO support which is 'old' enough to run without the freeze..
Seems I lost the R4600 V1.7 errata documents I used to have so all information that is left to me is what's documented in the Linux code. I've removed all the mentioned instructions and the kernel which otherwise is running fine on R5000 systems or R4600 V2.0 keeps crashing. I suspect I'm becoming victim of some of the other of the chip's errata; it has at least 18 ...
Anybody still got errata information for the R4600 V1.7 around?
Ralf
Re: R4600 V1.7 errata
Quoted 7 lines · Ralf Baechle
Quoted 6 lines
Well, it a little 'better'. It now hangs while configurating the network device, while in earlier versions the freeze appeared while calibrating the delay loop, or mounting the root fs.
Is there something else I could try?
Until I know what's going on, I am going to look for a kernel with proper VINO support which is 'old' enough to run without the freeze..
Quoted 8 lines
Seems I lost the R4600 V1.7 errata documents I used to have so all information that is left to me is what's documented in the Linux code. I've removed all the mentioned instructions and the kernel which otherwise is running fine on R5000 systems or R4600 V2.0 keeps crashing. I suspect I'm becoming victim of some of the other of the chip's errata; it has at least 18 ...
Anybody still got errata information for the R4600 V1.7 around?
Jorik was so friendly to track down the patch in CVS that broke the R4600 V1.7 back in time. With that as a start it was fairly easy to isolate the problem further. Seems we became victim of some erratum that affects the operation of indexed I-cache flushes only. Last night I commited a patch that provides an optimized solution for the problem.
Still, knowing the errata sheet of this processor has at least 18 items on it I'd not place bets on it being totally reliable. Therefore I'm still interested, just in case somebody happens to run over a dusty errata sheet somewhere :-)
Ralf
Re: R4600 V1.7 errata
On Tue, Feb 03, 2004 at 12:39:28PM +0100, Ralf Baechle wrote:
[...]
Quoted 5 lines
Jorik was so friendly to track down the patch in CVS that broke the R4600 V1.7 back in time. With that as a start it was fairly easy to isolate the problem further. Seems we became victim of some erratum that affects the operation of indexed I-cache flushes only. Last night I commited a patch that provides an optimized solution for the problem.
I assume it's safe to test it now? I'll build it for my R4600 V2.0 and report in a while. Stay tuned.
Signature · 3 lines
Dominik 'Rathann' Mierzejewski <[email protected]> Interdisciplinary Centre for Mathematical and Computational Modelling Warsaw University | http://www.icm.edu.pl | tel. +48 (22) 5540810
Re: R4600 V1.7 errata
Quoted 10 lines · Dominik 'Rathann' Mierzejewski
On Tue, Feb 03, 2004 at 12:39:28PM +0100, Ralf Baechle wrote:
[...]Quoted 5 lines
Jorik was so friendly to track down the patch in CVS that broke the R4600 V1.7 back in time. With that as a start it was fairly easy to isolate the problem further. Seems we became victim of some erratum that affects the operation of indexed I-cache flushes only. Last night I commited a patch that provides an optimized solution for the problem.
I assume it's safe to test it now? I'll build it for my R4600 V2.0 and report in a while. Stay tuned.
2.0 requires different workarounds which are already in place and functional since quite some time. We still lacking a fix for one important erratum of the 2.0 but it seems pretty stable without.
Chip revs later than 2.0 do identify as 2.0 so if you're lucky your processor is actually a post-2.0 and working just fine ...
Ralf
Re: R4600 V1.7 errata
Quoted 3 lines · Ralf Baechle
2.0 requires different workarounds which are already in place and functional since quite some time. We still lacking a fix for one important erratum of the 2.0 but it seems pretty stable without.
Well, I can actually see two problems: #4 that is fairly easy to handle
and #7 which is painful and which is unfortunately present with the R4700 as well.
Signature · 3 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
Re: R4600 V1.7 errata
Quoted 7 lines · Maciej W. Rozycki
Quoted 3 lines
2.0 requires different workarounds which are already in place and functional since quite some time. We still lacking a fix for one important erratum of the 2.0 but it seems pretty stable without.
Well, I can actually see two problems: #4 that is fairly easy to handle
and #7 which is painful and which is unfortunately present with the R4700 as well.
If #7 would only affect the R4700 the world would peachy ... To my knowledge the dusty box here in a corner is the only R4700 that ever ran Linux ...
Under a different bug number this bug also affects the R4600 V1.x; it's fixed in post-2.0 R4600 (which all identify as 2.0) and post-1.1 R4700. Since a workaround may be a bit performance sensitive I think I'll try if it can be probed for reliably.
Ralf
Re: R4600 V1.7 errata
Quoted 4 lines · Ralf Baechle
Under a different bug number this bug also affects the R4600 V1.x; it's fixed in post-2.0 R4600 (which all identify as 2.0) and post-1.1 R4700. Since a workaround may be a bit performance sensitive I think I'll try if it can be probed for reliably.
The conditions appear clear, so they may be quite easy to reproduce for
the erratum to trigger. I guess you may take the optimization hint from the document into account as well.
Signature · 3 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
Re: R4600 V1.7 errata
In reply to Dominik 'Rathann' MierzejewskiOn Tue, Feb 03, 2004 at 12:42:53PM +0100, Dominik 'Rathann' Mierzejewski wrote:
[...]
Quoted 2 lines
I assume it's safe to test it now? I'll build it for my R4600 V2.0 and report in a while. Stay tuned.
Works now. Thanks, guys.
Signature · 3 lines
Dominik 'Rathann' Mierzejewski <[email protected]> Interdisciplinary Centre for Mathematical and Computational Modelling Warsaw University | http://www.icm.edu.pl | tel. +48 (22) 5540810
Re: R4600 V1.7 errata
Quoted 6 lines · Dominik 'Rathann' Mierzejewski
On Tue, Feb 03, 2004 at 12:42:53PM +0100, Dominik 'Rathann' Mierzejewski wrote:
[...]Quoted 2 lines
I assume it's safe to test it now? I'll build it for my R4600 V2.0 and report in a while. Stay tuned.
Works now. Thanks, guys.
The latest cache updates break the Au1x kernel. I don't know yet exactly what the problem is, but I tested with a snapshot before and after the updates.
Pete
Re: R4600 V1.7 errata
Quoted 9 lines · Pete Popov
Quoted 5 lines
[...]
Quoted 2 lines
I assume it's safe to test it now? I'll build it for my R4600 V2.0 and report in a while. Stay tuned.
Works now. Thanks, guys.
The latest cache updates break the Au1x kernel. I don't know yet exactly what the problem is, but I tested with a snapshot before and after the updates.
The cache updates should specifically only affects systems that explicitly enable the cache workaround in <asm/war.h>; for any other the compiler should totally eleminate the workaround from the binary.
Therefore my first guess would be pg-r4k.c.
Ralf