Need advice: unable to mount filesystem

Need advice: unable to mount filesystem

[Amit Virdi]

Hi,

I have ported the code for my MMUless SoC from Kernel 3.3 to 3.8-rc6. 
I've compiled a flat cramfs format FS. This used to work with the SoC 
code over Kernel 3.3.

I copied this FS in the flash. I have done various checks such as the 
mtd partitions this kernel is creating are in accordance with the layout 
of the flash, command line arguments are correct, all the relevant 
configuration options are enabled during kernel configuration etc.

I have tried mounting the filesystem from DDR, that too with no success. 
One observation is that before mounting the FS, the kernel throws a warning:
--
Warning: unable to open an initial console.
--

I have even tried using initramfs (compiled kernel with busybox binary).

All of these used to run with Kernel 3.3. Same filesystem (copied in the 
flash is working with the older kernel).

I guess I'm missing something trivial here but not able to figure out.

I have enabled the following flags in the defconfig (pasting only relevant):
CONFIG_BINFMT_FLAT
CONFIG_BLK_DEV_INITRD
CONFIG_MTD_BLOCK
CONFIG_CRAMFS
CONFIG_AEABI

Can anyone suggest what I might be missing? Any help would be 
appreciated. Logfile is attached...

Thanks
Amit Virdi
-------------- next part --------------
CPU:   xxxx
DRAM:  128 MiB
Flash: 16 MiB
u-boot> bootm 0x23000000
## Booting kernel from Legacy Image at 23000000 ...
   Image Name:   Linux-3.8.0-rc6-00086-gb334582-d
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1168056 Bytes = 1.1 MiB
   Load Address: 20008000
   Entry Point:  20008000
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.8.0-rc6-00086-gb334582-dirty (amitvi at DLH10016) (gcc version 4.6.2 20110813 (STMicroelectronics/Linux Base 4.6.2-99) (GCC) ) #37 Wed Feb 13 11:39:33 IST 2013
CPU: ARMv7 Processor [411fc143] revision 3 (ARMv7), cr=08c51c7d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine: ST-xxxx-EVB
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: console=ttyAMA0,115200 root=/dev/mtdblock3 rootfstype=cramfs
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 127528k/127528k available, 3544k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0x00000000 - 0x00001000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0x00000000 - 0xffffffff   (4095 MB)
    lowmem  : 0x20000000 - 0x28000000   ( 128 MB)
      .text : 0x20008000 - 0x201f70dc   (1981 kB)
      .init : 0x201f8000 - 0x2020c48c   (  82 kB)
      .data : 0x2020e000 - 0x20229be0   ( 111 kB)
       .bss : 0x20229be0 - 0x2025ad74   ( 197 kB)
SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:104
VIC @8e000000: id 0x00041192, vendor 0x41
VIC @8e001000: id 0x00041192, vendor 0x41
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop... 275.25 BogoMIPS (lpj=1376256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Serial: AMBA PL011 UART driver
uart: ttyAMA0 at MMIO 0x85000000 (irq = 17) is a PL011 rev3
console [ttyAMA0] enabled
bio: create slab <bio-0> at 0
SCSI subsystem initialized
Switching to clocksource tmr1
jffs2: version 2.2. (NAND) ? 2001-2006 Red Hat, Inc.
msgmni has been set to 249
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
brd: module loaded
st: Version 20101219, fixed bufsize 32768, s/g segs 256
osst :I: Tape driver with OnStream support version 0.99.4
osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $
SCSI Media Changer driver v0.25 
sfc-nor sfc-nor: found device: w25q128, size = 1000000 (16MiB) erasesize = 0x00010000 (64KiB)
Creating 4 MTD partitions on "NOR":
0x000000000000-0x000000010000 : "X-loader"
0x000000010000-0x000000040000 : "U-Boot"
0x000000040000-0x000000240000 : "Kernel"
0x000000240000-0x000001000000 : "Root File System"
Warning: unable to open an initial console.
VFS: Cannot open root device "mtdblock3" or unknown-block(31,3): error -14
Please append a correct "root=" boot option; here are the available partitions:
1f00              64 mtdblock0  (driver?)
1f01             192 mtdblock1  (driver?)
1f02            2048 mtdblock2  (driver?)
1f03           14080 mtdblock3  (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3)
[<2000cb50>] (unwind_backtrace+0x0/0xf8) from [<2018655c>] (panic+0x8c/0x1d8)
[<2018655c>] (panic+0x8c/0x1d8) from [<201f8d58>] (mount_block_root+0x1fc/0x2b8)
[<201f8d58>] (mount_block_root+0x1fc/0x2b8) from [<201f90c0>] (prepare_namespace+0x160/0x1b8)
[<201f90c0>] (prepare_namespace+0x160/0x1b8) from [<20185984>] (kernel_init+0x8/0xe4)
[<20185984>] (kernel_init+0x8/0xe4) from [<20008e98>] (ret_from_fork+0x14/0x3c)

Need advice: unable to mount filesystem

[Linus Walleij]

On Wed, Feb 13, 2013 at 1:29 PM, Amit Virdi <amit.virdi@st.com> wrote:

> I have tried mounting the filesystem from DDR, that too with no success. One
> observation is that before mounting the FS, the kernel throws a warning:
> --
> Warning: unable to open an initial console.

This is not your problem. The kernel screams that all the time, (I once
saw that explained and some ugly workaround for).

This (from your log) is the real problem:

VFS: Cannot open root device "mtdblock3" or unknown-block(31,3): error -14
Please append a correct "root=" boot option; here are the available partitions:
1f00              64 mtdblock0  (driver?)
1f01             192 mtdblock1  (driver?)
1f02            2048 mtdblock2  (driver?)
1f03           14080 mtdblock3  (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3)
[<2000cb50>] (unwind_backtrace+0x0/0xf8) from [<2018655c>] (panic+0x8c/0x1d8)
[<2018655c>] (panic+0x8c/0x1d8) from [<201f8d58>] (mount_block_root+0x1fc/0x2b8)
[<201f8d58>] (mount_block_root+0x1fc/0x2b8) from [<201f90c0>]
(prepare_namespace+0x160/0x1b8)
[<201f90c0>] (prepare_namespace+0x160/0x1b8) from [<20185984>]
(kernel_init+0x8/0xe4)
[<20185984>] (kernel_init+0x8/0xe4) from [<20008e98>] (ret_from_fork+0x14/0x3c)

The kernel cannot find a working filesystem at mtdblock3.

> I have even tried using initramfs (compiled kernel with busybox binary).

And how does the boot log look when you try to do that?

Yours,
Linus Walleij

Need advice: unable to mount filesystem

[Anil Kumar]

Hi,

On Wed, Feb 13, 2013 at 6:44 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Feb 13, 2013 at 1:29 PM, Amit Virdi <amit.virdi@st.com> wrote:
>
>> I have tried mounting the filesystem from DDR, that too with no success. One
>> observation is that before mounting the FS, the kernel throws a warning:
>> --
>> Warning: unable to open an initial console.
>
> This is not your problem. The kernel screams that all the time, (I once
> saw that explained and some ugly workaround for).
>
> This (from your log) is the real problem:
>
> VFS: Cannot open root device "mtdblock3" or unknown-block(31,3): error -14
> Please append a correct "root=" boot option; here are the available partitions:
> 1f00              64 mtdblock0  (driver?)
> 1f01             192 mtdblock1  (driver?)
> 1f02            2048 mtdblock2  (driver?)
> 1f03           14080 mtdblock3  (driver?)
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3)
> [<2000cb50>] (unwind_backtrace+0x0/0xf8) from [<2018655c>] (panic+0x8c/0x1d8)
> [<2018655c>] (panic+0x8c/0x1d8) from [<201f8d58>] (mount_block_root+0x1fc/0x2b8)
> [<201f8d58>] (mount_block_root+0x1fc/0x2b8) from [<201f90c0>]
> (prepare_namespace+0x160/0x1b8)
> [<201f90c0>] (prepare_namespace+0x160/0x1b8) from [<20185984>]
> (kernel_init+0x8/0xe4)
> [<20185984>] (kernel_init+0x8/0xe4) from [<20008e98>] (ret_from_fork+0x14/0x3c)

