Uploads ...

Uploads ...

[Ralf Baechle]

Just as announced I've started uploading all the toys I've been working
on to Linus.  Right now all the RPMs (about 134mb) and all the source RPMs
are online.  I had to modify a couple of the source RPMs.  The most
common bug was trying to link with libbsd.a from Linux-libc which of
course is missing on our glibc-only system.

I've also uploaded a linux 2.1.67 kernel binary to Linus.

Still missing:

 - sh-utils (bug in the Redhat sources)
 - binutils (gcc dies during compile)
 - X
 - libc

I'll pump at least the last two items up tomorrow; the other items will
need some work.

Ok, and with this upload ``Mustang'' is history for me.  Let's go for
Redhat 5.0 ...

  Ralf

Re: Uploads ...

[Alan Cox]

>  - binutils (gcc dies during compile)

Build without gcc -O and it builds

Alan

Re: Uploads ...

[Alan Cox]

>  - binutils (gcc dies during compile)

Build without gcc -O and it builds

Alan

Re: Uploads ...

[Ralf Baechle]

On Mon, Dec 08, 1997 at 02:58:36PM +0000, Alan Cox wrote:
> >  - binutils (gcc dies during compile)
> 
> Build without gcc -O and it builds

Removing the 64bit targets from the binutils' configuration is probably
preferable as it will make the binutils quite a bit faster.  Nevertheless
I want this bug to be fixed - GCC 2.8 or not.

  Ralf

Re: Uploads ...

[Alex deVries]

On Mon, 8 Dec 1997, Ralf Baechle wrote:
> Just as announced I've started uploading all the toys I've been working
> on to Linus.  Right now all the RPMs (about 134mb) and all the source RPMs

Yay!

> are online.  I had to modify a couple of the source RPMs.  The most
> common bug was trying to link with libbsd.a from Linux-libc which of
> course is missing on our glibc-only system.

What is the replacement for libbsd.a, for future reference?

> I've also uploaded a linux 2.1.67 kernel binary to Linus.

I will try it tomorrow. 

I installed a load of RPM's, and had to install with a --nodeps since I
don't have the glibc RPM. As well, loads of stuff crashed.  I know this is
because of me missing a modern version of libc, so I'm really looking for
the libc release.

- Alex

Re: Uploads ...

[ralf]

On Tue, Dec 09, 1997 at 01:03:18AM -0500, Alex deVries wrote:

> > are online.  I had to modify a couple of the source RPMs.  The most
> > common bug was trying to link with libbsd.a from Linux-libc which of
> > course is missing on our glibc-only system.
> 
> What is the replacement for libbsd.a, for future reference?

You don't need to link with a special library, just #define _BSD_SOURCE,
for example with the option -D_BSD_SOURCE.

  Ralf

Re: Uploads ...

[Michael Hill]

Hi Ralf,

Thanks for the kernel binary.  Unfortunately it quits in the same spot as the
previous kernel I tried (the R4600 V2.0 problem).  You said you had a stable
kernel on the SNI RM200.  This time I used the Indy kernel; should I try the
rm200 kernel?  If I were to get my Indy back on support would they replace the
CPU because of this?

Regards,

Mike

-- 
Michael Hill
Toronto, Canada
mdhill@interlog.com

Re: Uploads ...

[ralf]

On Tue, Dec 09, 1997 at 07:34:21PM -0500, Michael Hill wrote:

> Thanks for the kernel binary.  Unfortunately it quits in the same spot as the
> previous kernel I tried (the R4600 V2.0 problem).  You said you had a stable
> kernel on the SNI RM200.  This time I used the Indy kernel; should I try the
> rm200 kernel?

If your have a RM200 ...

Is it still that bus error message you get?  If so, could you please mail
me the register dump displayed on the screen.

>  If I were to get my Indy back on support would they replace the
> CPU because of this?

No, because that problem can be handled in the OS software and > 2.1.57 do
so.

  Ralf

Re: Uploads ...

[Benjamin Pannier]

