All of lore.kernel.org
 help / color / mirror / Atom feed
From: freshy98 <freshy98@gmx.net>
To: Kumba <kumba@gentoo.org>
Cc: Linux MIPS List <linux-mips@linux-mips.org>
Subject: Re: O2 RM7000 Issues
Date: Mon, 02 Jul 2007 00:07:58 +0200	[thread overview]
Message-ID: <468825BE.6090001@gmx.net> (raw)
In-Reply-To: <4687DCE2.8070302@gentoo.org>

Ah, finally someone else got a hold of these things :-)
Still got mine unused at all.
Not done much linux at al for the past few years, but always interested 
to see how things might work out for either R5K or RM7K O2's.

Tom


Kumba wrote:
> 
> So I finally managed to get my hands on one of those super-rare RM7000 
> CPU's for the SGI O2, and, as expected, there are some problems.
> 
> For the most part, the system will boot into userland, but it seems 
> userland isn't at all very happy.  It seems bash is the unhappiest 
> customer so far (or rather, the only userland program I've seen fail 
> repeatedly).  Running the Gentoo init scripts at startup, several 
> scripts will terminate will a variety of messages, from Trace/breakpoint 
> traps, to bus errors to illegal instructions. However, in the init 
> scripts, they happen at specific points; usually when booting our 
> network startup scripts (neth.eth0, net.lo), and usually on an exit() 
> function in the script.  Our emerge process, while python at heart, 
> seems to fail sporadically on the bash sections (parsing the ebuild 
> code) as well.
> 
> I've got a feeling this is likely a problem in the kernel more than it 
> is a problem in the userland, but the question is how to go about 
> determining which and where.  The RM7K's are pretty rare, so I imagine 
> there's probably a few undiscovered quirks in the code (notably the SC 
> code in arch/mips/mm/sc-rm7k.c).  Not to mention, we can't even use the 
> 1MB tertiary cache these things have.
> 
> For reference, system info:
> 
>  > hinv
>                    System: IP32
>                 Processor: 350 Mhz RM7000, with FPU
>      Primary I-cache size: 16 Kbytes
>      Primary D-cache size: 16 Kbytes
>      Secondary cache size: 256 Kbytes
>        Ternary cache size: 1024 Kbytes
>               Memory size: 512 Mbytes
>                  Graphics: CRM, Rev C
>                     Audio: A3 version 1
>                 SCSI Disk: scsi(0)disk(2)
>                 SCSI Disk: scsi(0)disk(3)
>                SCSI CDROM: scsi(0)cdrom(4)
> 
> 
> # cat /proc/cpuinfo
> system type             : SGI O2
> processor               : 0
> cpu model               : RM7000 V3.3  FPU V2.0
> BogoMIPS                : 350.20
> byteorder               : big endian
> wait instruction        : yes
> microsecond timers      : yes
> tlb_entries             : 48
> extra interrupt vector  : no
> hardware watchpoint     : no
> ASEs implemented        :
> VCED exceptions         : not available
> VCEI exceptions         : not available
> 
> 
> 
> 
> 
> And errors (from various points in the execution and multiple reboots):
> 
>  * Starting eth0
> /sbin/runscript.sh: line 428:  2475 Illegal instruction     ( function 
> exit ()
> 
>  * Starting lo
> /sbin/runscript.sh: line 428:  1464 Illegal instruction     ( function 
> exit ()
> 
> 
>  * Starting eth0
> /etc/init.d/net.eth0: line 248:  1650 Bus error               ( u=0; 
> module_load_minimum "${MODULES[i]}" || u=1; if [[ ${u} == 0 ]]; then
> 
> /sbin/runscript.sh: line 428:  2779 Bus error               ( function 
> exit ()
> {
> 
>  * Stopping syslog-ng 
> ...                                                 [ ok ]
> /lib/rcscripts/sh/rc-services.sh: line 444:  4093 Illegal 
> instruction     ( "/etc/init.d/${service}" stop )
> 
> /lib/rcscripts/sh/rc-services.sh: line 384:  1095 Trace/breakpoint trap 
> "/etc/init.d/${service}" start
> 
> 
> 
> So if anyone's got some old rm7k patches sitting around they want 
> tested, or spots where to look/debug options to turn on, let me know.  
> I'll try switching back to an RM5200 and rebuild bash with -g and make 
> sure gdb is installed, them change back to the RM7000 to try and capture 
> some asm call or something that's causing these exit() failures in bash 
> (which seem to be the primary symptom)
> 
> 
> Cheers,
> 
> 
> --Kumba
> 

  reply	other threads:[~2007-07-01 22:08 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-01 16:57 O2 RM7000 Issues Kumba
2007-07-01 22:07 ` freshy98 [this message]
2007-07-02 13:08   ` sknauert
2007-07-02 13:08   ` sknauert
2007-07-04 15:27     ` Ralf Baechle
2007-07-04 19:22       ` Ralf Baechle
2007-07-16 11:53         ` Sergey Rogozhkin
2007-07-16 12:33           ` Ralf Baechle
2007-07-16 17:38             ` Andrew Sharp
2007-07-17 14:01               ` Kumba
2007-07-19 18:58                 ` Andrew Sharp
2007-07-19 22:26                   ` Shane McDonald
2007-07-17  7:54             ` Gleb O. Raiko
2007-07-17  9:04         ` Sergey Rogozhkin
2007-07-17 10:14           ` Ralf Baechle
2007-07-17 12:27           ` Ralf Baechle
2007-09-17 23:04             ` Steve Graham
2007-09-18  8:52               ` Ralf Baechle
2007-09-17 23:20             ` David Daney
2007-09-18  8:47               ` Ralf Baechle
2007-07-02 14:34 ` Maciej W. Rozycki
2007-09-21  6:27 ` Sagar Borikar
2007-09-21 13:47   ` Ralf Baechle
2007-09-22  3:20     ` Steve Graham
2007-09-24 11:58       ` Ralf Baechle
2007-09-26 17:06         ` Steve Graham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=468825BE.6090001@gmx.net \
    --to=freshy98@gmx.net \
    --cc=kumba@gentoo.org \
    --cc=linux-mips@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.