Re: Current CVS kernel no-go on R4k Decstation

Re: Current CVS kernel no-go on R4k Decstation

[Harald Koerfgen]

On 08-Jan-01 Karsten Merker wrote:
> On Mon, Jan 08, 2001 at 03:53:02PM +0100, Florian Lohoff wrote:
> 
>> Hi,
>> i am seeing this on my R4k Decstation (5000/150) 
>> 
>> This was the first try 
>> 
>> [...]
>> Freeing unused PROM memory: 124k freed
>> Freeing unused kernel memory: 60k freed
>> [init:1] Illegal instruction 0320f809 at 0fb651c4 ra=0fb651cc
>> [init:1] Illegal instruction 8f998018 at 0fb651c8 ra=0fb651cc
>> 
>> Second try doesnt give me any output at all after
>> the "Freeing unused kernel ..."
>> 
>> CVS Checkout @ 20010108 ~15:00 MESZ
>                                  ^^^^
> Is it still summer in Westfalen :-) ?
> 
> Similar effect for me (DS5000/150, Checkout @ Sat Jan 6 ~22:30 CET),
> except that I do not get the "illigal instruction" lines. Harald has the
> same problem on his /260. It looks like sometime in December 2000
> something has gone broken in the R4K-support, or are we perhaps
> triggering a compiler bug in egcs 1.1.2?

I don't think so. This hang appeared in the middle of December and may or may
not be related to the MIPS32 patches which were commited then. Unfortunately I
haven't had the time to track this down.

Anyway, is anybody else with a R4X00 machines seeing this?

-- 
Regards,
Harald

Current CVS kernel no-go on R4k Decstation

[Florian Lohoff]

Hi,
i am seeing this on my R4k Decstation (5000/150) 

This was the first try 

[...]
Freeing unused PROM memory: 124k freed
Freeing unused kernel memory: 60k freed
[init:1] Illegal instruction 0320f809 at 0fb651c4 ra=0fb651cc
[init:1] Illegal instruction 8f998018 at 0fb651c8 ra=0fb651cc

Second try doesnt give me any output at all after
the "Freeing unused kernel ..."

CVS Checkout @ 20010108 ~15:00 MESZ

This DECstation is a DS5000/1xx
Loading R4000 MMU routines.
CPU revision is: 00000430
Primary instruction cache 8kb, linesize 16 bytes.
Primary data cache 8kb, linesize 16 bytes.
Secondary cache sized at 1024K linesize 32 bytes.
Linux version 2.4.0-test11 (flo@paradigm) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #1 Mon Jan 8 15:35:19 CET 2001
Determined physical RAM map:
 memory: 04000000 @ 00000000 (usable)
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS2 root=/dev/sda2
Calibrating delay loop... 49.81 BogoMIPS
Memory: 62600k/65536k available (1269k kernel code, 2936k reserved, 69k data, 60k init)
[...]

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Current CVS kernel no-go on R4k Decstation

[Karsten Merker]

On Mon, Jan 08, 2001 at 03:53:02PM +0100, Florian Lohoff wrote:

> Hi,
> i am seeing this on my R4k Decstation (5000/150) 
> 
> This was the first try 
> 
> [...]
> Freeing unused PROM memory: 124k freed
> Freeing unused kernel memory: 60k freed
> [init:1] Illegal instruction 0320f809 at 0fb651c4 ra=0fb651cc
> [init:1] Illegal instruction 8f998018 at 0fb651c8 ra=0fb651cc
> 
> Second try doesnt give me any output at all after
> the "Freeing unused kernel ..."
> 
> CVS Checkout @ 20010108 ~15:00 MESZ
                                 ^^^^
Is it still summer in Westfalen :-) ?

Similar effect for me (DS5000/150, Checkout @ Sat Jan 6 ~22:30 CET),
except that I do not get the "illigal instruction" lines. Harald has the
same problem on his /260. It looks like sometime in December 2000
something has gone broken in the R4K-support, or are we perhaps
triggering a compiler bug in egcs 1.1.2?

Greetings,
Karsten
-- 
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung
oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder
Meinungsforschung.

Re: Current CVS kernel no-go on R4k Decstation

[Ralf Baechle]

On Tue, Oct 30, 1979 at 04:28:38AM +0100, Harald Koerfgen wrote:

> > Similar effect for me (DS5000/150, Checkout @ Sat Jan 6 ~22:30 CET),
> > except that I do not get the "illigal instruction" lines. Harald has the
> > same problem on his /260. It looks like sometime in December 2000
> > something has gone broken in the R4K-support, or are we perhaps
> > triggering a compiler bug in egcs 1.1.2?
> 
> I don't think so. This hang appeared in the middle of December and may or may
> not be related to the MIPS32 patches which were commited then. Unfortunately I
> haven't had the time to track this down.
> 
> Anyway, is anybody else with a R4X00 machines seeing this?

I can tell you that this patch provoked other alergic reactions, for example
with the R7000.

  Ralf

Re: Current CVS kernel no-go on R4k Decstation

[Kevin D. Kissell]

> > Similar effect for me (DS5000/150, Checkout @ Sat Jan 6 ~22:30 CET),
> > except that I do not get the "illigal instruction" lines. Harald has the
> > same problem on his /260. It looks like sometime in December 2000
> > something has gone broken in the R4K-support, or are we perhaps
> > triggering a compiler bug in egcs 1.1.2?
>
> I don't think so. This hang appeared in the middle of December and may or
may
> not be related to the MIPS32 patches which were commited then.
Unfortunately I
> haven't had the time to track this down.

If you're referring to the MIPS32 patches that came from the MIPS 2.2 tree,
we generally test those on an R4600 Indy and a couple R5xxx platforms as
a matter of routine.  This is not to say that there might not be some change
to the R4x00 support between 2.2 and 2.4 that interacts pathologically with
the MIPS32 code...

           Kevin K.

Re: Current CVS kernel no-go on R4k Decstation

[Kevin D. Kissell]

> > Similar effect for me (DS5000/150, Checkout @ Sat Jan 6 ~22:30 CET),
> > except that I do not get the "illigal instruction" lines. Harald has the
> > same problem on his /260. It looks like sometime in December 2000
> > something has gone broken in the R4K-support, or are we perhaps
> > triggering a compiler bug in egcs 1.1.2?
>
> I don't think so. This hang appeared in the middle of December and may or
may
> not be related to the MIPS32 patches which were commited then.
Unfortunately I
> haven't had the time to track this down.

If you're referring to the MIPS32 patches that came from the MIPS 2.2 tree,
we generally test those on an R4600 Indy and a couple R5xxx platforms as
a matter of routine.  This is not to say that there might not be some change
to the R4x00 support between 2.2 and 2.4 that interacts pathologically with
the MIPS32 code...

           Kevin K.