Please try with "rootwait" in bootargs.

I have also faced this type issue and solved by using "rootwait" .

Thanks,
Anil

Need advice: unable to mount filesystem

[Amit Virdi]

On 2/13/2013 6:44 PM, Linus Walleij wrote:
> On Wed, Feb 13, 2013 at 1:29 PM, Amit Virdi<amit.virdi@st.com>  wrote:
>
>> I have tried mounting the filesystem from DDR, that too with no success. One
>> observation is that before mounting the FS, the kernel throws a warning:
>> --
>> Warning: unable to open an initial console.
>
> This is not your problem. The kernel screams that all the time, (I once
> saw that explained and some ugly workaround for).
>

Okay.

> This (from your log) is the real problem:
>
> VFS: Cannot open root device "mtdblock3" or unknown-block(31,3): error -14
> Please append a correct "root=" boot option; here are the available partitions:
> 1f00              64 mtdblock0  (driver?)
> 1f01             192 mtdblock1  (driver?)
> 1f02            2048 mtdblock2  (driver?)
> 1f03           14080 mtdblock3  (driver?)
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3)
> [<2000cb50>] (unwind_backtrace+0x0/0xf8) from [<2018655c>] (panic+0x8c/0x1d8)
> [<2018655c>] (panic+0x8c/0x1d8) from [<201f8d58>] (mount_block_root+0x1fc/0x2b8)
> [<201f8d58>] (mount_block_root+0x1fc/0x2b8) from [<201f90c0>]
> (prepare_namespace+0x160/0x1b8)
> [<201f90c0>] (prepare_namespace+0x160/0x1b8) from [<20185984>]
> (kernel_init+0x8/0xe4)
> [<20185984>] (kernel_init+0x8/0xe4) from [<20008e98>] (ret_from_fork+0x14/0x3c)
>
> The kernel cannot find a working filesystem at mtdblock3.
>
>> I have even tried using initramfs (compiled kernel with busybox binary).
>
> And how does the boot log look when you try to do that?
>

Almost the same:

---
Kernel command line: console=ttyAMA0,115200

<<snip>>

Warning: unable to open an initial console.
VFS: Cannot open root device "(null)" or unknown-block(0,0): error -14
Please append a correct "root=" boot option; here are the available 
partitions:
1f00              64 mtdblock0  (driver?)
1f01             192 mtdblock1  (driver?)
1f02            2048 mtdblock2  (driver?)
1f03           14080 mtdblock3  (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)
[<2000cb50>] (unwind_backtrace+0x0/0xf8) from [<2018655c>] 
(panic+0x8c/0x1d8)
[<2018655c>] (panic+0x8c/0x1d8) from [<201f8d60>] 
(mount_block_root+0x1fc/0x2b8)
[<201f8d60>] (mount_block_root+0x1fc/0x2b8) from [<201f90c8>] 
(prepare_namespace+0x160/0x1b8)
[<201f90c8>] (prepare_namespace+0x160/0x1b8) from [<20185984>] 
(kernel_init+0x8/0xe4)
[<20185984>] (kernel_init+0x8/0xe4) from [<20008e98>] 
(ret_from_fork+0x14/0x3c)
---

Regards
Amit Virdi

Need advice: unable to mount filesystem

[Amit Virdi]

