Re: 2.6.11.10 failure on Hypersparc sparc32 [was: Re: sparc32 2.6

[Bob Breuer <breuerr@mc.net>]

William Lee Irwin III wrote:
> On Sat, Jun 04, 2005 at 12:21:22AM -0400, Jurij Smakov wrote:
> 
>>I have tried to dig a little bit more on this issue, with some success. 
>>It appears that initrd does not mount because something is wrong with the
>>__copy_1page function, invoked by memcpy() for copying page-sized chunks.
>>It is used in fs/cramfs/inode.c to read in the superblock of the cramfs 
>>filesystem and, surprisingly, in this process first 16 bytes (containing 
>>the magic cramfs number, among other things), get lost somehow. After I've 
>>replaced a call to __copy_1page with a call to __memcpy in 
>>include/asm-sparc/string.h, initrd mounted, however boot still fails. The 
>>next problem is that /linuxrc script from initrd is not executed as it 
>>should. This script is supposed to save real-root-device from /proc and 
>>set the real-root-device to ramdisk, where initrd is located (it all 
>>happens in do_mounts_initrd.c). However, the execve call to /linuxrc 
>>quietly fails, and the script is never executed. After that kernel tries 
>>to immediately mount /dev/sda1 (which is the real root) and fails, because 
>>the scsi modules have not been loaded. So it now looks like this:
> 
> [...]
> 
> This is a tremendous amount of progress. I'll look at __copy_1page,
> though others should do likewise as well.
> 

Look for hypersparc_copy_1page in arch/sparc/mm/hypersparc.S where it 
uses ASI_M_BCOPY.  I think the src and dest need to be 32 byte aligned 
in this case.

The core problem here is that cramfs uses statically allocated page 
sized buffers:
   nm -S arch/sparc/boot/image |grep read_buffers
   f022bab0 00008000 b read_buffers

Looks like cramfs also has the possibility of using a bad alignment with 
bzero_1page.

As for execve failing, can you print out the value of errno when it fails?

Bob