ralf@uni-koblenz.de wrote:
> 
> On Tue, Dec 09, 1997 at 07:34:21PM -0500, Michael Hill wrote:
> 
> > Thanks for the kernel binary.  Unfortunately it quits in the same spot as the
> > previous kernel I tried (the R4600 V2.0 problem).  You said you had a stable
> > kernel on the SNI RM200.  This time I used the Indy kernel; should I try the
> > rm200 kernel?
> 
> If your have a RM200 ...
> 
> Is it still that bus error message you get?  If so, could you please mail
> me the register dump displayed on the screen.

vmlinux-indy-2.1.67:

ARCH: SGI-IP22 
CPU: MIPS-4600 FPU<MIPS-R4600FPC> ICACHE DCACHE
Loading R4000 MMU routines
CPU revision is: 00002020
...
Stating kswapd v1.23
SGI Zilog8530 serialdriver V1.00
tty00 at 0xbfbd9838 (irq = 21) is Zilog8530
tty01 at 0xbfbd9830 (irq = 21) is Zilog8530
loop: registered device at major 7
Got a bus error IRQ, shouldn't ...
$0 : 00000000 1000fc01 88130000 00000000
$4 : 88174274 8812cb10 8fff1cd8 00000001
$8 : 1000fc03 00000201 0000ffe5 8813de68
$12: 00000001 00000001 00000001 fffffffc
$16: 0000c000 8ffe5000 00000000 00000000
$20: a8747330 9fc47a40 00000000 9fc47a40
$24: 1000fc01 0000000f
$2:  00000000 8fff1cb8 9fc47bac 8800b0e8
epc: 880359f8
status: 1000fc03
cause: 00004000
Spinning...

-karo

-- 
  __/__/__/\ Benjamin Pannier,ART+COM GmbH,BudapesterStr44,D-10787Berlin
 __/__/__/\/ Tel:(+49-30)25417-3 Fax:(+49-30)25417-555
__/__/__/\/ Email:karo@artcom.net WWW:http://www.artcom.net/~karo/ 
__\__\__\/ Email:karo@artcom.org me@karo.org i.am@ka.ro karo@artcom.de

Re: Uploads ...

[ralf]

On Thu, Dec 11, 1997 at 11:03:50PM +0100, Benjamin Pannier wrote:

> tty01 at 0xbfbd9830 (irq = 21) is Zilog8530
> loop: registered device at major 7
> Got a bus error IRQ, shouldn't ...

Bad, the two register dumps you and Mike mailed don't make very much
sense; the epc register is pointer to completly different routines.
What both reports have in common is that the kernel dies after the
initialisation of the loop device.  The loop driver is actually
``harmless'' as it has no SGI specific code.  The next driver to
be initialized would be the SCSI driver, so the problem is there.
This and the useless epc values might indicate a problem with the
hpc dma.

I wonder if the DMA engine in the HPC might still be active?

I'm going to try to solve the problem by starring at the source.  If
this doesn't help, could you guys please run a special debug kernel
that I'll make for you?

  Ralf

Indy crash during bootup

[ralf]

On Thu, Dec 11, 1997 at 06:12:24AM -0500, Michael Hill wrote:

> Got a bus error IRQ, shouldn't happen yet
> $0 : 00000000 00000000 0007c000 8007d000
> $4 : 00000080 89f7d000 1000fc01 8007cfe0
> $8 : 80000000 00000000 00009f7c 8813de68
> $12: 00000001 00000001 00000001 fffffffc
> $16: 09f7c000 89f7c000 00000000 00000000
> $20: a87ffc20 a8746d60 9fc556d4 00000000
> $24: 1000fc01 0000000f
> $28: eb3b6f7f 89f81d90 00000001 880f2890
> epc   : 88026918
> Status: 1000fc03
> Cause : 00004000
> Spinning...

Ok, I did some further analysis.  Dissassembling shows that Benjamin's
report doesn't really contain useful data.  His machine took the
bus error interrupt while processing some other exception.  Michael's
machine took the bus error at the end of r4k_flush_page_to_ram_d32i32_r4600()
which is being called during sgiwd33.c:sgiwd93_detect().c.