On 2/14/2013 8:27 AM, Anil Kumar wrote:
> Hi,
>
> On Wed, Feb 13, 2013 at 6:44 PM, Linus Walleij<linus.walleij@linaro.org>  wrote:
>> On Wed, Feb 13, 2013 at 1:29 PM, Amit Virdi<amit.virdi@st.com>  wrote:
>>
>>> I have tried mounting the filesystem from DDR, that too with no success. One
>>> observation is that before mounting the FS, the kernel throws a warning:
>>> --
>>> Warning: unable to open an initial console.
>>
>> This is not your problem. The kernel screams that all the time, (I once
>> saw that explained and some ugly workaround for).
>>
>> This (from your log) is the real problem:
>>
>> VFS: Cannot open root device "mtdblock3" or unknown-block(31,3): error -14
>> Please append a correct "root=" boot option; here are the available partitions:
>> 1f00              64 mtdblock0  (driver?)
>> 1f01             192 mtdblock1  (driver?)
>> 1f02            2048 mtdblock2  (driver?)
>> 1f03           14080 mtdblock3  (driver?)
>> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3)
>> [<2000cb50>] (unwind_backtrace+0x0/0xf8) from [<2018655c>] (panic+0x8c/0x1d8)
>> [<2018655c>] (panic+0x8c/0x1d8) from [<201f8d58>] (mount_block_root+0x1fc/0x2b8)
>> [<201f8d58>] (mount_block_root+0x1fc/0x2b8) from [<201f90c0>]
>> (prepare_namespace+0x160/0x1b8)
>> [<201f90c0>] (prepare_namespace+0x160/0x1b8) from [<20185984>]
>> (kernel_init+0x8/0xe4)
>> [<20185984>] (kernel_init+0x8/0xe4) from [<20008e98>] (ret_from_fork+0x14/0x3c)
>
> Please try with "rootwait" in bootargs.
>

Tried... no success :-(

I'll now backport to previous versions and see if it works.

Regards
Amit Virdi

Need advice: unable to mount filesystem

[Linus Walleij]

On Thu, Feb 14, 2013 at 6:24 AM, Amit Virdi <amit.virdi@st.com> wrote:
> On 2/13/2013 6:44 PM, Linus Walleij wrote:
>> [Amit]
>>> I have even tried using initramfs (compiled kernel with busybox binary).
>>
>> And how does the boot log look when you try to do that?
>
> Almost the same:
>
> ---
> Kernel command line: console=ttyAMA0,115200
>
> <<snip>>
>
>
> Warning: unable to open an initial console.
> VFS: Cannot open root device "(null)" or unknown-block(0,0): error -14
>
> Please append a correct "root=" boot option; here are the available
> partitions:
> 1f00              64 mtdblock0  (driver?)
> 1f01             192 mtdblock1  (driver?)
> 1f02            2048 mtdblock2  (driver?)
> 1f03           14080 mtdblock3  (driver?)
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)
>
> [<2000cb50>] (unwind_backtrace+0x0/0xf8) from [<2018655c>]
> (panic+0x8c/0x1d8)
> [<2018655c>] (panic+0x8c/0x1d8) from [<201f8d60>]
> (mount_block_root+0x1fc/0x2b8)
> [<201f8d60>] (mount_block_root+0x1fc/0x2b8) from [<201f90c8>]
> (prepare_namespace+0x160/0x1b8)
> [<201f90c8>] (prepare_namespace+0x160/0x1b8) from [<20185984>]
> (kernel_init+0x8/0xe4)
>
> [<20185984>] (kernel_init+0x8/0xe4) from [<20008e98>]
> (ret_from_fork+0x14/0x3c)

It looks like something is wrong with your initramfs. Check that
it is really added to the kernel image.

I usually use:

CONFIG_BLK_DEV_INITRD
CONFIG_INITRAMFS_SOURCE "your-ramdisk.cpio"
CONFIG_RD_GZIP
CONFIG_INITRAMFS_COMPRESSION_GZIP

Then pass root=/dev/ram0

But the last should not be necessary I think.

I have a precompiled ramfs here:
http://www.df.lth.se/~triad/krad/ux00/rootfs-u300.cpio

This is for ARM9 and uses ttyAMA0 as console so it
probably works with your system if you copy it to your
kernel build dir and state "rootfs-u300.cpio" as
initramfs source.

Yours,
Linus Walleij

Need advice: unable to mount filesystem

[Amit Virdi]

Linus,

I have some more findings...

>> [<20185984>] (kernel_init+0x8/0xe4) from [<20008e98>]
>> (ret_from_fork+0x14/0x3c)
>
> It looks like something is wrong with your initramfs. Check that
> it is really added to the kernel image.
>

I copied a known good flat filesystem in the flash. Then I appled 
patches for my SoC code to Linux 3.3, build the kernel and executed. 
Everything went smooth and the kernel successfully mounted the filesystem.

