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