Since the R4600 v2.0 is running rocksolid - my RM200 is up for over two
weeks - the problem seems to be in the SGI specific code in the function
that handles the Indy style l2 caches.

Hmm...  I just noticed in Benjamin's startup messages that his machine
doesn't print a message (``Enabling R4600 SCACHE'') about activating the
second level cache.  I bet both your and Benjamin's machines don't have
second level caches.  Could you check the hinv output, please?

William: would an attempt to manipulate the R4600 second level cache on
a Indy without such a cache result in a bus error interrupt?

  Ralf

Re: Indy crash during bootup

[William J. Earl]

ralf@uni-koblenz.de writes:
...
 > William: would an attempt to manipulate the R4600 second level cache on
 > a Indy without such a cache result in a bus error interrupt?
...
     Yes.  The memory address of the cache controller will not exist.  Avoid
referencing it when the cache is not configured.  If the kernel is not
reading the cache configuration from the CPU module EEPROM, then it should
test for the existence of the cache controller by referencing it within
some sort of exception trap which returns control gracefully with an error
indication if a bus error occurs.  Note that you might get a bus error exception
(on a read) rather than a bus error interrupt (on a write).

Re: Indy crash during bootup

[ralf]

On Thu, Dec 11, 1997 at 07:15:22PM -0800, William J. Earl wrote:

> ralf@uni-koblenz.de writes:
> ...
>  > William: would an attempt to manipulate the R4600 second level cache on
>  > a Indy without such a cache result in a bus error interrupt?
> ...
>      Yes.  The memory address of the cache controller will not exist.  Avoid
> referencing it when the cache is not configured.  If the kernel is not
> reading the cache configuration from the CPU module EEPROM, then it should
> test for the existence of the cache controller by referencing it within
> some sort of exception trap which returns control gracefully with an error
> indication if a bus error occurs.  Note that you might get a bus error exception
> (on a read) rather than a bus error interrupt (on a write).

Ok, this prooves that my theories have been correct.  In fact the Indy
code tries to be intelligent about recognicing a second level cache but
fails to get things right when flushing the cache.  Assume this bug to
be fixed for the next release.

There seems to be something else wrong with the cache handling.  My R5000
Indy has a second level cache according to hinv but it doesn't show up
in the results of lmbench running under Linux.

>click click<

Indeed, we only activate the second level cache for R4600 machines.  I
guess the next kernel release will be *faster* :-)

  Ralf

Re: Indy crash during bootup

[Benjamin Pannier]

ralf@uni-koblenz.de wrote:
 
> Hmm...  I just noticed in Benjamin's startup messages that his machine
> doesn't print a message (``Enabling R4600 SCACHE'') about activating the
> second level cache.  I bet both your and Benjamin's machines don't have
> second level caches.  Could you check the hinv output, please?

yes, that's right. That machine do not have a second level chache:

Iris Audio Processor: version A2 revision 4.1.0
1 133 MHZ IP22 Processor
FPU: MIPS R4600 Floating Point Coprocessor Revision: 2.0
CPU: MIPS R4600 Processor Chip Revision: 2.0
On-board serial ports: 2
On-board bi-directional parallel port
Data cache size: 16 Kbytes
Instruction cache size: 16 Kbytes
Main memory size: 128 Mbytes
Vino video: unit 0, revision 0, IndyCam connected
Integral ISDN: Basic Rate Interface unit 0, revision 1.0
Integral Ethernet: ec0, version 1
Integral SCSI controller 0: Version WD33C93B, revision D
  Disk drive: unit 1 on SCSI controller 0
Graphics board: Indy 24-bit

-ben


-- 
  __/__/__/\ Benjamin Pannier,ART+COM GmbH,BudapesterStr44,D-10787Berlin
 __/__/__/\/ Tel:(+49-30)25417-3 Fax:(+49-30)25417-555
__/__/__/\/ Email:karo@artcom.net WWW:http://www.artcom.net/~karo/ 
__\__\__\/ Email:karo@artcom.org me@karo.org i.am@ka.ro karo@artcom.de