Then, I rebased on v3.4. The new kernel again successfully mounted the FS.

I rebased again on v3.5, again everything went smoothly.

However, when I rebased on v3.6 things started to break. The Kernel 
didn't boot at all. The processor generated Synchronous Data Abort 
exception because of alignment fault (during read operation). I debugged 
the code and noticed that start_kernel ran successfully till the end. It 
is the execution of rest_init that generated alignment fault.

Same behavior was observed for v3.7.

However, this problem didn't come with Kernel v3.8-rc6. So, the kernel 
execution proceeded further and all the devices were probed and their 
drivers loaded. As reported earlier, the Kernel couldn't mount the FS 
and is throwing the error:
--
VFS: Cannot open root device "mtdblock3" or unknown-block(31,3): error -14
--

So, as long as there's no compatibility change introduced in the newer 
Kernel, I do not suspect the filesystem as such.

It seems something has been broken for MMUless processors.

> I usually use:
>
> CONFIG_BLK_DEV_INITRD
> CONFIG_INITRAMFS_SOURCE "your-ramdisk.cpio"
> CONFIG_RD_GZIP

I have verified these for initramfs and these are perfect.

> CONFIG_INITRAMFS_COMPRESSION_GZIP
>

However, I'm not using this but this might not be necessary.

> Then pass root=/dev/ram0
>
> But the last should not be necessary I think.
>
> I have a precompiled ramfs here:
> http://www.df.lth.se/~triad/krad/ux00/rootfs-u300.cpio
>
> This is for ARM9 and uses ttyAMA0 as console so it
> probably works with your system if you copy it to your
> kernel build dir and state "rootfs-u300.cpio" as
> initramfs source.
>

Didn't get chance to try these yet.

Regards
Amit Virdi

Need advice: unable to mount filesystem

[Amit Virdi]

Hi All,

I'm using cortex-R4 in my SoC. I figured earlier that the support for 
MMU-less kernel was broken from Kernel v3.6 onwards. As a result, I was 
facing problem in mounting the filesystem. Using git bisect, I figured 
out that as a result of:

> ARM: 7449/1: use generic strnlen_user and strncpy_from_user functions

the file system was unable to mount on MMU-less kernel. Till date, I 
have been using the following local fix [1]:

---
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 479a635..e5d549f 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -190,7 +190,7 @@ static inline void set_fs(mm_segment_t fs)
  #define access_ok(type,addr,size)	(__range_ok(addr,size) == 0)

  #define user_addr_max() \
