linux-mips
[Top] [All Lists]

Re: 2.6 on IP22 (Indy)

To: Markus Dahms <mad@automagically.de>
Subject: Re: 2.6 on IP22 (Indy)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Mon, 27 Jun 2005 14:17:13 +0100 (BST)
Cc: linux-mips@linux-mips.org
In-reply-to: <20050627100757.GA27679@gaspode.automagically.de>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20050627100757.GA27679@gaspode.automagically.de>
Sender: linux-mips-bounce@linux-mips.org
On Mon, 27 Jun 2005, Markus Dahms wrote:

> I'm trying to run a current 2.6 kernel (LinuxMIPS CVS) on my
> Indy(s). It should be a 64-bit kernel (just for fun, but I tried
> 32-bit, too). From the mailing list archives some time ago (about
> half a year) I learned that there are known problems.
> 
> My experiments: Indy with R4600PC (133MHz) boots to userspace
> 
> | ...
> | EXT3-fs: mounted filesystem with ordered data mode.
> | atkbd.c: keyboard reset failed on hpc3ps2/serio0
> | VFS: Mounted root (ext3 filesystem) readonly.
> | Freeing unused kernel memory: 204k freed
> | INIT: version 2.86 booting
> 
> and dies then :(. The same machine, but with a R4000PC (100MHz)

 Hmm, it might be a problem with TLB handlers that have been changed to be 
built at the run time.  Perhaps the R4600 isn't handled right as a result.  
What's the CPU revision ID? -- it's printed right at the beginning.

> processor module doesn't even come so far:
> 
> | arcsboot: ARCS Linux ext2fs loader 0.3.8.6
> |
> | Loading 2.6.12-64 from scsi(0)disk(2)rdisk(0)partition(0)
> | Allocated 0x38 bytes for segments
> | Loading 64-bit executable
> | Loading program segment 1 at 0x88004000, offset=0x0 4000, size = \
> | 0x0 3c4086
> | 3c0000      (cache: 95.3%)Zeroing memory at 0x883c8086, size = \
> | 0x42f9a
> | Starting ELF64 kernel
> 
> no more action at this point....

 Strange.  The system should be capable enough for early printk() to be 
trivially implemented using firmware call-backs.  It would be more useful 
to get some feedback from it this way, otherwise it's asking for a crystal 
ball (mine is currently being serviced, if you recall)...  It's probably a 
BUG() or an Oops somewhere.  It might be related to the lack of an S-cache 
on this system -- there's been another report recently about it being a 
problem on a different machine -- try the patch sent there as a test.

  Maciej

<Prev in Thread] Current Thread [Next in Thread>