-	(segment_eq(get_fs(), USER_DS) ? TASK_SIZE : ~0UL)
+	(segment_eq(get_fs(), KERNEL_DL) ? ~0UL : TASK_SIZE)

  /*
   * The "__xxx" versions of the user access functions do not verify the
---

However, I have realized that other people using MMU-less CPUs are happy 
(hopefully) with the latest kernel. So, this makes me think that there's 
something other than my local fix that I should be doing to get rid of 
the filesystem mounting problem.

Can anyone guide me how they are able to run the kernel on MMU-less 
system without facing FS mounting problem?

Regards
Amit Virdi

[1] The above fix works only till kernel v3.11-rc3
[2] The patch "ARM: move signal handlers into a vdso-like page" 
introduced in v3.11-rc4 generates Prefetch abort while booting kernel in 
MMU-less systems

On 2/15/2013 5:25 PM, Amit VIRDI wrote:
> Linus,
>
> I have some more findings...
>
>>> [<20185984>] (kernel_init+0x8/0xe4) from [<20008e98>]
>>> (ret_from_fork+0x14/0x3c)
>>
>> It looks like something is wrong with your initramfs. Check that
>> it is really added to the kernel image.
>>
>
> I copied a known good flat filesystem in the flash. Then I appled
> patches for my SoC code to Linux 3.3, build the kernel and executed.
> Everything went smooth and the kernel successfully mounted the filesystem.
>
> Then, I rebased on v3.4. The new kernel again successfully mounted the FS.
>
> I rebased again on v3.5, again everything went smoothly.
>
> However, when I rebased on v3.6 things started to break. The Kernel
> didn't boot at all. The processor generated Synchronous Data Abort
> exception because of alignment fault (during read operation). I debugged
> the code and noticed that start_kernel ran successfully till the end. It
> is the execution of rest_init that generated alignment fault.
>
> Same behavior was observed for v3.7.
>
> However, this problem didn't come with Kernel v3.8-rc6. So, the kernel
> execution proceeded further and all the devices were probed and their
> drivers loaded. As reported earlier, the Kernel couldn't mount the FS
> and is throwing the error:
> --
> VFS: Cannot open root device "mtdblock3" or unknown-block(31,3): error -14
> --
>
> So, as long as there's no compatibility change introduced in the newer
> Kernel, I do not suspect the filesystem as such.
>
> It seems something has been broken for MMUless processors.
>
>> I usually use:
>>
>> CONFIG_BLK_DEV_INITRD
>> CONFIG_INITRAMFS_SOURCE "your-ramdisk.cpio"
>> CONFIG_RD_GZIP
>
> I have verified these for initramfs and these are perfect.
>
>> CONFIG_INITRAMFS_COMPRESSION_GZIP
>>
>
> However, I'm not using this but this might not be necessary.
>
>> Then pass root=/dev/ram0
>>
>> But the last should not be necessary I think.
>>
>> I have a precompiled ramfs here:
>> http://www.df.lth.se/~triad/krad/ux00/rootfs-u300.cpio
>>
>> This is for ARM9 and uses ttyAMA0 as console so it
>> probably works with your system if you copy it to your
>> kernel build dir and state "rootfs-u300.cpio" as
>> initramfs source.
>>
>
> Didn't get chance to try these yet.
>
> Regards
> Amit Virdi
> .
>

copy from user broken on no-MMU (Was: Need advice: unable to mount filesystem)

[Amit Virdi]

Dear Uwe,

On 10/16/2013 1:50 PM, Uwe Kleine-K?nig wrote:
> Hello Amit,
>
> (fixed subject and added Nico to Cc:)
>
> On Wed, Oct 16, 2013 at 10:55:17AM +0530, Amit Virdi wrote:
>> I'm using cortex-R4 in my SoC. I figured earlier that the support
>> for MMU-less kernel was broken from Kernel v3.6 onwards. As a
>> result, I was facing problem in mounting the filesystem. Using git
>> bisect, I figured out that as a result of:
>>
>>> ARM: 7449/1: use generic strnlen_user and strncpy_from_user functions
>>
>> the file system was unable to mount on MMU-less kernel. Till date, I
>> have been using the following local fix [1]:
>>
>> ---
>> diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
>> index 479a635..e5d549f 100644
>> --- a/arch/arm/include/asm/uaccess.h
>> +++ b/arch/arm/include/asm/uaccess.h
>> @@ -190,7 +190,7 @@ static inline void set_fs(mm_segment_t fs)
>>   #define access_ok(type,addr,size)	(__range_ok(addr,size) == 0)
>>
>>   #define user_addr_max() \
>> -	(segment_eq(get_fs(), USER_DS) ? TASK_SIZE : ~0UL)
>> +	(segment_eq(get_fs(), KERNEL_DL) ? ~0UL : TASK_SIZE)
>>
>>   /*
>>    * The "__xxx" versions of the user access functions do not verify the
> I did:
>
> http://git.pengutronix.de/?p=ukl/linux.git;a=commitdiff;h=089c629270ccd7499a083b530ec6aecc101d078b
>
> but I'm not sure either this is correct. I asked here on the list back
> then with the same patch as your's[1].
>
> [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/170980/focus=191855

Yes, I see. So what do you think is the best way to resolve this 
problem? It is already lingering around for so long.

>> [2] The patch "ARM: move signal handlers into a vdso-like page"
>> introduced in v3.11-rc4 generates Prefetch abort while booting
>> kernel in MMU-less systems
> My M3 happily runs on v3.12-rc4.
>

I fixed a local problem and now I'm able to execute the Kernel on v3.12-rc5.

Regards
Amit Virdi